Remove the "root-element" binding and instead set up the lightweight theme consumer on :root elements from JS

RESOLVED FIXED in Firefox 60

Status

()

P3
normal
RESOLVED FIXED
a year ago
11 months ago

People

(Reporter: bgrins, Assigned: bgrins)

Tracking

(Blocks: 2 bugs)

Trunk
Firefox 60
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox60 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

a year ago
We have a binding "root-element" (https://bgrins.github.io/xbl-analysis/tree/#root-element), which gets bound onto the :root XUL element in minimal-xul.css (https://dxr.mozilla.org/mozilla-central/rev/474d58c9137360c0fa1c85cdd11e3313b33b7cad/toolkit/content/minimal-xul.css#33).

The binding basically looks for the "lightweightthemes" attribute on the root element and if it exists it sets up LightweightThemeConsumer instance. I think there’s a pretty good alternative to doing this via XBL which is listen for the "chrome-document-global-created" notification and do the same check / setup from there. Or sticking it in browser.js, given that's the only window we currently use this feature on in Firefox.

This binding is also extended by "dialog" "wizard" bindings, but I can't find any time where anything other than a <window> element gets the "lightweightthemes" attr.  In fact, in m-c the only instance of this is browser.xul (c-c does have quite a few hits but it's always applied to <window> elements so the same change should work there as well):

* https://searchfox.org/mozilla-central/search?q=lightweightthemes%3D&path=
* https://searchfox.org/comm-central/search?q=lightweightthemes%3D&path=
Comment hidden (mozreview-request)
(Assignee)

Comment 2

a year ago
Comment on attachment 8946791 [details]
Bug 1434401 - Remove the "root-element" binding from :root and create the LightweightThemeConsumer directly from browser.js;

Dão, can you review this change or suggest someone else to? I opted to put this into nsBrowserGlue instead of somewhere like gBrowserInit.onDOMContentLoaded in browser.js to stay closer to the current semantics: looking for an attribute in all XUL document roots instead of only browser.xul (even though in practice that's the only place we use it in m-c).
Attachment #8946791 - Flags: review?(dao+bmo)
(Assignee)

Updated

a year ago
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED

Updated

a year ago
Attachment #8946791 - Flags: review?(dao+bmo) → review?(gijskruitbosch+bugs)

Comment 3

a year ago
mozreview-review
Comment on attachment 8946791 [details]
Bug 1434401 - Remove the "root-element" binding from :root and create the LightweightThemeConsumer directly from browser.js;

https://reviewboard.mozilla.org/r/216714/#review222558

r=me assuming green try. :-)
Attachment #8946791 - Flags: review?(gijskruitbosch+bugs) → review+

Comment 4

a year ago
(In reply to Brian Grinstead [:bgrins] from comment #2)
> Comment on attachment 8946791 [details]
> Bug 1434401: Remove the "root-element" binding from :root and instead create
> the LightweightThemeConsumer from JS when new windows are created;
> 
> Dão, can you review this change or suggest someone else to? I opted to put
> this into nsBrowserGlue instead of somewhere like
> gBrowserInit.onDOMContentLoaded in browser.js to stay closer to the current
> semantics: looking for an attribute in all XUL document roots instead of
> only browser.xul (even though in practice that's the only place we use it in
> m-c).

Ugh, mozreview. FWIW, I didn't mean to steal this. When I added my self-review-request, mozreview didn't show any other reviewers, nor did it show any sign of a mid-air. Sorry! :-\


Dão, re-pinging you in case you want to review this instead of me.
Flags: needinfo?(dao+bmo)
(Assignee)

Comment 5

a year ago
(In reply to :Gijs from comment #3)
> Comment on attachment 8946791 [details]
> Bug 1434401: Remove the "root-element" binding from :root and instead create
> the LightweightThemeConsumer from JS when new windows are created;
> 
> https://reviewboard.mozilla.org/r/216714/#review222558
> 
> r=me assuming green try. :-)

Thanks for the review :). I have a couple of try pushes and both look fine:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=48809a6ebc2dd5a0fdedf015ca12aaae994372a8
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f99ffbdb997cc90cb793d0727124e8bdc3fa56e0

The second I ran especially to look at android, although since there's a completely different LWT implementation there I didn't expect any issue.
(Assignee)

Comment 6

a year ago
Frank, just a heads up this bug will remove the general.xml#root-element binding and the rule assigning it to :root in minimal-xul.css. See Comment 0 for more info.

