Closed Bug 1445787 Opened 3 years ago Closed 3 years ago
OS] Toolbar overflow menu broken after clicking an extension's browser action item (remote webextensions)
Steps to repro from a fresh macOS profile on current nightly. 1. Install https://addons.mozilla.org/en-US/firefox/addon/styl-us (it happens with others too, the link is just for convenience and since it's what I tried with) 2. Open toolbar customize ui, add the stylus button to the overflow menu, and then close the customize ui. 3. Click the overflow menu, and select stylus from the drop down. Result: the menu vanishes, you don't go to the stylus page, and the menu will never open again. Interestingly, the menu behaves somewhat as if it is open, and some items will still respond to clicks (if you add 'show sidebars' to the menu, and then the overflow menu, and click where 'show sidebars' would be had the menu been visible, the sidebar will appear).
Still need to look at this. Just in case you have time before me, Paolo, maybe you know what's going on here?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(paolo.mozmail)
Seems this was caused by bug 1385403. https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3eef48c0a0d9530f463d4f38dfc271925ca4d5d6&tochange=79044302abd1165ed375708201090281972d32d8 The good news is that although that landed before the merge, it's disabled on release and beta.
Has Regression Range: --- → yes
Has STR: --- → yes
Component: Toolbars and Customization → WebExtensions: General
Product: Firefox → Toolkit
Summary: Toolbar overflow menu broken after clicking an extension's browser action item → [macOS] Toolbar overflow menu broken after clicking an extension's browser action item (remote webextensions)
(I'm assuming the same problem doesn't reproduce on Windows with remote webextensions, in which case there may be a different regression window there, but I haven't had a chance to test this. I did verify that on macOS, you can "fix" the issue locally by flipping the extensions.webextensions.remote pref)
(In reply to :Gijs from comment #2) > Seems this was caused by bug 1385403. That's not entirely surprising. When we load a remote extension view, we change the way that we render the popup: https://searchfox.org/mozilla-central/rev/6e96a3f1e44e286ddae5fdafab737709741d237a/layout/xul/nsMenuPopupFrame.cpp#2303-2308 That works as expected on Windows, but it might cause problems on OS-X. I think Markus may have to look into this one. My knowledge of how we handle popup compositing on OS-X is not great.
Flags: needinfo?(kmaglione+bmo) → needinfo?(mstange)
I'm going to take a look.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Comment on attachment 8966367 [details] Bug 1445787 - Correctly set the initial size of the ChildView we create for the popup contents. https://reviewboard.mozilla.org/r/235054/#review240802
Attachment #8966367 - Flags: review?(spohl.mozilla.bugs) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/0d9149c03ebc Correctly set the initial size of the ChildView we create for the popup contents. r=spohl
Issue was reproduced on Firefox 60.0a1 (20180201100326). Retested and verified in Firefox 60.0a1 (20180424013604) on Mac OS 10.13.3.
Updated version and gif. Issue was reproduced on Firefox 60.0a1 (20180201100326). Retested and verified in Firefox 61.0a1 (20180424013604) on Mac OS 10.13.3.
Attachment #8970476 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.