Consider disallowing opening a picker from a background page
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: edgar, Assigned: edgar)
References
Details
(Keywords: csectype-spoof, sec-want, Whiteboard: [adv-main136-])
Attachments
(3 files)
(This is split from bug 1828276 comment #8)
I think we should not allow a background page can open a picker and even switch itself to foreground. It's worth to check how other browser behave. However, in general, open a picker requires a user gesture, so blocking a background page from opening a picker should not cause web compatibility problem. Because in most of case "a-background-page == no-user-gesture", unless user interact with the page, switch it to background then tries to open a picker, and expect that work, but I think that is a very corner case.
This is from a fullscreen sec bug, though we have a solution for that, bug 1821884, but not sure if opening-pickers-from-background might cause other bugs, so file this bug for tracking and mark as a sec bug, too.
Comment 1•2 years ago
|
||
I'm not sure what this bug is tracking, which leaves me unsure what security rating to give it. Blocking pickers-from-background in cases other than fullscreen? Tracking regressions ("might cause other bugs") from bug 1821884? The "edge case" of opening something from a page and then switching focus to another window/tab before the picker can open? That last one is known to be exploitable on mobile, at least.
| Assignee | ||
Comment 2•2 years ago
|
||
This bug is created to track potential issues of opening-pickers-from-background other than fullscreen.
(In reply to Daniel Veditz [:dveditz] from comment #1)
The "edge case" of opening something from a page and then switching focus to another window/tab before the picker can open? That last one is known to be exploitable on mobile, at least.
Do we have a bug on mobile?
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
|
||
| Assignee | ||
Comment 5•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 7•1 year ago
|
||
Backed out for causing build bustages on nsColorPicker.cpp:
https://hg.mozilla.org/integration/autoland/rev/ec9441f956a20c64d517c8cc84f40149939d71ba
[task 2025-01-14T13:08:12.807Z] 13:08:12 ERROR - /builds/worker/checkouts/gecko/widget/gtk/nsColorPicker.cpp:97:15: error: use of undeclared identifier 'aColorPickerShownCallback'
[task 2025-01-14T13:08:12.807Z] 13:08:12 INFO - 97 | mCallback = aColorPickerShownCallback;
[task 2025-01-14T13:08:12.807Z] 13:08:12 INFO - | ^
| Assignee | ||
Updated•1 year ago
|
Comment 9•1 year ago
|
||
Backed out for causing build bustages
Backout link: https://hg.mozilla.org/integration/autoland/rev/2bd4c737942733221ce01f49c6995e9cd5122700
Comment 10•1 year ago
|
||
Comment 11•1 year ago
|
||
https://hg.mozilla.org/mozilla-central/rev/7907d00425fb
https://hg.mozilla.org/mozilla-central/rev/a4ef712fa44d
https://hg.mozilla.org/mozilla-central/rev/e49da4b8b2d0
Comment 12•1 year ago
|
||
:edgar I see this is a sec want, do we need to uplift this to beta and esr128?
Comment 13•1 year ago
|
||
I'd rather let this get some bake time rather than uplifting to Beta in the last week of the cycle. Not super concerned about ESR either, but leaving that option open for now until Edgar has a chance to reply.
| Assignee | ||
Comment 14•1 year ago
|
||
Not super concern about ESR, either. And I would like this get some bake time on Beta/Release.
Updated•11 months ago
|
Comment 15•11 months ago
|
||
I noticed that the behavioral change introduced here does not have any test coverage.
Since the patches have caused a regression (bug 1949092), I decided to not only add test coverage for the regressed functionality, but also a simple test case for the common case (a tab browser), at https://phabricator.services.mozilla.com/D238843 (as test_canOpenModalPicker_in_tab).
Updated•11 months ago
|
Updated•11 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Description
•