Closed Bug 1594834 Opened 5 years ago Closed 5 years ago

Triggering an ajax request and then updating window.location.href causes the request to never be spawned

Categories

(DevTools :: Netmonitor, defect, P3)

70 Branch
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: rdwoodring, Unassigned)

References

Details

Attachments

(1 file)

2.94 KB, application/x-zip-compressed
Details
Attached file fetch-and-navigate.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36

Steps to reproduce:

Within JavaScript:

  1. Open developer tools.
  2. Select the Network tab
  3. Check "Persist Logs"
  4. spawn a request with the fetch API
  5. update window.location.href

Reproducible test case is attached.

  1. Unzip it, run npm install, then run npm start.
  2. With developer tools open to the Network tab in Firefox, click the button to fire a request and instantly navigate away.
  3. look for the request to /banana in the network tab and in the console window where the npm start was run

Also tested this out on Nightly build (72.0a1 (2019-11-07) (64-bit) and the behavior persists.

Actual results:

No fetch request is fired, the user is just navigated away. In the test case, this can be verified as the server never logs the request as received and the developer tools never show the request being sent.

Expected results:

I would expect the request to be fired even though the user is navigated away. Use case is that the request could trigger a long-running process on the server that we don't want to make the user wait for; instead, we just want to notify the user when the process is complete.

In any case, it doesn't seem right that the request is never even fired.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Netmonitor
Product: Firefox → DevTools

The priority flag is not set for this bug.
:Honza, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(odvarko)

Thanks for the report!

I can reproduce on my machine Win10 + Firefox Nightly

The test case is online here
http://janodvarko.cz/tests/bugzilla/1594834/

Michal, could this be a problem in Necko?
I am not seeing that request would be reported by Necko API.

Honza

Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Flags: needinfo?(odvarko) → needinfo?(michal.novotny)
Priority: -- → P3

(In reply to Jan Honza Odvarko [:Honza] (always need-info? me) PTO from 12/23/19 to 1/1/20 from comment #3)

Thanks for the report!

I can reproduce on my machine Win10 + Firefox Nightly

The test case is online here
http://janodvarko.cz/tests/bugzilla/1594834/

Michal, could this be a problem in Necko?
I am not seeing that request would be reported by Necko API.

Honza

If the scope of the fetch/XHR is the document/window, then it's IMO correct that we don't continue processing async requests when we're navigating away. Can you point to a spec that would say the opposite?

Flags: needinfo?(michal.novotny)

To be honest, I had a look at the spec before I submitted the ticket and didn't get much out of it either way. As far as I can tell, though, this behavior is inconsistent with all other major browsers, including IE11.

That being said, I can agree that there's not a huge use case for this. I ran into it because some hacky code on our server queues requests up and the short term solution was for the client code to just redirect immediately since the server couldn't be guaranteed to respond in a timely manner. Ideally, I agree, the server should just respond in all cases (even when they are going to thread out a long-running opeeation) but it bothered me most that the behavior was not consistent with other browsers, FWIW.

Michal, thanks for the response!

I am closing the report since it appears that there is not much we'd like to do.

Feel free to reopen if you think otherwise!

Honza

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: