You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Click "Set cookie: Make top-level page response trigger download"
Click "Navigate to same origin page"
Click back
Chrome: Download starts. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. If you hammer the back button fast enough you can get past the history entry.
Firefox: Download prompt. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. Hammering the back button doesn't seem to help, but it might be a race.
Safari: As Chrome. Download starts. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. If you hammer the back button fast enough you can get past the history entry.
Top level 204
Traversing back to a page that, different to last time, serves a 204.
Click "Set cookie: Make top-level page response 204"
Click "Navigate to same origin page"
Click back
Chrome: Similar to the download case. The traversal is cancelled, meaning you're stuck on the history entry. If you hammer the download button fast enough you can get past the history entry.
Firefox: Similar to the download case. The traversal is cancelled, meaning you're stuck on the history entry. Hammering the back button doesn't seem to help, but it might be a race.
Safari: Traversal happens, but the active document doesn't change. So, clicking back again returns to the new tab page. Clicking forward also traverses, but you stay visually on the new tab page.
Iframe Content-Disposition
Traversing back to an iframe page that, different to last time, serves a file via Content-Disposition.
Chrome: Download starts. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. Hammering the back button doesn't seem to help, but it might be a race.
Firefox: Download prompt. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. Hammering the back button doesn't seem to help, but it might be a race.
Safari: Download starts. Traversal happens, but the active document doesn't change. So, clicking back again returns to the new tab page.
Iframe 204
Traversing back to an iframe page that, different to last time, serves a 204.
Chrome: The traversal is cancelled, meaning you're stuck on the history entry. Hammering the back button doesn't seem to help, but it might be a race.
Firefox: As Chrome. The traversal is cancelled, meaning you're stuck on the history entry. Hammering the back button doesn't seem to help, but it might be a race.
Safari: Traversal happens, but the active document doesn't change. So, clicking back again returns to the new tab page.
Recommendation
The patterns that break the back button seem bad, and potentially abusable.
I like what Safari sometimes does, and I think I can spec it:
Right now, a navigable has a "current session history entry", but I could split this into a "current session history entry" and a "displayed session history entry". These will usually be the same thing, except in cases where you traverse to something that cannot display, such as the cases above.
Take this history:
Where the top row is a top level page and the second row is an iframe in that page.
We're on step 2. The iframe has the /one entry as both its current and displayed entry.
Back clicked, but /frame-start returns a 203. As a result, the iframe has the /frame-start entry as its current entry, but stays with /one as its displayed entry.
Back clicked, traversing the top level page. However, the iframe knows the /frame-start entry is its current entry, so nothing happens to the iframe, even though it's still displaying the document from /one.
Forward clicked, traversing the top level page. However, the iframe knows the /frame-start entry is its current entry, so nothing happens to the iframe, even though it's still displaying the document from /one.
Forward clicked. The iframe now changes its current entry to /one, but since its rendered entry is already /one, it doesn't reload or refresh.
Another great catch! Your recommendation makes sense to me, although the simplicity and (sort of) 2/3 behavior of just not allowing the traversal is somewhat attractive.
I hope we can get folks like @smaug---- and @csreis / @rakina to chime in on whether they think it's OK to change their implementation in such a fashion.
I think "cancel traversal" might be a vector for keeping someone trapped in the site. Also, it gets a lot more complicated if you're stepping back multiple history items at once, and 3 iframes navigate, and one 204s. That would require synchronising all the fetch parts of a traversal before swapping any active documents.
This is pretty similar to #6446, except with beforeunload it's ok to cancel the traversal since it's the user's choice.
…but also not an error? Things like HTTP 204 and responses with
Content-Disposition
.Top level
Content-Disposition
Traversing back to a page that, different to last time, serves a file via
Content-Disposition
.Chrome: Download starts. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. If you hammer the back button fast enough you can get past the history entry.
Firefox: Download prompt. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. Hammering the back button doesn't seem to help, but it might be a race.
Safari: As Chrome. Download starts. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. If you hammer the back button fast enough you can get past the history entry.
Top level 204
Traversing back to a page that, different to last time, serves a 204.
Chrome: Similar to the download case. The traversal is cancelled, meaning you're stuck on the history entry. If you hammer the download button fast enough you can get past the history entry.
Firefox: Similar to the download case. The traversal is cancelled, meaning you're stuck on the history entry. Hammering the back button doesn't seem to help, but it might be a race.
Safari: Traversal happens, but the active document doesn't change. So, clicking back again returns to the new tab page. Clicking forward also traverses, but you stay visually on the new tab page.
Iframe
Content-Disposition
Traversing back to an iframe page that, different to last time, serves a file via
Content-Disposition
.Chrome: Download starts. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. Hammering the back button doesn't seem to help, but it might be a race.
Firefox: Download prompt. The traversal is cancelled, meaning you're stuck on the history entry. Clicking back again starts another download. Hammering the back button doesn't seem to help, but it might be a race.
Safari: Download starts. Traversal happens, but the active document doesn't change. So, clicking back again returns to the new tab page.
Iframe 204
Traversing back to an iframe page that, different to last time, serves a 204.
Chrome: The traversal is cancelled, meaning you're stuck on the history entry. Hammering the back button doesn't seem to help, but it might be a race.
Firefox: As Chrome. The traversal is cancelled, meaning you're stuck on the history entry. Hammering the back button doesn't seem to help, but it might be a race.
Safari: Traversal happens, but the active document doesn't change. So, clicking back again returns to the new tab page.
Recommendation
The patterns that break the back button seem bad, and potentially abusable.
I like what Safari sometimes does, and I think I can spec it:
Right now, a navigable has a "current session history entry", but I could split this into a "current session history entry" and a "displayed session history entry". These will usually be the same thing, except in cases where you traverse to something that cannot display, such as the cases above.
Take this history:
Where the top row is a top level page and the second row is an iframe in that page.
/one
entry as both its current and displayed entry./frame-start
returns a 203. As a result, the iframe has the/frame-start
entry as its current entry, but stays with/one
as its displayed entry./frame-start
entry is its current entry, so nothing happens to the iframe, even though it's still displaying the document from/one
./frame-start
entry is its current entry, so nothing happens to the iframe, even though it's still displaying the document from/one
./one
, but since its rendered entry is already/one
, it doesn't reload or refresh.cc @smaug---- @csreis @natechapin @cdumez @domenic
The text was updated successfully, but these errors were encountered: