window.name discard in case of set document.domain in script
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | wontfix |
firefox-esr102 | --- | wontfix |
firefox95 | --- | wontfix |
firefox96 | --- | wontfix |
firefox97 | --- | wontfix |
firefox98 | --- | wontfix |
firefox99 | --- | wontfix |
firefox100 | --- | wontfix |
firefox101 | --- | wontfix |
firefox102 | --- | wontfix |
firefox103 | --- | wontfix |
firefox104 | --- | wontfix |
firefox105 | --- | fixed |
People
(Reporter: ugalnikov, Assigned: timhuang)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
Steps to reproduce:
- Update firefox to v.95.0
- Set document.domain and window.name in script as in attached file (or use attached file)
- Open browser and reset settings to default
- Open attached html on localhost (we use django framework)
- Refresh page.
- After refreshing page window.name will be equal to set in script
- Close and open browser again
- Open attached html on localhost
- Refresh page
- After each refreshing window.name will be EMPTY STRING (NOT EXPECTED)
- If reset firefox settings, window.name won't reset after each page refreshing
- After reopen browser window.name will reset to empty string every time
We set document.domain on pages for using javascript from different sub-domains correctly. Also we use window.name in our code and we expect that window.name won't reset after page refreshing on the same domain.
Actual results:
EMPTY window.name after each page refreshing on v.95.0 after reopen browser in case of document.domain set in script
Expected results:
window.name should be the same as set before refreshing
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Updated•2 years ago
|
Comment 2•2 years ago
|
||
I could not reproduce this with fission disabled.
(In reply to Edgar Chen [:edgar] from comment #2)
I could not reproduce this with fission disabled.
Could I prevent window.name discarding with any settings in firefox?
Comment 4•2 years ago
|
||
I got the following regression window by running mozregression with fission enabled,
69:39.06 INFO: Last good revision: 559529d56050a814a637f63b085ff383bc4fcbe8
69:39.06 INFO: First bad revision: bc08003d6b4ce7aee5998a20a2ce5b7fdd45667c
69:39.06 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=559529d56050a814a637f63b085ff383bc4fcbe8&tochange=bc08003d6b4ce7aee5998a20a2ce5b7fdd45667c
Seems like a regression of bug 1685807.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 5•2 years ago
|
||
Set release status flags based on info from the regressing bug 1685807
Updated•2 years ago
|
Are there any chances that the bug will be fixed in release 97? I wonder to know why this problem won't be resolved to the next release. Thanks for supporting.
Assignee | ||
Comment 7•2 years ago
|
||
According to Bug 1687029 comment 1, Fission doesn't follow HTML spec when dealing with about:blank pages. This might be the reason why this issue only happens when Fission is enabled.
You can disable the window.name resetting by turning off the pref privacy.window.name.update.enabled
. This can be a workaround.
Comment 8•2 years ago
|
||
The severity field is not set for this bug.
:edgar, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 9•2 years ago
|
||
The severity field is not set for this bug.
:farre, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 10•2 years ago
|
||
(In reply to Tim Huang[:timhuang] from comment #7)
You can disable the window.name resetting by turning off the pref
privacy.window.name.update.enabled
. This can be a workaround.
This report sounds like a web developer hitting an issue with a site under development. Recommending a pref flip doesn't seem like a valid workaround to be suggesting in this case. Can we try to bump the priority here?
Comment 11•2 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)
(In reply to Tim Huang[:timhuang] from comment #7)
You can disable the window.name resetting by turning off the pref
privacy.window.name.update.enabled
. This can be a workaround.This report sounds like a web developer hitting an issue with a site under development. Recommending a pref flip doesn't seem like a valid workaround to be suggesting in this case. Can we try to bump the priority here?
Henri, NI you here as this is a suspicious about:blank issue.
FWIW, I'm taking a build from https://bugzilla.mozilla.org/show_bug.cgi?id=1736570#c77 and the build seemed to fix this issue.
A shippable build from https://bugzilla.mozilla.org/show_bug.cgi?id=1736570#c79 does not fix this. I'll see if going back to to the older revision helps.
(In reply to Henri Sivonen (:hsivonen) from comment #12)
A shippable build from https://bugzilla.mozilla.org/show_bug.cgi?id=1736570#c79 does not fix this. I'll see if going back to to the older revision helps.
A shippable build of the older revision doesn't work for me. This distinction between shippable and debug points at a timing issue.
Comment 14•2 years ago
|
||
(In reply to Henri Sivonen (:hsivonen) from comment #13)
(In reply to Henri Sivonen (:hsivonen) from comment #12)
A shippable build from https://bugzilla.mozilla.org/show_bug.cgi?id=1736570#c79 does not fix this. I'll see if going back to to the older revision helps.
A shippable build of the older revision doesn't work for me. This distinction between shippable and debug points at a timing issue.
I was trying again. Still, win64-shippable/opt build from https://bugzilla.mozilla.org/show_bug.cgi?id=1736570#c77 worked for me.
However, win64-shippable/opt build from https://bugzilla.mozilla.org/show_bug.cgi?id=1736570#c79 does NOT work for me, either.
Comment 15•2 years ago
|
||
Hi Tim,
The regression window pointed bug 1685807. Can you please take a deeper look again to investigate, narrow down and confirm the root cause? Thank you.
Assignee | ||
Comment 16•2 years ago
|
||
I spent some time on this bug. It looks like there are two separate issues. The first one came from Bug 1685807, we've changed the way how we check the same origin in that bug. Now we consider the document.domain
, but this somehow violates the spec. In https://html.spec.whatwg.org/#history-traversal 5.3, it should be a same origin check but not a same origin-domain check. So, we will reset the window.name
because the document.domain
was set.
The second issue is about the session history entry. So, actually, even the window.name
was cleared in 5.3, we would store the name in the session history entry following the spec 5.3.2. And then, restore the name in the spec 5.5.1 because it reloads the same entry IIUC. So, the name should be restored in this case. However, it looks like the name we store in 5.3.2 doesn't pass to the entry we restore in 5.5.1 even they should be the same entry. I think this has something to do with the session history in the parent process. That's why this issue is not triggered in non-fission mode.
So, I guess there are two questions here.
- Anne, do we want to change the spec to check same origin-domain instead of same origin in spec 5.3? I think what we changed in Bug 1685807 was reasonable. So, maybe we should reflect this in the spec.
- Peter, is there a sync issue in this case? We set the name here to the entry, but cannot get the value in here. Note that this is a reload, so it should be the same entry IIUC.
Comment 17•2 years ago
|
||
What do Chrome and Safari do? If they do the same as us, filing an issue against whatwg/html would be good (ideally with pointers to tests).
Comment 18•2 years ago
|
||
Does it affect a live site?
We will set as P3.
document.domain
might be dropped in the future by chromium. So that might break in larger ways.
Reporter | ||
Comment 19•2 years ago
|
||
(In reply to Karl Dubost💡 :karlcow from comment #18)
Does it affect a live site?
We will set as P3.
document.domain
might be dropped in the future by chromium. So that might break in larger ways.
Yes, it affects a live site.
Updated•2 years ago
|
Assignee | ||
Comment 20•2 years ago
|
||
(In reply to Anne (:annevk) from comment #17)
What do Chrome and Safari do? If they do the same as us, filing an issue against whatwg/html would be good (ideally with pointers to tests).
It seems Safari and Chrome don't clear in this case. This might suggest that they don't check same origin-domain in spec 5.3. I think maybe we should change our behavior to match the spec first to resolve this issue. And pushing the spec change in the future, then we can change it back. WDYT, Anne?
Updated•2 years ago
|
Comment 21•2 years ago
|
||
If Chrome and Safari match the current specification that sounds like the best way forward to me. And unless we have a really compelling reason to change it to "same origin-domain" I'd rather keep it as-is I think. The less things that depend on document.domain
the better.
Assignee | ||
Comment 22•2 years ago
|
||
I see. I will submit a patch to fix this issue.
Assignee | ||
Comment 23•2 years ago
|
||
Updated•2 years ago
|
Comment 24•2 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:timhuang, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Assignee | ||
Comment 25•2 years ago
|
||
I still need to work on the test cases. I don't have time to work on this recently. Once I finish the test, I will submit the patch and get reviewed.
Updated•2 years ago
|
Assignee | ||
Comment 26•2 years ago
|
||
This patch adds a test in the web-platform test
clear-window-name.https.html. The test will load the sub domain and set
the document.domain to the parent domain. And verify that the
window.name won't be reset after navigating to the sub domain.
Depends on D143994
Updated•2 years ago
|
Comment 27•2 years ago
|
||
Pushed by tihuang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4e51b0dcf193 Stop considering document.domain when deciding if we need to reset the window name. r=smaug https://hg.mozilla.org/integration/autoland/rev/90f3275f3489 Add a test to verify that the window.name won't reset if document.domain was set. r=smaug
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/35485 for changes under testing/web-platform/tests
Comment 29•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4e51b0dcf193
https://hg.mozilla.org/mozilla-central/rev/90f3275f3489
Updated•2 years ago
|
Upstream PR merged by moz-wptsync-bot
Description
•