Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider to make "loading inside onload handler" replace previous session history entry. #3247

Closed
freesamael opened this issue Nov 22, 2017 · 1 comment · Fixed by #6714
Closed

Consider to make "loading inside onload handler" replace previous session history entry. #3247

freesamael opened this issue Nov 22, 2017 · 1 comment · Fixed by #6714
Labels
topic: forms topic: navigation

Comments

@freesamael
Copy link

A few months ago Microsoft reported a Firefox bug noting that they're utilizing form POST submission inside the onload handler for redirection, but Firefox would add a new history entry in this case and pressing back button after the redirection would keep user being redirected back to current page.

The standard does mention location assignment would set replacement flag if the document has not been completely loaded, but there wasn't a similar definition in form submission.

Both Chrome and Edge don't add new entries for the "form submission inside onload handler" case, and allowing history entries being generated during onload would essentially break the back button. I think it's considerable to make the definition more generic somewhere (maybe in session history or page load processing?) that loading inside onload shouldn't generate new entries.

I submitted a tentative web-platform test case few weeks ago. It passes on Chrome / Edge and Firefox 58.
@bzbarsky
Copy link
Contributor

Note that what Firefox implemented is specifically that form submissions under a load event handler running do a replace load. Doing things like click() on <a> elements does not, I'm pretty sure, because the relevant part of the code runs async in that case, so no longer under the load event (unlike form submission, which runs that code sync).

I don't know that we've tested what Edge and Chrome do with click() here.

@domenic domenic mentioned this issue Apr 12, 2021
Closed
domenic added a commit that referenced this issue May 24, 2021
@domenic
Fix handling of navigations before/during load
d280c83 
Several types of navigations have a special handling, where if they happen "before load", they are converted into "replace" navigations (instead of "default" navigations). However, this special handling had several interoperability problems and the specification was somewhat broken due to a bad definition of "completely loaded". The result here mostly aligns with WebKit and Blink behavior.

Notable changes:

* "completely loaded" gets flipped only after the load event has run. It is mostly used to determine "default" vs. "replace" navigations, and in almost all cases browsers treat navigations before or during the load event as getting the special "replace" treatment. This includes the below cases, as well as <iframe> src="" assignment (which is otherwise untouched). The other thing this improves is that it ensures load events on iframe/embed/object elements are only fired (or at least queued) after the corresponding load event on the contained Document.

* location.assign() gets special handling before/during the load event; previously this special handling was only applied to the location setters. (This allows us to roll "Location-object-setter navigate" into "Location-object navigate".)

* Location APIs now override the special handling and force "default" navigation if transient user activation is present, not just if running specifically in a click handler.

* All form submissions can get converted to "replace" if they target a non-completely loaded document. Previously this special handling was only applied to form submissions initiated by the formElement.submit() API.

Notable non-changes (backed by tests):

* Following hyperlinks never varies its "replace" vs. "default" behavior based on completely loaded status. This matches all browsers

* window.open() navigating an existing browsing context never varies its "replace" vs. "default" behavior based on completely loaded status. This matches Blink and WebKit.

Closes #6579. Closes #3247.
@domenic domenic mentioned this issue May 24, 2021
Merged
3 tasks
domenic added a commit that referenced this issue Jun 23, 2021
@domenic
Fix handling of navigations before/during load
524485a 
* Fix handling of navigations before/during load

Several types of navigations have a special handling, where if they happen "before load", they are converted into "replace" navigations (instead of "default" navigations). However, this special handling had several interoperability problems and the specification was somewhat broken due to a bad definition of "completely loaded". The result here mostly aligns with Blink behavior.

Notable changes from the previous spec:

* "completely loaded" gets flipped only after the load event has run. It is mostly used to determine "default" vs. "replace" navigations, and in almost all cases browsers treat navigations before or during the load event as getting the special "replace" treatment. This includes the below cases, as well as <iframe> src="" assignment (which is otherwise untouched). The other thing this improves is that it ensures load events on iframe/embed/object elements are only fired (or at least queued) after the corresponding load event on the contained Document.

* location.assign() gets special handling before/during the load event; previously this special handling was only applied to the location setters. (This allows us to roll "Location-object-setter navigate" into "Location-object navigate".)

* Location APIs now override the special handling and force "default" navigation if transient user activation is present, not just if running specifically in a click handler.

* All form submissions can get converted to "replace" if they target a non-completely loaded document. Previously this special handling was only applied to form submissions initiated by the formElement.submit() API.

Notable non-changes (backed by tests):

* Following hyperlinks never varies its "replace" vs. "default" behavior based on completely loaded status.

* window.open() navigating an existing browsing context never varies its "replace" vs. "default" behavior based on completely loaded status.

Closes #6579. Closes #3247.
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
@domenic
Fix handling of navigations before/during load
4d522bb 
* Fix handling of navigations before/during load

Several types of navigations have a special handling, where if they happen "before load", they are converted into "replace" navigations (instead of "default" navigations). However, this special handling had several interoperability problems and the specification was somewhat broken due to a bad definition of "completely loaded". The result here mostly aligns with Blink behavior.

Notable changes from the previous spec:

* "completely loaded" gets flipped only after the load event has run. It is mostly used to determine "default" vs. "replace" navigations, and in almost all cases browsers treat navigations before or during the load event as getting the special "replace" treatment. This includes the below cases, as well as <iframe> src="" assignment (which is otherwise untouched). The other thing this improves is that it ensures load events on iframe/embed/object elements are only fired (or at least queued) after the corresponding load event on the contained Document.

* location.assign() gets special handling before/during the load event; previously this special handling was only applied to the location setters. (This allows us to roll "Location-object-setter navigate" into "Location-object navigate".)

* Location APIs now override the special handling and force "default" navigation if transient user activation is present, not just if running specifically in a click handler.

* All form submissions can get converted to "replace" if they target a non-completely loaded document. Previously this special handling was only applied to form submissions initiated by the formElement.submit() API.

Notable non-changes (backed by tests):

* Following hyperlinks never varies its "replace" vs. "default" behavior based on completely loaded status.

* window.open() navigating an existing browsing context never varies its "replace" vs. "default" behavior based on completely loaded status.

Closes whatwg#6579. Closes whatwg#3247.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: forms topic: navigation
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix handling of navigations before/during load whatwg/html
3 participants
@bzbarsky @annevk @freesamael