Something like this maybe? The way this is fixed will have some impact on what I'm doing in bug 1348294.

Why can't we just remove the border-radius rule on OS X? Is there some reason we need all the other bits of this patch (and especially the DOM structure changes...) for this particular change that I'm not seeing?

(In reply to :Gijs from comment #2) > Why can't we just remove the border-radius rule on OS X? I think the <panelview> element would then cover the rounded corners of the panel itself. The panelview has a background color and no border-radius at the moment. If we additionally add a border-radius to the panelview elements, things will probably look ok. And if we go ahead with bug 1374749, we don't even need to set a background on the panelviews any more, so then the transparent background of the arrow panel would be completely visible in all its translucent glory. If we want to have nice transparency without bug 1374749, then things are a bit more complicated. My attempt to solve that problem was what led me to suggesting the approach in this patch, and I realize now that it's impossible to understand why I did what I did unless I explain what I had in mind for the transparency. My plan was to give the panelview elements a -moz-appearance: -moz-mac-arrowpanel-inner; which would clear everything behind its rectangle and render a translucent panel background. That way, subviews will "hide" what's inside the panel behind them (by erasing it), and at the same time, the window behind the panel would be slightly visible through the panel's transparent background. The problem with this approach is that we can only clear rectangles. If the panelview elements now render a slightly transparent background on top of the cleared rectangle, and this background has rounded corners, then the corners of the subview will look odd during the slide-in animation because the panel will have holes around the corner curve. Unfortunately I don't have a screenshot of this phenomenon at the moment. I'm not sure if my explanation makes sense without one, though. The idea of my patch was then to find a way to make -moz-appearance: -moz-mac-arrowpanel-inner only apply on a rectangle that does not cover the very top and very bottom of the panel, so that it doesn't erase the corners, and so that it doesn't need to render rounded corners itself. However, bug 1374749 would make this complexity unnecessary.

(In reply to Markus Stange [:mstange] from comment #3) > However, bug 1374749 would make this complexity unnecessary. Bug 1374749 will not be appearing on our roadmap very soon, I suspect, because it requires considerable changes to the markup & dimensions precalc. I'm not sure we'll be able to pull that animation off without a sync reflow. It'll also be animating two elements at the same time, depending on the strategy taken; if so, the chance of frame drop is higher. If we can make sure to animate only the container, than it'll be fine probably. All that needs some time to experiment and fiddle with.

From talking to Aaron, it sounds like we do want to fix bug 1374749, so my understanding is we could take a simpler patch here. That said, we should probably get to 1374749 sooner rather than later.

I fixed this in passing in https://hg.mozilla.org/integration/autoland/rev/862e0401146f because otherwise webextension tests complained, for everything except the overflow panel, because I got a bit lost trying to figure out why it was broken there, and in any case I had other fish to fry in that bug. I'm not sure why the corners are still square there off-hand, but either way I'll update the summary to be slightly more precise about what's left here.

Funny thing, fixing the overflow stuff here seems to also improve things for bug 1374509 for me.

Comment on attachment 8897390 [details] Bug 1374315 - fix CSS overflow:hidden in overflow panel and page action panel to fix rounded corners, https://reviewboard.mozilla.org/r/168706/#review174070

Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/1e7bcce37cfc fix CSS overflow:hidden in overflow panel and page action panel to fix rounded corners, r=mikedeboer

Verified on OSX.

Backed out for frequently failing browser-chrome's browser_ext_browserAction_popup_resize.js (bug 1373507): https://hg.mozilla.org/mozilla-central/rev/e365137fa61bfd729617ba1ebf9f1ed79facd1f2 Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=123306724&repo=autoland 17:43:58 INFO - 307 INFO TEST-PASS | browser/components/extensions/test/browser/browser_ext_browserAction_popup_resize.js | Browser height should increase (1425 > 175) - 17:43:58 INFO - 308 INFO TEST-PASS | browser/components/extensions/test/browser/browser_ext_browserAction_popup_resize.js | Window width should not change - 17:43:58 INFO - 309 INFO TEST-PASS | browser/components/extensions/test/browser/browser_ext_browserAction_popup_resize.js | Window height should increase (1425 > 560) - 17:43:58 INFO - Buffered messages finished 17:43:58 ERROR - 310 INFO TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_browserAction_popup_resize.js | Window height be less than the screen height (1425 < 1024) - 17:43:58 INFO - Stack trace: 17:43:58 INFO - chrome://mochitests/content/browser/browser/components/extensions/test/browser/browser_ext_browserAction_popup_resize.js:testPopupSize:255

(In reply to Sebastian Hengst [:aryx][:archaeopteryx] (needinfo on intermittent or backout) from comment #13) > Backed out for frequently failing browser-chrome's > browser_ext_browserAction_popup_resize.js (bug 1373507): > > https://hg.mozilla.org/mozilla-central/rev/ > e365137fa61bfd729617ba1ebf9f1ed79facd1f2 > > Failure log: > https://treeherder.mozilla.org/logviewer.html#?job_id=123306724&repo=autoland > > 17:43:58 INFO - 307 INFO TEST-PASS | > browser/components/extensions/test/browser/ > browser_ext_browserAction_popup_resize.js | Browser height should increase > (1425 > 175) - > 17:43:58 INFO - 308 INFO TEST-PASS | > browser/components/extensions/test/browser/ > browser_ext_browserAction_popup_resize.js | Window width should not change - > 17:43:58 INFO - 309 INFO TEST-PASS | > browser/components/extensions/test/browser/ > browser_ext_browserAction_popup_resize.js | Window height should increase > (1425 > 560) - > 17:43:58 INFO - Buffered messages finished > 17:43:58 ERROR - 310 INFO TEST-UNEXPECTED-FAIL | > browser/components/extensions/test/browser/ > browser_ext_browserAction_popup_resize.js | Window height be less than the > screen height (1425 < 1024) - > 17:43:58 INFO - Stack trace: > 17:43:58 INFO - > chrome://mochitests/content/browser/browser/components/extensions/test/ > browser/browser_ext_browserAction_popup_resize.js:testPopupSize:255 Kris, any idea *why* this change would break that test often-but-not-always? :-\

I can't say for sure without looking at it in detail, but it looks from the screenshot like the popup isn't immediately resizing to fit the view. The way that we currently calculate the max height of the popup contents is we take the initial height of the view (since that was always the minimum height in the menu panel) and add the initial distance from the bottom of the panel to the bottom of the screen to it. If the panel hasn't resized to fit the view at the point where we take that measurement, then we'll think we have much more vertical screen space than we actually do.

I can't reproduce the failures locally (on my win10 machine) at all, neither with debug or opt builds, so I am at a loss as to how to address the issue. Instead, I get timeouts because https://dxr.mozilla.org/mozilla-central/source/browser/components/extensions/test/browser/head.js#165-170 gets stuck in an infinite loop because the width of the window vs. browser is off by one on my (hidpi) machine. Fixing that, the test just always passes, even when run as part of the directory, and even when run with --run-until-failure, despite failing on 40% of pushes when this patch was in the tree (so presumably once every 5-10 test runs given the different incarnations of win7/win8 opt/pgo). Can we just disable this test? Do you think the failure actually indicates something is wrong with the patch, or just wrong with the test?

Pinged Kris about this on IRC. I'll disable the height vs. screen check and file a followup to investigate re-enabling it. Self-ni so I go do this on Monday.

Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/1559cabac7b6 fix CSS overflow:hidden in overflow panel and page action panel to fix rounded corners, r=mikedeboer

Tested this with today's nightly and the overflow panel has rounded corners on OSX 10.12. Updating the bug as verified-fixed.