Open
Bug 1482157
Opened 6 years ago
Updated 2 years ago
Add new CSS property to define where macOS sheets should be attached
Categories
(Core :: Widget: Cocoa, enhancement, P3)
Core
Widget: Cocoa
Tracking
()
NEW
People
(Reporter: ntim, Unassigned)
References
Details
Right now, this is being defined by whatever element has -moz-appearance: toolbox; which is not ideal, because -moz-appearance also gets rid of custom backgrounds/borders.
Comment 1•6 years ago
|
||
We will need to change https://searchfox.org/mozilla-central/rev/2466b82b729765fb0a3ab62f812c1a96a7362478/widget/cocoa/nsChildView.mm#2557 to find an element based on different criteria than -moz-appearance:toolbox. Perhaps an attribute or className would work, such as [mac-sheet-anchor].
Updated•6 years ago
|
Whiteboard: [blocking-static-themes-fx]
Comment 2•6 years ago
|
||
Markus, is this something you could help with (or at least provide some pointers)? Tim and I talked about this but it relies on ThemeGeometries which as I understand it is only related to -moz-appearance.
Flags: needinfo?(mstange)
Comment 3•6 years ago
|
||
Getting this fixed is a very high priority for the add-ons team as it blocks a P1 bug related to static themes.
Comment 4•6 years ago
|
||
(In reply to (away 8/20-8/27) Jared Wein [:jaws] (please needinfo? me) from comment #2)
> Markus, is this something you could help with (or at least provide some
> pointers)? Tim and I talked about this but it relies on ThemeGeometries
> which as I understand it is only related to -moz-appearance.
That's right, and it's going to be a bit of work to implement a separate mechanism to track a sheet-attachment edge. We do something similar for the window dragging region; from a quick glance, we may need to instrument the same places as the ones that call AdjustWindowDraggingRegion for this: https://searchfox.org/mozilla-central/search?q=symbol:_ZN20nsDisplayListBuilder26AdjustWindowDraggingRegionEP8nsIFrame&redirect=false
I think this is more complicated than initially anticipated, and I don't really have cycles for this.
May I suggest a CSS-only workaround? There's a gray line at the bottom of the toolbox that's implemented with a generated content pseudo element. Could we set -moz-apperance: toolbox on that, and since that will get rid of the border, implement the border as an inset box-shadow?
Something like this:
#navigator-toolbox::after {
height: 1px;
border: none;
box-shadow: inset 0 -1px var(--toolbox-border-bottom-color); /* use inset box-shadow instead of border because -moz-appearance hides the border */
-moz-appearance: toolbox; /* declares this element's bottom edge as the sheet attachment position */
}
Flags: needinfo?(mstange) → needinfo?(ntim.bugs)
Reporter | ||
Comment 5•6 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #4)
> #navigator-toolbox::after {
> height: 1px;
> border: none;
> box-shadow: inset 0 -1px var(--toolbox-border-bottom-color); /* use inset
> box-shadow instead of border because -moz-appearance hides the border */
> -moz-appearance: toolbox; /* declares this element's bottom edge as the
> sheet attachment position */
> }
Not very elegant, but sounds fine enough to unblock static themes on AMO.
Flags: needinfo?(ntim.bugs)
Updated•6 years ago
|
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•