The heuristic is that we show focus outlines for unknown or key focus, and not
for mouse / touch.
This is probably not the final heuristic we take, but this allows people to play
with it and file bugs.
Once this is mature enough we should remove :-moz-focusring in favor of
:focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D63861
--HG--
extra : moz-landing-system : lando
This commit implements the actual UI changes. A follow-up commit adds the
tests for the changes. The CSS is a little bit awkard since it uses lots of
ID selectors rather than class selectors. I wanted to be able to write quick
selects, since it's selecting across the entire browser document. I feel
a little conflicted with the approach, as I would prefer to use classes in
general.
The panel.jsm.js file collects all of the UI handling changes rather than
having everything in menu-button.jsm.js, as the latter can get loaded
at startup. I'm not sure if it's completely worth the trouble of having
two files, as most of it should be pretty light.
This commit does not handle localization for the panel, as we should be moving
to Fluent. Rather than solve that here, I will follow-up with it in Bug 1599774.
Differential Revision: https://phabricator.services.mozilla.com/D62914
--HG--
extra : moz-landing-system : lando
This was inadvertently enabled and it has memory and likely
other perf impact that we're not yet ready to evaluate.
Differential Revision: https://phabricator.services.mozilla.com/D63343
--HG--
extra : moz-landing-system : lando
The heuristic is that we show focus outlines for unknown or key focus, and not
for mouse / touch.
This is probably not the final heuristic we take, but this allows people to play
with it and file bugs.
Once this is mature enough we should remove :-moz-focusring in favor of
:focus-visible.
Differential Revision: https://phabricator.services.mozilla.com/D63861
--HG--
extra : moz-landing-system : lando
This commit implements the actual UI changes. A follow-up commit adds the
tests for the changes. The CSS is a little bit awkard since it uses lots of
ID selectors rather than class selectors. I wanted to be able to write quick
selects, since it's selecting across the entire browser document. I feel
a little conflicted with the approach, as I would prefer to use classes in
general.
The panel.jsm.js file collects all of the UI handling changes rather than
having everything in menu-button.jsm.js, as the latter can get loaded
at startup. I'm not sure if it's completely worth the trouble of having
two files, as most of it should be pretty light.
This commit does not handle localization for the panel, as we should be moving
to Fluent. Rather than solve that here, I will follow-up with it in Bug 1599774.
Differential Revision: https://phabricator.services.mozilla.com/D62914
--HG--
extra : moz-landing-system : lando
Add a pref that we can gate the EME app approval behaviour behind. If the pref
is true we'll ask app for approval via a permission request. The intended use
for this is to allow GeckoView to seek explicit approval from the embedding app.
Having this pref is also useful for testing outside of GeckoView as it allows
runtime configuration of the permission check.
Differential Revision: https://phabricator.services.mozilla.com/D56102
--HG--
extra : moz-landing-system : lando
This moves the late write checking forward to before xpcom-shutdown-threads
in Nightly, and it turns it on for after the last cycle collection on
beta/release.
Differential Revision: https://phabricator.services.mozilla.com/D63215
--HG--
extra : moz-landing-system : lando
We remove the old behaviour that if webm was disabled it would be overridden under some circumstances.
Instead we replace if with a new specialised preference (media.mediasource.vp9.enabled) that is only disabled on Android.
If this pref is disabled, vp9 will only be enabled under some conditions:
- h264 HW decoding is not supported
- mp4 is not enabled
- Device was deemed fast enough to decode VP9 via the P9Benchmark utility
- On Android, A VP9 HW decoder is present.
The primary observable result is that YouTube will serve H264 content on devices with no hardware VP9 decoder
Differential Revision: https://phabricator.services.mozilla.com/D63042
--HG--
extra : moz-landing-system : lando
We remove the old behaviour that if webm was disabled it would be overridden under some circumstances.
Instead we replace if with a new specialised preference (media.mediasource.vp9.enabled) that is only disabled on Android.
If this pref is disabled, vp9 will only be enabled under some conditions:
- h264 HW decoding is not supported
- mp4 is not enabled
- Device was deemed fast enough to decode VP9 via the P9Benchmark utility
- On Android, A VP9 HW decoder is present.
The primary observable result is that YouTube will serve H264 content on devices with no hardware VP9 decoder
Differential Revision: https://phabricator.services.mozilla.com/D63042
--HG--
extra : moz-landing-system : lando
Will send an intent. The only issues I'm aware of are serialization /
simplification ones where every browser does its own thing already, and we're
the one that behaves the closest to the spec.
Differential Revision: https://phabricator.services.mozilla.com/D63585
--HG--
extra : moz-landing-system : lando
We remove the old behaviour that if webm was disabled it would be overridden under some circumstances.
Instead we replace if with a new specialised preference (media.mediasource.vp9.enabled) that is only disabled on Android.
If this pref is disabled, vp9 will only be enabled under some conditions:
- h264 HW decoding is not supported
- mp4 is not enabled
- Device was deemed fast enough to decode VP9 via the P9Benchmark utility
- On Android, A VP9 HW decoder is present.
The primary observable result is that YouTube will serve H264 content on devices with no hardware VP9 decoder
Differential Revision: https://phabricator.services.mozilla.com/D63042
--HG--
extra : moz-landing-system : lando
