gecko-dev/toolkit/modules/LightweightThemeConsumer.jsm

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

413 строки
13 KiB
JavaScript
Исходник Обычный вид История

2012-05-21 15:12:37 +04:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
var EXPORTED_SYMBOLS = ["LightweightThemeConsumer"];
Bug 1514594: Part 3 - Change ChromeUtils.import API. *** Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8 This changes the behavior of ChromeUtils.import() to return an exports object, rather than a module global, in all cases except when `null` is passed as a second argument, and changes the default behavior not to pollute the global scope with the module's exports. Thus, the following code written for the old model: ChromeUtils.import("resource://gre/modules/Services.jsm"); is approximately the same as the following, in the new model: var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm"); Since the two behaviors are mutually incompatible, this patch will land with a scripted rewrite to update all existing callers to use the new model rather than the old. *** Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs This was done using the followng script: https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm *** Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8 Differential Revision: https://phabricator.services.mozilla.com/D16747 *** Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D16748 *** Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D16749 *** Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs *** Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs Differential Revision: https://phabricator.services.mozilla.com/D16750 --HG-- extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895 extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
2019-01-17 21:18:31 +03:00
const {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
const DEFAULT_THEME_ID = "default-theme@mozilla.org";
const ICONS = Services.prefs.getStringPref("extensions.webextensions.themes.icons.buttons", "").split(",");
ChromeUtils.defineModuleGetter(this, "AppConstants",
"resource://gre/modules/AppConstants.jsm");
ChromeUtils.defineModuleGetter(this, "LightweightThemeImageOptimizer",
"resource://gre/modules/addons/LightweightThemeImageOptimizer.jsm");
// Get the theme variables from the app resource directory.
// This allows per-app variables.
ChromeUtils.defineModuleGetter(this, "ThemeContentPropertyList",
"resource:///modules/ThemeVariableMap.jsm");
ChromeUtils.defineModuleGetter(this, "ThemeVariableMap",
"resource:///modules/ThemeVariableMap.jsm");
const toolkitVariableMap = [
["--lwt-accent-color", {
lwtProperty: "accentcolor",
processColor(rgbaChannels, element) {
if (!rgbaChannels || rgbaChannels.a == 0) {
return "white";
}
// Remove the alpha channel
const {r, g, b} = rgbaChannels;
return `rgb(${r}, ${g}, ${b})`;
},
}],
["--lwt-text-color", {
lwtProperty: "textcolor",
processColor(rgbaChannels, element) {
if (!rgbaChannels) {
rgbaChannels = {r: 0, g: 0, b: 0};
}
// Remove the alpha channel
const {r, g, b} = rgbaChannels;
element.setAttribute("lwthemetextcolor", _isTextColorDark(r, g, b) ? "dark" : "bright");
return `rgba(${r}, ${g}, ${b})`;
},
}],
["--arrowpanel-background", {
lwtProperty: "popup",
}],
["--arrowpanel-color", {
lwtProperty: "popup_text",
processColor(rgbaChannels, element) {
const disabledColorVariable = "--panel-disabled-color";
if (!rgbaChannels) {
element.removeAttribute("lwt-popup-brighttext");
element.removeAttribute("lwt-popup-darktext");
element.style.removeProperty(disabledColorVariable);
return null;
}
let {r, g, b, a} = rgbaChannels;
if (_isTextColorDark(r, g, b)) {
element.removeAttribute("lwt-popup-brighttext");
element.setAttribute("lwt-popup-darktext", "true");
} else {
element.removeAttribute("lwt-popup-darktext");
element.setAttribute("lwt-popup-brighttext", "true");
}
element.style.setProperty(disabledColorVariable, `rgba(${r}, ${g}, ${b}, 0.5)`);
return `rgba(${r}, ${g}, ${b}, ${a})`;
},
}],
["--arrowpanel-border-color", {
lwtProperty: "popup_border",
}],
["--lwt-toolbar-field-background-color", {
lwtProperty: "toolbar_field",
}],
["--lwt-toolbar-field-color", {
lwtProperty: "toolbar_field_text",
processColor(rgbaChannels, element) {
if (!rgbaChannels) {
element.removeAttribute("lwt-toolbar-field-brighttext");
return null;
}
const {r, g, b, a} = rgbaChannels;
if (_isTextColorDark(r, g, b)) {
element.removeAttribute("lwt-toolbar-field-brighttext");
} else {
element.setAttribute("lwt-toolbar-field-brighttext", "true");
}
return `rgba(${r}, ${g}, ${b}, ${a})`;
},
}],
["--lwt-toolbar-field-border-color", {
lwtProperty: "toolbar_field_border",
}],
["--lwt-toolbar-field-focus", {
lwtProperty: "toolbar_field_focus",
}],
["--lwt-toolbar-field-focus-color", {
lwtProperty: "toolbar_field_text_focus",
}],
["--toolbar-field-focus-border-color", {
lwtProperty: "toolbar_field_border_focus",
}],
["--lwt-toolbar-field-highlight", {
lwtProperty: "toolbar_field_highlight",
processColor(rgbaChannels, element) {
if (!rgbaChannels) {
element.removeAttribute("lwt-selection");
return null;
}
element.setAttribute("lwt-selection", "true");
const {r, g, b, a} = rgbaChannels;
return `rgba(${r}, ${g}, ${b}, ${a})`;
},
}],
["--lwt-toolbar-field-highlight-text", {
lwtProperty: "toolbar_field_highlight_text",
}],
];
function LightweightThemeConsumer(aDocument) {
this._doc = aDocument;
this._win = aDocument.defaultView;
this._winId = this._win.windowUtils.outerWindowID;
Services.obs.addObserver(this, "lightweight-theme-styling-update");
ChromeUtils.import("resource://gre/modules/LightweightThemeManager.jsm", this);
// We're responsible for notifying LightweightThemeManager when the OS is in
// dark mode so it can activate the dark theme. We don't want this on Linux
2019-02-26 18:37:29 +03:00
// as the default theme picks up the right colors from dark GTK themes.
if (AppConstants.platform != "linux") {
this._darkThemeMediaQuery = this._win.matchMedia("(-moz-system-dark-theme)");
this._darkThemeMediaQuery.addListener(this.LightweightThemeManager);
this.LightweightThemeManager.systemThemeChanged(this._darkThemeMediaQuery);
}
this._update(this.LightweightThemeManager.currentThemeWithPersistedData);
this._win.addEventListener("resolutionchange", this);
this._win.addEventListener("unload", this, { once: true });
}
LightweightThemeConsumer.prototype = {
_lastData: null,
// Whether a lightweight theme is enabled.
_active: false,
observe(aSubject, aTopic, aData) {
if (aTopic != "lightweight-theme-styling-update")
return;
let parsedData = JSON.parse(aData);
if (!parsedData) {
parsedData = { theme: null, experiment: null };
}
if (parsedData.window && parsedData.window !== this._winId) {
return;
}
this._update(parsedData.theme, parsedData.experiment);
},
handleEvent(aEvent) {
switch (aEvent.type) {
case "resolutionchange":
if (this._active) {
this._update(this._lastData);
}
break;
case "unload":
Services.obs.removeObserver(this, "lightweight-theme-styling-update");
Services.ppmm.sharedData.delete(`theme/${this._winId}`);
this._win.removeEventListener("resolutionchange", this);
this._win = this._doc = null;
if (this._darkThemeMediaQuery) {
this._darkThemeMediaQuery.removeListener(this.LightweightThemeManager);
this._darkThemeMediaQuery = null;
}
break;
}
},
_update(theme, experiment) {
this._lastData = theme;
if (theme) {
theme = LightweightThemeImageOptimizer.optimize(theme, this._win.screen);
}
if (!theme) {
theme = { id: DEFAULT_THEME_ID };
}
let active = this._active = (theme.id != DEFAULT_THEME_ID);
// The theme we're switching to can be different from the user-selected
// theme. E.g. if the default theme is selected and the OS is in dark mode,
// we'd silently activate the dark theme if available. We set an attribute
// in that case so stylesheets can differentiate this from the dark theme
// being selected explicitly by the user.
let isDefaultThemeInDarkMode =
theme.id == this.LightweightThemeManager.defaultDarkThemeID &&
this.LightweightThemeManager.selectedThemeID == DEFAULT_THEME_ID &&
this._darkThemeMediaQuery &&
this._darkThemeMediaQuery.matches;
let root = this._doc.documentElement;
if (active && theme.headerURL) {
root.setAttribute("lwtheme-image", "true");
} else {
root.removeAttribute("lwtheme-image");
}
if (active && theme.icons) {
let activeIcons = Object.keys(theme.icons).join(" ");
root.setAttribute("lwthemeicons", activeIcons);
} else {
root.removeAttribute("lwthemeicons");
}
for (let icon of ICONS) {
let value = theme.icons ? theme.icons[`--${icon}-icon`] : null;
_setImage(root, active, `--${icon}-icon`, value);
}
this._setExperiment(active, experiment, theme.experimental);
_setImage(root, active, "--lwt-header-image", theme.headerURL);
_setImage(root, active, "--lwt-additional-images", theme.additionalBackgrounds);
_setProperties(root, active, theme);
if (active) {
root.setAttribute("lwtheme", "true");
} else {
root.removeAttribute("lwtheme");
root.removeAttribute("lwthemetextcolor");
}
if (isDefaultThemeInDarkMode) {
root.setAttribute("lwt-default-theme-in-dark-mode", "true");
} else {
root.removeAttribute("lwt-default-theme-in-dark-mode");
}
let contentThemeData = _getContentProperties(this._doc, active, theme);
Services.ppmm.sharedData.set(`theme/${this._winId}`, contentThemeData);
},
_setExperiment(active, experiment, properties) {
const root = this._doc.documentElement;
if (this._lastExperimentData) {
const { stylesheet, usedVariables } = this._lastExperimentData;
if (stylesheet) {
stylesheet.remove();
}
if (usedVariables) {
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
for (const [variable] of usedVariables) {
_setProperty(root, false, variable);
}
}
}
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
this._lastExperimentData = {};
if (!active || !experiment) {
return;
}
let usedVariables = [];
if (properties.colors) {
for (const property in properties.colors) {
const cssVariable = experiment.colors[property];
const value = _sanitizeCSSColor(root.ownerDocument, properties.colors[property]);
usedVariables.push([cssVariable, value]);
}
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
}
if (properties.images) {
for (const property in properties.images) {
const cssVariable = experiment.images[property];
usedVariables.push([cssVariable, `url(${properties.images[property]})`]);
}
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
}
if (properties.properties) {
for (const property in properties.properties) {
const cssVariable = experiment.properties[property];
usedVariables.push([cssVariable, properties.properties[property]]);
}
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
}
for (const [variable, value] of usedVariables) {
_setProperty(root, true, variable, value);
}
this._lastExperimentData.usedVariables = usedVariables;
if (experiment.stylesheet) {
/* Stylesheet URLs are validated using WebExtension schemas */
let stylesheetAttr = `href="${experiment.stylesheet}" type="text/css"`;
let stylesheet = this._doc.createProcessingInstruction("xml-stylesheet",
stylesheetAttr);
this._doc.insertBefore(stylesheet, root);
this._lastExperimentData.stylesheet = stylesheet;
}
},
};
function _getContentProperties(doc, active, data) {
if (!active) {
return {};
}
let properties = {};
for (let property in data) {
if (ThemeContentPropertyList.includes(property)) {
properties[property] = _parseRGBA(_sanitizeCSSColor(doc, data[property]));
}
}
return properties;
}
function _setImage(aRoot, aActive, aVariableName, aURLs) {
if (aURLs && !Array.isArray(aURLs)) {
aURLs = [aURLs];
}
_setProperty(aRoot, aActive, aVariableName, aURLs && aURLs.map(v => `url("${v.replace(/"/g, '\\"')}")`).join(","));
}
function _setProperty(elem, active, variableName, value) {
if (active && value) {
elem.style.setProperty(variableName, value);
} else {
elem.style.removeProperty(variableName);
}
}
function _setProperties(root, active, themeData) {
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
let properties = [];
for (let map of [toolkitVariableMap, ThemeVariableMap]) {
for (let [cssVarName, definition] of map) {
const {
lwtProperty,
optionalElementID,
processColor,
isColor = true,
} = definition;
let elem = optionalElementID ? root.ownerDocument.getElementById(optionalElementID)
: root;
let val = themeData[lwtProperty];
if (isColor) {
val = _sanitizeCSSColor(root.ownerDocument, val);
if (processColor) {
val = processColor(_parseRGBA(val), elem);
}
}
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
properties.push([elem, cssVarName, val]);
}
}
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
// Set all the properties together, since _sanitizeCSSColor flushes.
for (const [elem, cssVarName, val] of properties) {
_setProperty(elem, active, cssVarName, val);
}
}
function _sanitizeCSSColor(doc, cssColor) {
if (!cssColor) {
return null;
}
const HTML_NS = "http://www.w3.org/1999/xhtml";
// style.color normalizes color values and makes invalid ones black, so a
// simple round trip gets us a sanitized color value.
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
// Use !important so that the theme's stylesheets cannot override us.
let div = doc.createElementNS(HTML_NS, "div");
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
div.style.setProperty("color", "black", "important");
div.style.setProperty("display", "none", "important");
let span = doc.createElementNS(HTML_NS, "span");
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
span.style.setProperty("color", cssColor, "important");
// CSS variables are not allowed and should compute to black.
Bug 1511138 - Improve performance of LightweightThemeConsumer when setting properties, and also avoid _sanitizeCSSColor from getting fooled. r=jaws 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
2018-12-04 05:06:44 +03:00
if (span.style.color.includes("var(")) {
span.style.color = "";
}
div.appendChild(span);
doc.documentElement.appendChild(div);
cssColor = doc.defaultView.getComputedStyle(span).color;
div.remove();
return cssColor;
}
function _parseRGBA(aColorString) {
if (!aColorString) {
return null;
}
var rgba = aColorString.replace(/(rgba?\()|(\)$)/g, "").split(",");
rgba = rgba.map(x => parseFloat(x));
return {
r: rgba[0],
g: rgba[1],
b: rgba[2],
a: 3 in rgba ? rgba[3] : 1,
};
}
function _isTextColorDark(r, g, b) {
return (0.2125 * r + 0.7154 * g + 0.0721 * b) <= 110;
}