RE how-much-to-constrain autocomplete-popups -- testcase 5 is an example to test whether these popups might be constrained to the iframe viewport (more restrictive) vs. the top-level viewport (less restrictive). Chrome seems to choose the less-restrictive of these options; it constrains them to the **top-level** viewport. Firefox doesn't constrain them at all. Two other notes: - on macOS (probably Windows too?), Firefox does seem to constrain `<select>` popups (in testcase 4) to the content area. I suspect that that's our intent, and that the Wayland-specific escaping that I noted is just an bug/special-case that we have with Wayland. - I tested Safari on macOS, and it seems to be "permissive" in all cases here, FWIW; they'll gladly let all of these popups (including `select`) escape the content area and overlap the browser UI (or stick off the bottom of the browser window).
Bug 1826622 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
RE how-much-to-constrain autocomplete-popups -- testcase 5 is an example to test whether these datalist autocomplete-popups might be constrained to the iframe viewport (more restrictive) vs. the top-level viewport (less restrictive). Chrome seems to choose the less-restrictive of these options; it constrains them to the **top-level** viewport. Firefox doesn't constrain them at all. Two other notes: - on macOS (probably Windows too?), Firefox does seem to constrain `<select>` popups (in testcase 4) to the content area. I suspect that that's our intent, and that the Wayland-specific escaping that I noted is just an bug/special-case that we have with Wayland. - I tested Safari on macOS, and it seems to be "permissive" in all cases here, FWIW; they'll gladly let all of these popups (including `select`) escape the content area and overlap the browser UI (or stick off the bottom of the browser window).