I missed the failure in browser_selectpopup_colors.js since it doesn't run on
Linux. Fix the getComputedStyle usage in that code by using
getDefaultComputedStyle, which is what it really wants.
Also, do a bit of cleanup while at it: uaBackgroundColor was unused, and uaColor
was wrong (we don't override the ua color of the <option> element, it just
inherits, so it's the same as the <select> color, and that's what we were
comparing it against anyway).
Differential Revision: https://phabricator.services.mozilla.com/D13956
This probably deserves a comment as of why it belongs to this bug.
This patch series caused a single, reproducible timeout on
browser_ext_themes_toolbars.js, where the transitionend event it awaits for
stops triggering.
I got fascinated by it and I decided to poke around it in rr instead of just
removing the await line, and here's what's going on.
In the previous implementation of _sanitizeCSSColor, we were not flushing style
because of the optimization bug 1363805 introduced (which wasn't supposed to
deal with out-of-document elements, but it accidentally did so).
In any case, the fact that we were not flushing style in _sanitizeCSSColor
caused us to flush style sometime later when the lwtheme attribute was already
set up, and thus the selector in here matched:
https://searchfox.org/mozilla-central/rev/cfaa5a1d48d6bc6552199e73004ecb05d0a9c921/browser/themes/shared/browser.inc.css#40
And thus caused the transition rule to apply at a time where the
background-color change happened.
Now we were flushing on getComputedStyle on every call, and in the most
inefficient way possible (changing a custom property on the root before each
property change, which causes us to restyle the whole document to propagate it
down to all descendants).
Furthermore, we were flushing style at a time where the lwtheme attribute
change had not yet happened, and thus when the background-color changed, there
was no transition rule applicable, and the transition didn't fire.
This patch changes LightweightThemeConsumer to avoid restyling the whole
document over and over.
Also, while at it I realized that you could fool the sanitizer with !important
in an experiment stylesheet or with other !important rule in the page really.
It's not clear why you'd do that, but it may be worth to just making that
function completely sound, so I did that and added a test for it.
Differential Revision: https://phabricator.services.mozilla.com/D13716
See D13472 for spec quotes and such. Other browsers don't allow
getting computed styles in disconnected subtrees and we agreed to follow suit
(it does make sense because when you're not on the flat tree it's not defined
what you're supposed to inherit from, specially in presence of Shadow DOM).
Also, it allows the style system to rely on the DOM being in a sane state.
Differential Revision: https://phabricator.services.mozilla.com/D13551
https://drafts.csswg.org/cssom/#dom-window-getcomputedstyle says:
> If elt is connected, part of the flat tree, and its shadow-including root...
WebKit and Blink already do this, and we do it already except for cross-document
situations, where we can end up with a PresShell even if GetPresShellForContent
returns null.
The style system should be able to rely on ShadowRoots having a non-null shadow
host.
Differential Revision: https://phabricator.services.mozilla.com/D13472
Update WebRTC stat deprecation messages which were originally targeting 65, which are now targeting 66.
Differential Revision: https://phabricator.services.mozilla.com/D13950
--HG--
extra : moz-landing-system : lando
This also adds a console test to make sure we don't regress
this in the future.
Differential Revision: https://phabricator.services.mozilla.com/D13762
--HG--
extra : moz-landing-system : lando
This probably deserves a comment as of why it belongs to this bug.
This patch series caused a single, reproducible timeout on
browser_ext_themes_toolbars.js, where the transitionend event it awaits for
stops triggering.
I got fascinated by it and I decided to poke around it in rr instead of just
removing the await line, and here's what's going on.
In the previous implementation of _sanitizeCSSColor, we were not flushing style
because of the optimization bug 1363805 introduced (which wasn't supposed to
deal with out-of-document elements, but it accidentally did so).
In any case, the fact that we were not flushing style in _sanitizeCSSColor
caused us to flush style sometime later when the lwtheme attribute was already
set up, and thus the selector in here matched:
https://searchfox.org/mozilla-central/rev/cfaa5a1d48d6bc6552199e73004ecb05d0a9c921/browser/themes/shared/browser.inc.css#40
And thus caused the transition rule to apply at a time where the
background-color change happened.
Now we were flushing on getComputedStyle on every call, and in the most
inefficient way possible (changing a custom property on the root before each
property change, which causes us to restyle the whole document to propagate it
down to all descendants).
Furthermore, we were flushing style at a time where the lwtheme attribute
change had not yet happened, and thus when the background-color changed, there
was no transition rule applicable, and the transition didn't fire.
This patch changes LightweightThemeConsumer to avoid restyling the whole
document over and over.
Also, while at it I realized that you could fool the sanitizer with !important
in an experiment stylesheet or with other !important rule in the page really.
It's not clear why you'd do that, but it may be worth to just making that
function completely sound, so I did that and added a test for it.
Differential Revision: https://phabricator.services.mozilla.com/D13716
See D13472 for spec quotes and such. Other browsers don't allow
getting computed styles in disconnected subtrees and we agreed to follow suit
(it does make sense because when you're not on the flat tree it's not defined
what you're supposed to inherit from, specially in presence of Shadow DOM).
Also, it allows the style system to rely on the DOM being in a sane state.
Differential Revision: https://phabricator.services.mozilla.com/D13551
