Almost invisible separators in the context menu of a downloaded item in the Library when dark theme is enabled
Categories
(Firefox :: Toolbars and Customization, defect, P3)
Tracking
()
People
(Reporter: itiel_yn8, Assigned: itiel_yn8)
References
(Regression)
Details
(Keywords: regression)
Attachments
(6 files)
This is a regression caused by bug 1453722.
STR:
- New profile, enable dark theme
- Download any file
- Click the Downloads icon on the toolbar > right click the downloaded item > observe separators color and style -- expected
- Click the Library icon > Downloads > right click the downloaded item > observe separators color and style -- bad
There are actually 2 issues here:
- The separators are almost invisible -- this is regression from bug 1453722
- Their style is not the same as other separators in the Firefox UI (not so much padding before and after) -- this goes back to when the Downloads section was first introduced in the Library
See attached.
Comment 2•6 years ago
|
||
Bug 1453722 just changed --panel-separator-color. The problem here is that this color shouldn't be used in the first place in the natively styled context menu.
I think there are two ways to approach this (short of making context menus dark which we'll likely do at some point). The first one would be to somehow exclude the context menu here:
The other option would be to put panelDownloadsContextMenu in mainPopupSet instead of the panel.
Comment 3•6 years ago
|
||
Felipe, do you think we should be tracking this for 66 uplift?
Comment 4•6 years ago
|
||
If you are able to land a fix soon it can still make it into tomorrow's beta build. Past that I don't really want to uplift.
Comment 5•6 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #2)
The other option would be to put panelDownloadsContextMenu in mainPopupSet instead of the panel.
This (having a context menu for a panel that is not inside that panel in the DOM structure) has historically caused flickering issues on Windows classic.
Comment 6•6 years ago
|
||
Since the regression is from 62, I don't think we need to track it for 66 or worry about uplifting.
Comment 7•6 years ago
|
||
(In reply to :Gijs (he/him) from comment #5)
(In reply to Dão Gottwald [::dao] from comment #2)
The other option would be to put panelDownloadsContextMenu in mainPopupSet instead of the panel.
This (having a context menu for a panel that is not inside that panel in the DOM structure) has historically caused flickering issues on Windows classic.
I'll move this then since it seems that the fix isn't going to be download panel specific. Probably still a P3 but I'll reset the priority to be sure.
I wonder if we should use the child selector here, or if this would miss separators that this rule wants to match:
Comment 8•6 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #7)
I wonder if we should use the child selector here, or if this would miss separators that this rule wants to match:
I think there's probably .panel-subview-body
things in the way in some cases, and in the bookmarks menu button I don't know if we set these classes on the submenus (ie nested bookmark folders etc.) as well.
I think the only menuseparator
items we want to affect here are going to be in the bookmarks menu button. I'd be fine with making the menuseparator rules specific to that. Does that sound like it'd work?
Comment 9•6 years ago
|
||
(In reply to :Gijs (he/him) from comment #8)
(In reply to Dão Gottwald [::dao] from comment #7)
I wonder if we should use the child selector here, or if this would miss separators that this rule wants to match:
I think there's probably
.panel-subview-body
things in the way in some cases,
That alone doesn't sound like a problem, as the selectors could just include that. The previous selector already is #widget-overflow-mainView > .panel-subview-body > toolbarseparator
. Perhaps we could just drop #widget-overflow-mainView >
from that?
I think the only
menuseparator
items we want to affect here are going to be in the bookmarks menu button. I'd be fine with making the menuseparator rules specific to that. Does that sound like it'd work?
Or use menupopup.PanelUI-subView there?
Updated•6 years ago
|
Comment 10•6 years ago
|
||
So just adding the class (.PanelUI-subView) doesn't help, because we don't set that class on the submenus.
In fact, the styling for the submenus looks noticeably broken on mac, because the submenu items don't get moz-appearance: none anymore. I'll see if I can find a regression window for that tomorrow or if I'm just imagining that it used to work that way...
Comment 11•6 years ago
|
||
(In reply to :Gijs (he/him) from comment #10)
So just adding the class (.PanelUI-subView) doesn't help, because we don't set that class on the submenus.
In fact, the styling for the submenus looks noticeably broken on mac, because the submenu items don't get moz-appearance: none anymore. I'll see if I can find a regression window for that tomorrow or if I'm just imagining that it used to work that way...
This seems to have regressed when we wrote photon, and I guess isn't super important if we still haven't fixed it.
Updated•6 years ago
|
Updated•5 years ago
|
Comment hidden (off-topic) |
Comment hidden (off-topic) |
Comment hidden (off-topic) |
Comment hidden (off-topic) |
Comment hidden (off-topic) |
Assignee | ||
Comment 17•5 years ago
|
||
Updated•5 years ago
|
Comment 18•5 years ago
|
||
Comment 19•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•3 years ago
|
Description
•