Use standard anchored popup for the result menu on Mac
Categories
(Firefox :: Address Bar, task, P3)
Tracking
()
People
(Reporter: dao, Assigned: sam)
References
Details
(Whiteboard: [sng][search-tech-debt])
Attachments
(1 file)
Updated•2 years ago
|
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Not sure I agree. I haven't tested either of those patches -- do they make non-native menus look exactly like native Mac menus? If so then great. If not, I don't want to replace a nice native menu with an uncanny value simulation.
| Reporter | ||
Comment 2•2 years ago
|
||
(In reply to Drew Willcoxon :adw from comment #1)
Not sure I agree. I haven't tested either of those patches -- do they make non-native menus look exactly like native Mac menus? If so then great.
It's likely not pixel-perfect, but it should be so close that ordinary users wouldn't be able to tell the difference.
If not, I don't want to replace a nice native menu with an uncanny value simulation.
But that's how most of our UI works these days. Working around this on the basis of individual widgets when our native simulation falls short doesn't scale. Instead we should continue to make efforts like bug 1858349 and bug 1861671 so that all instances can benefit.
That said, I'm not sure if any of the layout/ and widget/ changes from https://phabricator.services.mozilla.com/D177355 should also be reverted. mstange?
Comment 3•1 year ago
|
||
I agree that the non-native popup looks close enough these days that users wouldn't notice the difference much, so I am fine with removing this special case.
And then bug 1710459 will make it use a native popup again, if it ever gets done.
| Assignee | ||
Comment 5•1 month ago
|
||
After bug 1710459, openPopup(anchor) uses a native menu on macOS, so this workaround is no longer required and can be removed.
Updated•1 month ago
|
Updated•1 month ago
|
Updated•20 days ago
|
Description
•