Odd shadow appearance on context menu with DPI set to 200% or above
Categories
(Firefox :: Menus, defect, P1)
Tracking
()
People
(Reporter: RT, Assigned: enndeakin, NeedInfo)
References
(Blocks 1 open bug)
Details
(Whiteboard: [proton-context-menus] [proton-uplift])
Attachments
(4 files)
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
This is some rendering issue I think.
In high-dpi mode, the menupopup's border is drawn wider and shows up around the edges. This is more obvious if the border colour is changed to something more obvious. Making the border transparent or 0px doesn't seem to help though. In low-dpi mode, the border is not drawn.
When the border is moved from the inner arrowscrollbox to the popup instead, the high-dpi mode rendering looks correct, but in low-dpi mode the border is cut off.
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Comment 2•4 years ago
|
||
(In reply to Neil Deakin from comment #1)
When the border is moved from the inner arrowscrollbox to the popup instead, the high-dpi mode rendering looks correct, but in low-dpi mode the border is cut off.
Is there an overflow:hidden
rule on the parent that we can drop to avoid this, perhaps?
I originally thought that in the worst case, we could disable these shadows again if they're causing the issue, but your description makes it sound like the weird artifacts are actually us mis-drawing the border (rather than the shadow) on the menu - am I misunderstanding the issue?
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
The patch here improves the appearance by adding one pixel to the crop area and clearing the border on the popup properly. It seems to appear much better although there is a small white artifact in the lower-right corner, but is much less noticeable than the current appearance.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
bugherder |
Comment 7•4 years ago
|
||
please request uplift, this affects a11y due to high contrast mode (fixes 2 search visual bugs).
Assignee | ||
Comment 8•4 years ago
|
||
Comment on attachment 9215281 [details]
Bug 1704040, adjust border cropping computation on windows to better handle high dpi values, r=jmathies
Beta/Release Uplift Approval Request
- User impact if declined: Odd appearance on most menu popup borders when high-dpi or high-constrast mode is used. Affects Windows 10 only.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce: Cannot be tested automatically as it part of the border drawn by Windows. Can be manually testing with dpi >= 200.
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Cosmetic drawing issue
- String changes made/needed:
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Comment on attachment 9215281 [details]
Bug 1704040, adjust border cropping computation on windows to better handle high dpi values, r=jmathies
Approved for 89 beta 6, thanks.
Comment 10•4 years ago
|
||
bugherder uplift |
Comment 11•4 years ago
|
||
Hi,
While the shadow appearance has improved (no more 1px gap). The corner radius of the shadow seems to be different than the corner radius of the context menu. Please see screenshot for reference.
Comment 12•4 years ago
|
||
Updated•4 years ago
|
Comment 13•4 years ago
|
||
We do not reopen bugs with landed patches. Please discuss in matrix or slack how to resolve the issue you're seeing.
Comment 14•4 years ago
|
||
There are more details in comment #4, but the tl;dr is that after spending way more time than we’d like to admit, Engineering thinks this is as good as we can get it.
Comment 15•4 years ago
|
||
Reproduced the initial issue shown in comment 0 with both a 4k monitor set up at 200% scale and layout.css.devPixelsPerPx
set to 2.0 using an old Nightly build from 2021-04-09. Verified that using Firefox 89.0 and Latest Nightly 90.0a1 the shadow matches the screenshots from comments 11 and comment 12. Keeping in mind comment 14, I'll go ahead and mark this bug as verified fixed.
Description
•