Inconsistent arrow panel shadows
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox87 | --- | fixed |
People
(Reporter: mstange, Assigned: mstange)
References
Details
Attachments
(1 file)
Steps to reproduce:
- Open a new browser window.
- Click the hamburger button in the new window.
- Look at the arrow panel's shadow.
- Click outside the panel to close it.
- Click the hamburger button again.
Expected results:
The shadow should look the same as before.
Actual results:
On second opening, the shadow looks darker and less soft.
This also happens for the toolbar overflow panel. It does not apply on some other panels.
The difference seems to be whether the panel is resized before it's opened.
It turns out that the hard dark shadow is actually the shadow style we explicitly set in AdjustShadowStyle
, and the soft shadow is the default from the system. On first opening, and on opening-after-resize, our override seems to fail and we get the default (softer) shadow.
So this means there are two things wrong:
- Our custom shadow style looks bad (too dark and too hard). These arrow panels all use
-moz-window-shadow-style: default
. - Our custom shadow override is brittle and doesn't work most of the time.
Assignee | ||
Comment 1•4 years ago
|
||
CGSSetWindowShadowAndRimParameters was interfering with the window's built-in
mechanism to update shadow styles. The shadowOptions API should be less brittle.
This also lets us get rid of the hardcoded window shadow parameters, which were
based on macOS Yosemite and which look out of place on Big Sur.
This patch also explicitly makes us only support different shadow types if the
window is a PopupWindow
. We effectively had the same behavior before, due to
the canBecomeKeyWindow
check.
This patch also changes how the default
style is treated: Rather than being
the style for a normal top-level window, it's now the style of a regular
menu/panel. Our arrow panels use default
, so this makes them look better.
The StyleWindowShadow::Sheet
value is unused and we now treat it as default.
Depends on D105708
Updated•4 years ago
|
Comment 3•4 years ago
|
||
bugherder |
Description
•