When rendering a <select> dropdown menu in a WebExtension popup, on the first click, the options list renders off to the right, which is surprising.

Upon second click, it renders in the expected place under/over the select element.

1. Install https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/
2. On any web page, click its toolbar button.
3. Click its select element. Observe the native options menu rendering off to the right.
4. Close it, and click it another time. Observe it now rendering in the expected place toward the bottom.

The bug is consistently reproducible in Firefox 92 on macOS and on Linux.

The code is simple and open at: https://github.com/wikimedia/WikimediaDebug/blob/2.4.3/popup.html#L15

I have tried to reproduce this on a standalone webpage:
https://codepen.io/Krinkle/pen/ExXGWPY

However, it does not appear to happen there. As such, I suspect this may be related to how WebExtension popups are rendered, and how their dimensions are automatically determined and cropped in some way.

This standalone version uses an artificial 1s delay for its JS code, as I suspected that maybe the bug is related to the menu options being changed by JS. However, even with the artifical delay and clicking it early, to then have the JS change it while open, does not cause the bug.

I have also tried to reproduce this by creating a popup using window.open() as a way to make Firefox render a window at roughly the size of a webextension popup (since normal windows cannot be resized that small). The bug does not happen there either.

May be related to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1413099 (bug 1413099)
https://bugzilla.mozilla.org/show_bug.cgi?id=1582103 (bug 1582103)
https://bugzilla.mozilla.org/show_bug.cgi?id=1709000 (bug 1709000)

I can repro, on Linux+Wayland behavior is even more erratic tbh. I'll try to poke and see if it's the front-end what's giving widget a bogus position, or something else.

This is bug 1696718. That fix wasn't quite correct.

Bug 1696718 landed a fix to propagate the position change from layout.
However that's not correct, because the widget isn't resized until
nsView::ProcessPendingUpdatesForView is resized (and even that in some
platforms it might be async).

So the right place to propagate the position change is in
nsXULPopupManager (which we call into from the view system which listens
itself to the widget).

Let's try to enable the test for that bug everywhere with this fixed.

Hiro, what are you doing to reproduce https://phabricator.services.mozilla.com/D127801#4154525? It works just fine for me on both X and XWayland (on wayland it doesn't work but that seems like a separate wayland bug)

I just did same setup described in bug 1696718 comment 0. Did you enable Fission? It's a key factor to reproduce the issue I saw.

I see, I did not, will try again. This bug happens without fission.

I wonder why fission is relevant in that code, huh.

I could repro that and that happens after this patch because some popup moves by the window manager don't end up going through the popup manager. For now I kept a call where it is too so that it doesn't regress on Linux+Fission.

https://hg.mozilla.org/mozilla-central/rev/76a0d606b755