VOOZH about

URL: https://bugzilla.mozilla.org/show_bug.cgi?id=1611272

⇱ 1611272 - In mochitest, appending a media element to document would make Navigator.MediaSession become undefined


Closed Bug 1611272 Opened 6 years ago Closed 6 years ago

In mochitest, appending a media element to document would make Navigator.MediaSession become undefined

In mochitest, appending a media element to document would make Navigator.MediaSession become undefined
Core
DOM: Core & HTML
unspecified
Unspecified
Unspecified
defect
Not set
normal
Points:
---
RESOLVED WORKSFORME
RESOLVED
WORKSFORME
Iteration:
---
a11y-review
Accessibility Severity
Performance Impact
Size Estimate
Webcompat Priority
Webcompat Score
Tracking Status
relnote-firefox
thunderbird_esr115
thunderbird_esr140
firefox-esr115
firefox-esr140
firefox-esr153
firefox152
firefox153
firefox154
---
QA Whiteboard:
---
Has STR:
---
Change Request:
---
Bug Flags:
Signature:
None
This bug is publicly visible.

 
👁 Image
Multiple Authors

Description

6 years ago

Navigator.mediaSession is controlled by the pref dom.media.mediasession.enabled.

And I found a weird thing when writing a mochitest, if you create a. media element and append it to the document, then Navigator.mediaSession would become undefined even if you have already turn the pref dom.media.mediasession.enabled on.


STR

  1. adding a line "<video></video" or "<audio></audio>" between line#8 and line#9 in [1]
  2. (for clearer error msg) comment line#53
  3. run the test_setactionhandler.html

Expected.
4. navigator.mediaSession is defined

Actual.
4. navigator.mediaSession is undefined

[1] https://searchfox.org/mozilla-central/rev/f98dad153b59a985efd4505912588d4651033395/dom/media/mediasession/test/test_setactionhandler.html#8-9
[2] https://searchfox.org/mozilla-central/rev/f98dad153b59a985efd4505912588d4651033395/dom/media/mediasession/test/test_setactionhandler.html#53

Reporter

Comment 1

6 years ago

Hi, bz,
Do you have any idea about this issue?
Thank you very much.

Flags: needinfo?(bzbarsky)
Reporter

Updated

6 years ago
Type: task → defect

The pref defined in the IDL is read whenever Navigator.prototype is set up. This happens lazily the first time someone asks for that object or the Navigator object. So if anything in the test touches navigator before the function that sets the pref runs, you will end up with the property not being defined.

Now in this case, if an <audio> is added to the DOM before that <script>, then Navigator.prototype is set up with this C++ stack (abridged):

Window_Binding::get_navigator
...
js stuff
...
Element::NotifyUAWidgetSetupOrChange

and this JS stack:

0 anonymous( <Failed to get argument while inspecting stack frame>
 <Failed to get argument while inspecting stack frame>
) ["chrome://global/content/elements/videocontrols.js":22:4]
 <failed to get 'this' value>
1 setupWidget(aElement = [cross-compartment wrapper]) ["resource://gre/actors/UAWidgetsChild.jsm":125:17]
 <failed to get 'this' value>
2 setupOrNotifyWidget(aElement = [cross-compartment wrapper]) ["resource://gre/actors/UAWidgetsChild.jsm":46:11]
 <failed to get 'this' value>
3 handleEvent(aEvent = [cross-compartment wrapper]) ["resource://gre/actors/UAWidgetsChild.jsm":36:13]
 <failed to get 'this' value>

The JS there looks like this, in the VideoControlsWidget constructor:

 this.isMobile = this.window.navigator.appVersion.includes("Android");

This all happens before the pref gets set, so there is no mediaSession property.

The usual way to deal with this sort of thing in mochitests is to set the pref, then create a new iframe and do your test stuff using objects from that. Since the global for the iframe is created after the pref is set, all the IDL bits in there see the pref when they get set up.

Flags: needinfo?(bzbarsky)
Reporter

Comment 3

6 years ago

Ah, it helps a lot, I will use the way you suggested to rewrite my test!
Thank you very muich

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.