Closed Bug 1746349 Opened 2 years ago Closed 2 years ago

window.name discard in case of set document.domain in script

Categories

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

Firefox 95
defect

Tracking

()

RESOLVED FIXED
105 Branch
Webcompat Priority P3
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)

Attached file 1.html

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:

  1. Update firefox to v.95.0
  2. Set document.domain and window.name in script as in attached file (or use attached file)
  3. Open browser and reset settings to default
  4. Open attached html on localhost (we use django framework)
  5. Refresh page.
  6. After refreshing page window.name will be equal to set in script
  7. Close and open browser again
  8. Open attached html on localhost
  9. Refresh page
  10. After each refreshing window.name will be EMPTY STRING (NOT EXPECTED)
  11. If reset firefox settings, window.name won't reset after each page refreshing
  12. 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

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.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Component: Widget: Gtk → DOM: Core & HTML

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?

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.

Regressed by: 1685807
Has Regression Range: --- → yes
Flags: needinfo?(tihuang)

Set release status flags based on info from the regressing bug 1685807

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.

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.

Flags: needinfo?(tihuang)

The severity field is not set for this bug.
:edgar, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(echen)
Flags: needinfo?(echen) → needinfo?(htsai)
Flags: needinfo?(htsai)

The severity field is not set for this bug.
:farre, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(afarre)
Severity: -- → S3
Flags: needinfo?(afarre)

(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?

Status: UNCONFIRMED → NEW
Webcompat Priority: --- → ?
Ever confirmed: true
See Also: → 1687029

(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.

Flags: needinfo?(hsivonen)

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.

Flags: needinfo?(hsivonen)

(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.

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.

Flags: needinfo?(tihuang)

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.
Flags: needinfo?(tihuang)
Flags: needinfo?(peterv)
Flags: needinfo?(annevk)

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).

Flags: needinfo?(annevk) → needinfo?(tihuang)

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.

Webcompat Priority: ? → P3
Flags: needinfo?(ugalnikov)

(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.

Flags: needinfo?(ugalnikov)

(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?

Flags: needinfo?(tihuang) → needinfo?(annevk)

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.

Flags: needinfo?(annevk)

I see. I will submit a patch to fix this issue.

Assignee: nobody → tihuang
Status: NEW → ASSIGNED
Flags: needinfo?(peterv)

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.

Flags: needinfo?(tihuang)
Flags: needinfo?(bugs)
Flags: needinfo?(bugs)

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.

Flags: needinfo?(tihuang)

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

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
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 105 Branch
Flags: in-testsuite+
Regressions: 1785227
Upstream PR merged by moz-wptsync-bot
No longer regressions: 1785227
You need to log in before you can comment on or make changes to this bug.