Closed Bug 1470870 Opened 6 years ago Closed 6 years ago

Load "menu.css" as a document stylesheet

Categories

(Toolkit :: Themes, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: Paolo, Assigned: Paolo)

References

(Depends on 1 open bug)

Details

Attachments

(2 files)

This is part of the work tracked in bug 1470830.
I expect this will resurface Bug 1429857 (originally filed as Bug 1420229), which is what prompted us to do the move to UA sheets in the first place. Can you double check that it reproduces still and then look to see if there's a more permanent fix than what we landed before migrating to UA and ultimately reverted once it wasn't needed anymore: https://hg.mozilla.org/mozilla-central/rev/05bab8e59cd1?
More platform weirdness. This patch is on top of the one that loads the "widgets.css" stylesheet through "global.css", without modifying the style cache, and I decreased the specificity of one rule in "menu.css" to fix the Windows issue with the menu of the non-default Bookmarks button in the toolbar.

While this works for some rules, the one in the screenshot has a strange issue. I'm seeing an inconsistent state in the computed rules view, and the later rule is in fact not applied. What is happening here?
Assignee: nobody → paolo.mozmail
Status: NEW → ASSIGNED
Flags: needinfo?(emilio)
Note that increasing the specificity of the later rule does make "-moz-appearance" apply.
Also, the order is applied correctly for "padding-top" with the same selectors in the same files.
Which element do I need to inspect to see that Paolo?
Flags: needinfo?(emilio) → needinfo?(paolo.mozmail)
Ah, sorry for not mentioning that earlier! On a Windows build, you need to add the Bookmarks button to the toolbar, for example using "Library > Bookmarks > Bookmarking Tools > Add Bookmarks Menu to Toolbar", then in the menu you can look for one of the "menuitem" elements and inspect the ".menu-iconic-left" box, which contains the icon image but is not the icon image itself.
Flags: needinfo?(paolo.mozmail) → needinfo?(emilio)
I've split "menulist" to bug 1471544.
Summary: Load "menu.css" and "menulist.css" as document stylesheets → Load "menu.css" as a document stylesheet
This is working as expected, the sheets in that page are:

Array.from(document.styleSheets).map(s => s.href).join(", ")

> "chrome://browser/content/browser.css, chrome://browser/content/downloads/downloads.css, chrome://browser/content/places/places.css, chrome://browser/content/usercontext/usercontext.css, chrome://browser/skin/controlcenter/panel.css, chrome://browser/skin/customizableui/panelUI.css, chrome://browser/skin/downloads/downloads.css, chrome://browser/skin/searchbar.css, chrome://browser/skin/places/places.css, chrome://browser/skin/places/editBookmark.css, chrome://browser/skin/browser.css, chrome://browser/content/tabbrowser.css, chrome://browser/skin/compacttheme.css"

menu.css is imported via widgets.css, which is imported via global.css, which is imported via chrome://browser/skin/browser.css, that is, comes after panelUI.css, so given they have the same specificity, the rule in menu.css wins, and thus appearance computes to menuimage.

Also, getComputedStyle(temp0).paddingTop is 2px in my build (though it's a Linux build with the Windows rule copied over), fwiw.

So I'm not sure what the computed view is doing, but it's not doing it right. You can see the ordered rules that match an element with InspectorUtils.getCSSStyleRules(element). There, for that element, the rules are (one per line):

InspectorUtils.getCSSStyleRules(temp0).map(r => r.cssText).join("\n")

> * { -moz-user-focus: ignore; -moz-user-select: none; display: -moz-box; box-sizing: border-box; }
.menu-text, .menu-iconic-left, .menu-iconic-right, .menu-iconic-text { margin-top: 0px !important; margin-bottom: 0px !important; margin-inline-start: 0px !important; margin-inline-end: 2px !important; color: inherit; }
.menu-iconic-left, .menu-iconic-right { width: 16px; padding-inline-end: 3px !important; }
.subviewbutton > .menu-right, .subviewbutton > .menu-accel-container > .menu-iconic-accel, .subviewbutton > .menu-iconic-left, .subviewbutton > .menu-iconic-text { padding-bottom: 0px; padding-top: 0px; }
.subviewbutton > .menu-iconic-left { -moz-appearance: none; margin-inline-end: 0px; }
.menu-iconic > .menu-iconic-left, .menuitem-iconic > .menu-iconic-left { -moz-appearance: menuimage; padding-top: 2px; }
#BMB_bookmarksPopup .subviewbutton > .menu-iconic-left { margin-inline-end: 3px; }


Which makes sense, looking at the sheets they come from :)
Flags: needinfo?(emilio)
Thanks Emilio for the help with debugging! I'll file a developer tools bug.

What made this even more confusing is that "getComputedStyle(temp0).paddingTop" is zero for me because of some effect of "-moz-appearance: menuimage", apparently on Windows only.
Depends on: 1471960
Depends on: 1421433
Comment on attachment 8987481 [details]
Bug 1470870 - Load "menu.css" as a document stylesheet.

https://reviewboard.mozilla.org/r/252728/#review261318

::: toolkit/themes/windows/global/menu.css:93
(Diff revision 2)
>  .menu-iconic-icon {
>    width: 16px;
>    height: 16px;
>  }
>  
> -menu.menu-iconic > .menu-iconic-left,
> +.menu-iconic > .menu-iconic-left,

Is this change still needed after bug 1421433?
Attachment #8987481 - Flags: review?(bgrinstead) → review+
(In reply to Brian Grinstead [:bgrins] from comment #14)
> > -menu.menu-iconic > .menu-iconic-left,
> > +.menu-iconic > .menu-iconic-left,
> 
> Is this change still needed after bug 1421433?

Yes, and it now behaves as expected, being overridden by the browser rules.
I looked into the screenshot differences in the Preferences window on Linux, and fixed other cases where the "xul|groupbox xul|label:not(...)" rule was applied to too many inner labels.

Still, this only applied in part because it was overriden by the following "!important" rule in the UA stylesheet:

.menu-iconic-accel { margin-inline-start: 7px !important; }

I'll run new screenshots with the fix, and I expect them to show small differences where we are restoring the behavior we had when these were XBL stylesheets.
Pushed by paolo.mozmail@amadzone.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/953772c799a6
Load "menu.css" as a document stylesheet. r=bgrins
https://hg.mozilla.org/mozilla-central/rev/953772c799a6
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Depends on: 1474631
I think Bug 1474631 was likely caused by global.css not being loaded somewhere, like https://searchfox.org/mozilla-central/source/browser/base/content/webext-panels.xul. We saw  asimilar issue with about:config on first landing (bug 1420166).
Pushed by paolo.mozmail@amadzone.org:
https://hg.mozilla.org/integration/mozilla-inbound/rev/aeb4179d5adc
Load "menu.css" as a document stylesheet. r=bgrins
That was it.
https://hg.mozilla.org/mozilla-central/rev/aeb4179d5adc
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Depends on: 1477897
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: