1610523 - Cannot easily reattempt navigating to a URL that returned status 204 No Content using reload button (and URL is not remembered in session restore)

Status: UNCONFIRMED

(Firefox :: General, defect, P5)

Description

[Martin F.]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

• Open new tab
• Open network console
• Navigate to a page with status 204 (No Content), for example http://httpstat.us/204
• Try to reload the page with the button near the address bar or F5 or Ctrl+R

Actual results:

Nothing. Reload button is disabled.

Expected results:

Firefox should send a new HTTP request.

The 204 status is special, but I think if the user explicitly entered the address in the address bar, the browser should navigate to that page and make it possible to reload it. This is a common task (and HTTP status) for developers of web services.

Comment 1

[Martin F.]

See also bug 1174493

Comment 2

[Gingerbread Man]

• Reload toolbar button, F5/Ctrl+R are disabled.
• Reload network monitor button and Reload tab context menu just clear the address bar.
• Session restore brings up a blank tab with an empty address bar, with the title "New Tab".
• Session restore doesn't bring up the blank tab a second time, as expected (bug 1549360).

(In reply to :Gijs (he/him) from bug 1174493, comment 6)

Please file a new bug.

This is that bug. Any idea where to triage this and what the intended behavior is?

Comment 3

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from bug 1174493, comment 6)

Please file a new bug.

This is that bug. Any idea where to triage this and what the intended behavior is?

I think unfortunately ::General is our best bet. This is to do with the progress listener events we get and/or somehow figuring out (when those listeners fire, asynchronously) whether the load was triggered by the URL bar, ie avoiding regressing bug 802026.

That said, I'm a little confused. AIUI a 204 load does not in fact return any content and so no document loads at all. So "reload"-ing that document is meaningless. It seems other browsers do not do this, either (checked Safari and Chrome).

(In reply to Martin F. from comment #0)

The 204 status is special, but I think if the user explicitly entered the address in the address bar, the browser should navigate to that page

But there is no page, that's exactly the problem...

and make it possible to reload it. This is a common task (and HTTP status) for developers of web services.

Developers of services that work like this (CRUD or otherwise) are hopefully familiar with cURL and similar tools, or could manually run fetch() in the console.

There are also specs for this type of navigation. It's actually not super clear to me from step 2 at https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-response what the origin of the resulting document would be; it is set in step 1 only under certain conditions, which won't be true for a 204/205 response. Anne?

In any case, normally the reload button reloads the then-current document. In this case (and perhaps that's against the spec, I'm honestly not sure), it seems we do not replace the current document in the browsing context (try e.g. loading mozilla.org and then copy-pasting http://httpstat.us/204 into the URL bar and hitting enter; the "old" page remains visible).

We could potentially make the reload button in a blank tab with text in the URL bar that has been used for a load at least once, attempt to re-run that load. That would also help for some other issues in this area. Either way, the tab should not be discarded for session restore, as it has user content in the URL bar.

Comment 4

[Anne (:annevk)]

Step 2 there means the navigation does not complete and the previous document remains in place (as you observed). I'm not certain how accurate that is under all conditions as I don't think it's well tested.

Comment 5

[Martin F.]

(In reply to :Gijs (he/him) from comment #3)

(In reply to Martin F. from comment #0)

The 204 status is special, but I think if the user explicitly entered the address in the address bar, the browser should navigate to that page

But there is no page, that's exactly the problem...

While there is a semantic difference which programs may find significant, I don’t see a reason not to present this to the user similar to 0-byte-responses with status 200 (at least when the URL is manually entered or opened via a link in a new tab). A 204 response has many quirks, the URL does not show up in the history, session restore doesn’t work, reloading is not possible and when entering the URL in another tab, there is no "switch to tab" entry in the suggestions below the address bar.

and make it possible to reload it. This is a common task (and HTTP status) for developers of web services.

Developers of services that work like this (CRUD or otherwise) are hopefully familiar with cURL and similar tools, or could manually run fetch() in the console.

While there may be better tools than a browser, a browser with a network console is a powerful tool and often good enough. It is probably often used by beginners not knowing better tools yet, users who want to check something quickly without having to remember/look up command line parameters and when a better tool is currently not available in that environment. Backend developers may not be familiar with the fetch API.

Comment 6

[:Gijs (he/him)]

(In reply to Martin F. from comment #5)

(In reply to :Gijs (he/him) from comment #3)

(In reply to Martin F. from comment #0)

The 204 status is special, but I think if the user explicitly entered the address in the address bar, the browser should navigate to that page

But there is no page, that's exactly the problem...

While there is a semantic difference which programs may find significant, I don’t see a reason not to present this to the user similar to 0-byte-responses with status 200 (at least when the URL is manually entered or opened via a link in a new tab). A 204 response has many quirks, the URL does not show up in the history, session restore doesn’t work, reloading is not possible and when entering the URL in another tab, there is no "switch to tab" entry in the suggestions below the address bar.

But this behaviour could easily be relied upon by external sites - if they themselves redirect location.href to a place that can (perhaps only some of the time) return a 204, they would expect the page to remain loaded as it is right now. Changing this (to loading a blank document, with the origin of the requested URL) would be a web-exposed behaviour change. We could consider that, but it'd need a spec change and discussion with other browsers. If you think this is warranted, I'd suggest taking it up with the whatwg/w3c.

(In reply to :Gijs (he/him) from comment #3)

We could potentially make the reload button in a blank tab with text in the URL bar that has been used for a load at least once, attempt to re-run that load. That would also help for some other issues in this area. Either way, the tab should not be discarded for session restore, as it has user content in the URL bar.

OK, so this specific case would not affect web compat, and I could see us taking a patch if it included an automated test, but it would potentially confuse users in that it'd cause different behaviour depending on what was open before. Either way, fixing isn't a big priority for the core team right now.