2033234 - Background tab datalist popup can appear in the foreground tab

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Tomoya Nakanishi]

Platform: Desktop
Version: Nightly 151.0a1 (2026-04-17)

Calling showPicker() on an <input> associated with a <datalist> can open Firefox's own autocomplete-style popup even after the originating tab has moved to the background. A page in tab A can receive a normal user gesture, schedule input.showPicker() with a short delay, and let the user switch to tab B before the delay expires. When the delayed call runs, Firefox shows the popup on top of the selected foreground tab, even though tab B did not request the popup.

Steps to Reproduce:

1. Save the two files below as tab-a.html and tab-b.html in the same directory.
2. Serve that directory over HTTP. For example:
   python3 -m http.server 8000
3. Open http://a.localhost.ntomoya.com:8000/tab-a.html in tab A and http://b.localhost.ntomoya.com:8000/tab-b.html in tab B of the same Firefox window.
4. Switch back to tab A.
5. Click the "Arm background popup" button in tab A and immediately switch to tab B before 500 ms elapse.
6. Observe that after roughly 500 ms, Firefox displays a normal autocomplete/datalist popup containing attacker-controlled strings on top of tab B, even though tab B did not request the popup and is cross-origin to tab A.

Security Impact:
A background tab can cause Firefox to display a trusted browser-owned popup over an unrelated foreground tab. The popup contents are attacker-controlled datalist strings, so a malicious site can inject misleading UI that looks like Firefox-provided autocomplete suggestions in the wrong tab context.

Comment 1

[Tomoya Nakanishi]

Attachment: demo.mp4

Comment 2

[Tomoya Nakanishi]

Attachment: tab-a.html

Comment 3

[Tomoya Nakanishi]

Attachment: tab-b.html

Comment 4

[Jan Jaeschke [:jjaschke]]

Hi Vincent, I think you have worked on this. Could you take a look?

Comment 5

[Vincent Hilla [:vhilla]]

Attachment: (secure)

Comment 6

[Vincent Hilla [:vhilla]]

This was implemented in bug 1767228, I think we can use BC::CanOpenModalPicker that was introduced in bug 1837963 and would make the code more consistent.

Comment 7

[Vincent Hilla [:vhilla]]

SelectParent.sys.mjs has an open method that checks

      if (tabbrowser && tabbrowser.selectedBrowser != browser) {
         // AsyncTabSwitcher might delay activating our browser, check
         // explicitly for tabbrowser.
         return false;
       }

This comes from bug 1909535 and I wonder whether AutoCompleteParent should have that check too in addition to BC::CanOpenModalPicker.

I couldn't get bug 1909535 to reproduce with a datalist picker though. Opening a new window causes a blur event that causes nsFormFillController to StopControllingInput. To get the picker to open and remain open on another page, one has to call showPicker after blur has fired, meaning CanOpenModalPicker would be false due to a lack of focus.

But this does seem a bit fragile, adding the check is harmless, and having the check in both places is more consistent.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a91851cbc2da
https://hg.mozilla.org/integration/autoland/rev/e76f2fc3d9fe
Use BC::CanOpenModalPicker for all picker. r=edgar,firefox-desktop-core-reviewers ,Gijs,extension-reviewers,robwu,devtools-reviewers,nchevobbe

Comment 9

[Vincent Hilla [:vhilla]]

Issue was introduced by bug 1767228, shipped by bug 1998668 in 149. I verified the issue reproduces in release.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e76f2fc3d9fe