This is used by some gfx code and is required to convert gfxPrefs into StaticPrefs.
The setter only modifies the value of the StaticPref in the current process and doesn't propagate to others.
Differential Revision: https://phabricator.services.mozilla.com/D31254
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
Following the shift in unified build setup following the removal of gfxPrefs.{cpp,c} we hit this error.
Unified builds made this header get included with other files that use multiple inheritance, and clang-cl about the conflicting inheritance models. Local testing suggests clang-cl doesn't need the pragma anyway, so just take it out.
Differential Revision: https://phabricator.services.mozilla.com/D31465
--HG--
extra : moz-landing-system : lando
This allows for the getter to be used in IProtocol's destructor, and generally
brings IProtocol more in line with IToplevelProtocol.
Differential Revision: https://phabricator.services.mozilla.com/D32042
--HG--
extra : moz-landing-system : lando
This patch changes the timing of when the other side actor is created to
be after posting the message to the event loop, to avoid situations
early during actor creation when the parent side hasn't been created yet
triggering null pointer crashes.
Differential Revision: https://phabricator.services.mozilla.com/D30664
--HG--
extra : moz-landing-system : lando
This is an attempt to reduce the negative impact of bug 1553644 by replacing a
remote browser which fails to create an `mBrowserParent` actor with a tab
crashed display rather than a failed `nsFrameLoader`. This is done by firing the
`oop-browser-crashed` event on the owner `<browser>` element when the attempt
fails, even if no `BrowserParent` was ever created.
This does not fix the root cause of bug 1553644, but may make the browser better
at recovering.
Differential Revision: https://phabricator.services.mozilla.com/D32381
--HG--
extra : moz-landing-system : lando
As now we won't load disabled text track, we have to mark track as default in order to trigger loading which would be done by automatically text track selection, or to set its track mode explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D32359
--HG--
extra : moz-landing-system : lando
Sometime wpt runs test even before the document becomes visible, which would delay `video.play()` and cause `play()` running in wrong order.
Differential Revision: https://phabricator.services.mozilla.com/D32079
--HG--
extra : moz-landing-system : lando
The channel might not be created correctly if we pass invaild url (eg. "invalid://url"), we should handle this error.
Differential Revision: https://phabricator.services.mozilla.com/D32038
--HG--
extra : moz-landing-system : lando
This test is used to ensure that we queue 'honor user preferences for automatic text track selection' as a marco task, not a mirco task.
In this test, we would trigger a media event before queuing a text track selection task, and check the text track's mode to know whether the text track selection runs after the task for media event.
Differential Revision: https://phabricator.services.mozilla.com/D31921
--HG--
extra : moz-landing-system : lando
Refactor those tests' structure in order to make them more readable, and add the comment to show what the test purpose is for each test.
Differential Revision: https://phabricator.services.mozilla.com/D31914
--HG--
extra : moz-landing-system : lando
This patch do two things in order to trigger loading for track element and wait for correct event to check track's and cues' status after loading finished.
(1) listen track element's load event
There are some tests listening video's loadedmetadata, but it's wrong. The loading process of media element and track element are completely non-related.
If you would like to check track element's status, you should wait for track element's load event.
(2) enable track explictly
If the text track which has default attribute is added to the media element before the media element starts running automatic track selection [1], then it would be enable by the media element.
Otherwise, you have to enable track explicitly by changing its track mode.
[1] https://html.spec.whatwg.org/multipage/media.html#sourcing-out-of-band-text-tracks:text-track-7
Differential Revision: https://phabricator.services.mozilla.com/D31913
--HG--
extra : moz-landing-system : lando
Create test elements in HTML beforehand, which can remove unnecessary JS code and make test cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D31911
--HG--
extra : moz-landing-system : lando
To reduce non-neccesary input, we can always capture `this` and print the address in the log, and use same log level for all of them.
Differential Revision: https://phabricator.services.mozilla.com/D31559
--HG--
extra : moz-landing-system : lando
There are too many `self` used in the lambda, we can just capture `this` to remove redudant `self`.
Differential Revision: https://phabricator.services.mozilla.com/D31558
--HG--
extra : moz-landing-system : lando
Beta sees a couple more of these same asserts for some reason.
Explanation of logic for bumping these counts can be found in bug 1530190 where we bumped them already before.
Differential Revision: https://phabricator.services.mozilla.com/D32384
--HG--
extra : moz-landing-system : lando
