[Proton][Windows] add Windows native shadow back to context menu
Categories
(Firefox :: Menus, enhancement, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | fixed |
People
(Reporter: Gijs, Assigned: enndeakin)
References
(Blocks 1 open bug)
Details
(Whiteboard: [proton-context-menus])
Attachments
(2 files)
I believe Neil has a patch that would allow us to add a native shadow to the context menu again.
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 1•4 years ago
|
||
Neil, would you mind taking this / sharing your patch? :-)
Assignee | ||
Comment 2•4 years ago
|
||
I can work on this, but I don't have a patch yet. I just did hardcoded a quick test to see what it would look like.
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
So the existing style has the border radius on the arrowscrollbox not on the popup itself, meaning some manual finding of elements would be necessary. Is it possible to move the radius to the popup instead?
Also, border-radius supports a wide variety of options: different width/height, different values of each corner, etc. Do we care about handling any of this or should we just limit it and guess that whatever one corner is set to is the value for all of the corners? Although it is possible to create more complex shapes such as different borders at each edge with a dropshadow, the basic rounding rect Windows API for this (CreateRoundRectRgn) only handles a width and height that is the same for all four corners.
Or, should we just hard-code the 4 pixels directly , possibly using a special 'appearance' value to enable it, and not worry about making this more flexible?
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Neil Deakin from comment #3)
So the existing style has the border radius on the arrowscrollbox not on the popup itself, meaning some manual finding of elements would be necessary. Is it possible to move the radius to the popup instead?
I think so, though the border itself would then also want to move.
Also, border-radius supports a wide variety of options: different width/height, different values of each corner, etc. Do we care about handling any of this or should we just limit it and guess that whatever one corner is set to is the value for all of the corners? Although it is possible to create more complex shapes such as different borders at each edge with a dropshadow, the basic rounding rect Windows API for this (CreateRoundRectRgn) only handles a width and height that is the same for all four corners.
Or, should we just hard-code the 4 pixels directly , possibly using a special 'appearance' value to enable it, and not worry about making this more flexible?
At this point I think I'm happy to do whatever is easiest to implement. I would be fine with either completely hardcoding or reading the radius on one corner and assuming it's the same elsewhere. I don't think we should worry about more complex shapes or different values for different corners.
Assignee | ||
Comment 5•4 years ago
|
||
Assignee | ||
Comment 6•4 years ago
|
||
I spent a lot of time trying to get the border-radius on the popup instead of the inner box, but I couldn't seem to get it to render the rounded corners properly with the dropshadow. I don't want to spend more time on it so instead I hard-coded the size in nsWindow.cpp. The rendering looks ok, but there is still an issue with modified dpi values in that there is a thin white strip in the right and bottom sides.
Assignee | ||
Comment 7•4 years ago
|
||
The latest version is less hard-coded and puts the border radius on the menupopup, but the border is still drawn by the inner box.
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
Depends on D109833
Updated•4 years ago
|
Comment 10•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/39b38c8cd03b
https://hg.mozilla.org/mozilla-central/rev/4731fcb3e98b
Description
•