Open Bug 1343331 Opened 7 years ago Updated 1 year ago

Firefox prioritizes web socket events over location changes

Categories

(Core :: DOM: Networking, defect, P2)

51 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: troiter, Unassigned)

References

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

Create a web socket object in JS in some file.

var ws = new WebSocket(...) ;

ws.onclose = function() {
  window.location.reload() ;
} ;

Let me know if I can be of any further assistance in reproducing this for the dev team.



Actual results:

Load a page with js mentioned in the steps to reproduce and try entering a url in the location window.  It will prioritize the disconnect of the websocket on the location change, and call window.location.reload() with the current window location instead of honoring the new location typed in the address bar. (if you have links on the page that leave the host, you will see the same behavior as well)   Both Chrome and Safari handle this situation correctly.


Expected results:

The browser should load the page typed in the address bar or the anchor tag instead of reloading the current location again.
Product: Firefox → Core
Component: Untriaged → Networking: WebSockets
Component: Networking: WebSockets → DOM
Shouldn't have anything to do with WebSockets.

Clicking on <a> shouldn't probably be handled specially, but typing url to the address should override page's reload() request.
Perhaps reload() shouldn't do anything if there is pending load triggered by systemPrincipal.
Component: DOM → Document Navigation
I just want to make sure I understand your <a> comment correctly.

So an <a> on a page that explicitly goes to another site shouldn't take the user there?  If there's a window.location.reload() in the web socket close event handler, the behavior of the web socket code should win and the user gets a refresh instead of being brought to what they clicked on?
for comment 2
Flags: needinfo?(bugs)
Priority: -- → P3
baku knows websockets well so could probably answer comment 2.
Flags: needinfo?(amarchesini)
> I just want to make sure I understand your <a> comment correctly.

Yes. this is what smaug is suggesting. I don't know when I'll be able to work on this. But if somebody else wants to take it, I can maybe help reviewing the patch.
Flags: needinfo?(amarchesini)
Component: DOM: Navigation → DOM: Networking
Flags: needinfo?(bugs)
Severity: normal → S3
Priority: P3 → P2
Whiteboard: [necko-triaged]

i don't know if this a good change or a bad change

You need to log in before you can comment on or make changes to this bug.