Instead we are going to watch for new windows being created in js to set up the LWT consumer - the current patch uses the "chrome-document-global-created" notification. comm-central uses this feature in a few documents in editor/ mail/ and suite/ (https://searchfox.org/comm-central/search?q=lightweightthemes%3D&path=).  You could either restore the binding (minus the call to destroy() which will now be handled within the LWT consumer) or copy over the changes from nsBrowserGlue into the appropriate place(s) in comm-central.
Flags: needinfo?(frgrahl)
Depends on: 1434547
(In reply to Brian Grinstead [:bgrins] from comment #2)
> Comment on attachment 8946791 [details]
> Bug 1434401: Remove the "root-element" binding from :root and instead create
> the LightweightThemeConsumer from JS when new windows are created;
> 
> Dão, can you review this change or suggest someone else to? I opted to put
> this into nsBrowserGlue instead of somewhere like
> gBrowserInit.onDOMContentLoaded in browser.js to stay closer to the current
> semantics: looking for an attribute in all XUL document roots instead of
> only browser.xul (even though in practice that's the only place we use it in
> m-c).

I think we should put this in gBrowserInit as I don't anticipate that we'll use this for other windows. Most non-browser.xul windows are small and transient. The long-term plan for the Library window is to move it into a tab.
Flags: needinfo?(dao+bmo)
Thanks. Will take care of it for SeaMonkey.
Flags: needinfo?(frgrahl)
Comment hidden (mozreview-request)

Comment 10

a year ago
mozreview-review
Comment on attachment 8946791 [details]
Bug 1434401 - Remove the "root-element" binding from :root and create the LightweightThemeConsumer directly from browser.js;

https://reviewboard.mozilla.org/r/216714/#review224784

::: browser/base/content/browser.js:1182
(Diff revision 2)
>  
>  var gBrowserInit = {
>    delayedStartupFinished: false,
>  
>    onDOMContentLoaded() {
> +    if (document.documentElement.hasAttribute("lightweightthemes")) {

Let's remove this attribute.

::: browser/base/content/browser.js:1183
(Diff revision 2)
>  var gBrowserInit = {
>    delayedStartupFinished: false,
>  
>    onDOMContentLoaded() {
> +    if (document.documentElement.hasAttribute("lightweightthemes")) {
> +      new LightweightThemeConsumer(document);

This seems oddly placed next to the very basic setup happening in onDOMContentLoaded. Any reason why you didn't put this in the onLoad method (e.g. grouped with the "Misc. inits.") other than that the xbl constructor probably ran pretty early too?
Attachment #8946791 - Flags: review?(dao+bmo) → review+
Priority: -- → P3
(Assignee)

Comment 11

a year ago
(In reply to Dão Gottwald [::dao] from comment #10)
> Comment on attachment 8946791 [details]
> Bug 1434401: Remove the "root-element" binding from :root and create the
> LightweightThemeConsumer directly from browser.js;
> 
> https://reviewboard.mozilla.org/r/216714/#review224784
> 
> ::: browser/base/content/browser.js:1182
> (Diff revision 2)
> >  
> >  var gBrowserInit = {
> >    delayedStartupFinished: false,
> >  
> >    onDOMContentLoaded() {
> > +    if (document.documentElement.hasAttribute("lightweightthemes")) {
> 
> Let's remove this attribute.

I did that at first but then realized that we load browser.js in hiddenWindow.xul (where we wouldn't want to apply the lwt). Although now that I read closer: onDOMContentLoaded / onLoad shouldn't actually fire in that case so I can remove the attribute.

> ::: browser/base/content/browser.js:1183
> (Diff revision 2)
> >  var gBrowserInit = {
> >    delayedStartupFinished: false,
> >  
> >    onDOMContentLoaded() {
> > +    if (document.documentElement.hasAttribute("lightweightthemes")) {
> > +      new LightweightThemeConsumer(document);
> 
> This seems oddly placed next to the very basic setup happening in
> onDOMContentLoaded. Any reason why you didn't put this in the onLoad method
> (e.g. grouped with the "Misc. inits.") other than that the xbl constructor
> probably ran pretty early too?

I put it there because I figured we'd want the lwt to be set up ASAP to avoid a FOUC. The XBL constructor should actually run before DOMContentLoaded (the documentElement gets accessed during the evaluation of browser.js when checking windowtype). I don't feel strongly about any of these but we could either:

1) Keep it in DOMContentLoaded
2) Move it into onLoad
3) Move it as inline execution

In (3) we'd keep the current behavior, but we'd want to keep the "lightweightthemes" attr so it didn't run in hiddenWindow.xul.
(In reply to Brian Grinstead [:bgrins] from comment #11)
> > >    onDOMContentLoaded() {
> > > +    if (document.documentElement.hasAttribute("lightweightthemes")) {
> > > +      new LightweightThemeConsumer(document);
> > 
> > This seems oddly placed next to the very basic setup happening in
> > onDOMContentLoaded. Any reason why you didn't put this in the onLoad method
> > (e.g. grouped with the "Misc. inits.") other than that the xbl constructor
> > probably ran pretty early too?
> 
> I put it there because I figured we'd want the lwt to be set up ASAP to
> avoid a FOUC. The XBL constructor should actually run before
> DOMContentLoaded (the documentElement gets accessed during the evaluation of
> browser.js when checking windowtype). I don't feel strongly about any of
> these but we could either:
> 
> 1) Keep it in DOMContentLoaded
> 2) Move it into onLoad
> 3) Move it as inline execution

I believe onLoad right now should run before the first paint, although this may change as a result of bug 1336227. I'd probably start with (2), and revert to (1) only if needed. If you want to keep it in DOMContentLoaded, please move it down after the more critical stuff.
Comment hidden (mozreview-request)
(Assignee)

Comment 14

a year ago
Switched it to onLoad and removed the "lightweightthemes" attribute
(Assignee)

Comment 15

a year ago
It looks like the lightweightthemes attribute is used in mail/ editor/ and suite/. You may want to either restore the root-element binding in comm-central, or move the LightweightThemeConsumer instantiation to JS as this patch does.
Flags: needinfo?(richard.marti)
(In reply to Brian Grinstead [:bgrins] from comment #15)
> It looks like the lightweightthemes attribute is used in mail/ editor/ and
> suite/. You may want to either restore the root-element binding in
> comm-central, or move the LightweightThemeConsumer instantiation to JS as
> this patch does.

Thank you for the info. I will check what way is better for us.
Flags: needinfo?(richard.marti)

Comment 17

a year ago
Pushed by bgrinstead@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/86af6b6108d8
Remove the "root-element" binding from :root and create the LightweightThemeConsumer directly from browser.js;r=dao,Gijs

Comment 18

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/86af6b6108d8
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox60: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 60

Updated

a year ago
Depends on: 1438504
(Assignee)

Updated

11 months ago
Depends on: 1447052
You need to log in before you can comment on or make changes to this bug.