The user activation state isn't propagted to nsDocShellLoadState for the load triggered by `window.open()`
Categories
(Core :: DOM: Navigation, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox130 | --- | fixed |
People
(Reporter: edgar, Assigned: edgar)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
We found this issue while working on Text Fragment (Bug 1888756).
window.open()
will consume the user activation if the popup blocker is enabled. However, the nsDocShellLoadState
is built after that, so it always ends up having mHasValidUserGestureActivation
set to false
. The popup blocker is disabled by default while running automation tests, so we didn't catch this issue during testing. And since only the Sec-Fetch-User
use that currently, it is not easily noticeable by users. And the Text Fragment has made this issue emerge.
Assignee | ||
Updated•4 months ago
|
Assignee | ||
Comment 1•3 months ago
|
||
Assignee | ||
Comment 2•3 months ago
|
||
Assignee | ||
Comment 3•3 months ago
|
||
nsWindowWatcher::OpenWindowInternal
takes both a URL string and nsDocShellLoadState
as argument. In most of cases, caller passes null
for nsDocShellLoadState
and
nsWindowWatcher::OpenWindowInternal
creates it lazily with the nsIURI
which is
converted frome the URL string. The only place that passes both non-void URL string
and non-null nsDocShellLoadState
is in nsDocShell::PerformRetargeting
, see
https://searchfox.org/mozilla-central/rev/e74b86533c2499eb6393071aeedcfb080d84e4da/docshell/base/nsDocShell.cpp#8409.
The passed URL string is converted from the URI of the passed nsDocShellLoadState
,
so they are actually equal. Therefore, the code for replacing URI is redundant.
Assignee | ||
Comment 4•3 months ago
|
||
Depends on D215426
Assignee | ||
Comment 5•3 months ago
|
||
Updated•3 months ago
|
Updated•3 months ago
|
Comment 7•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/49087840a161
https://hg.mozilla.org/mozilla-central/rev/5e76d2196972
Description
•