1009629 - Call location.reload in onreadystatechange cancels user navigation

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect)

Description

[Piotr Duda]

Attachment: reload.py

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140428193813

Steps to reproduce:

Run attached script reload.py (using python 2.7)
Type in localhost:8000 in address bar and press enter.
Click link or any bookmark or type any address in address bar or click back button...


Actual results:

Browser stays on localhost:8000


Expected results:

Browser should go to specified address

Comment 1

[Cody Crews]

I'm not exactly up on this, but is it possible that location.reload is called because the ready state of onreadystatechange events has changed and location.reload is triggered before the loading/changing of the URI loaded into the document(window) is even initialized?  What I mean is the ready state would change as the document begins to change its location.  This would trigger location.reload which would just reload the URI as it was before the change.

Comment 2

[Cody Crews]

Unless this could do anything bad like poison the history of users browser or something along those lines I cant really see this being a bug per say.  I mean how I described it above is how it is supposed to work but I can say that I myself was recently involved in some very similar even based work so it could hold merit.  I'll let someone who actually knows what they're talking about come through here and probably correct me ;-)

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is the behavior the spec calls for.  Do other UAs handle this differently?

Comment 4

[Piotr Duda]

(In reply to Boris Zbarsky [:bz] from comment #3)
> This is the behavior the spec calls for.  Do other UAs handle this
> differently?

Yes, Chromium 34 and IE 10 just leave the page. 

Additionaly i tried combined this with onbeforeunload which results in weird behavior like browser going to another page and automagically returns to original page, or browser going into infinite loop of onbeforeunload confirmation messages.

Comment 5

[Boris Zbarsky [:bzbarsky]]

So I just tried this in Chrome (36 dev) and it has pretty much the same behavior as us.  I managed to leave the page once, out of about 20 tries.  Which can happen, of course, if the two loads race just right....

Same thing in Safari.

And if I can trust browserstack, same thing in IE11.  Fwiw, I'm using http://fiddle.jshell.net/Bhu23/show/ (the source is visible at http://fiddle.jshell.net/Bhu23/ ) as the testcase.

Comment 6

[Boris Zbarsky [:bzbarsky]]

By "same thing" I mean same as us.  I never managed to leave the page in Safari or IE11.

Comment 7

[Cody Crews]

Maybe I wasn't so wrong on this one.  So the question here is does this leave the browser in an expected state in any way?  If not I don't see this being a bug at all.

Comment 8

[Cody Crews]

^^ should be unexpected* getting my coffee in me.  Also mark this as INVALID?  If the browser doesn't have something like a history entry to a URI it never actually loaded, or anything along those lines then everything is matching the spec right?

Comment 9

[Piotr Duda]

The exampla pasted to fiddle doesn't behave exacly as the example I provided, due to fast response for xmlhttprequest, page is constantly reloading and you're not able to click link which isn't problem I reported (You could leave page by clicking any bookmark), the problem is when while xmlhttprequest is pending and user tries navigate out of page, which result in abort of xmlhttprequest which forces reload resulting in canceling user navigation (even if it was trigered by clicking bookmark).

Example that doesn't rely on long request response time http://fiddle.jshell.net/2Dr77/show/ (source: http://fiddle.jshell.net/2Dr77/ ) in Firefox trying to leave page (by either click link or click bookmark) results in infinite reload loop (the only way out out is to close page, and if you uncomment return in onbeforeunload it's even worse), in Chromium, browser just leave the page.

Comment 10

[Cody Crews]

So this could pull off a DoS if someone were to navigator to a properly setup webpage?  That might not be a different issue.

Comment 11

[Cody Crews]

What I meant by that was that I was experimenting with DoS based event stuff a little over the last few weeks so I can look into this.  I think I might enjoy this :-)

Comment 12

[Cody Crews]

Someone else be ready to pick this up.  Like I said I don't consider it a bug and I have to drop looking over this and my own event based funny business so yeah I'll get back to it if and when I can.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Hmmm.  When I try http://fiddle.jshell.net/2Dr77/show/ in a Chrome dev build, clicking the link just reloads the fiddle page.

Comment 14

[Piotr Duda]

Tested http://fiddle.jshell.net/2Dr77/show/ on IE11, works like Chrome dev (just reloads fiddle page), Opera 21 simply follows link. Anyway, no other browser so far enters infinite loop like Firefox.

Comment 15

[Thomas Wisniewski [:twisniewski]]

This is affecting https://mozdef.infosec.mozilla.org, as discovered in https://webcompat.com/issues/24077 .

Firefox users are unable to use the address bar to navigate away from affected pages, as a document.reload() is called during an XHR onreadystatechange callback, presumably because the page sees an XHR error and wants to reload to get back to a clean state, not realizing the document is just unloading.

I'd say this is another evil trap to add to the pile in bug 432687, though I'm not sure if it only happens due to specific circumstances (given that the involved script is 3 megs of minified code).