This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13498 - document.readyState should return to 'loading' on navigation
Summary: document.readyState should return to 'loading' on navigation
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Whiteboard: test needed
Depends on:
Reported: 2011-08-01 10:36 UTC by Hallvord R. M. Steen
Modified: 2011-09-27 21:20 UTC (History)
7 users (show)

See Also:


Description Hallvord R. M. Steen 2011-08-01 10:36:36 UTC
Opera has problems with uploading attachments on's webmail, it boils down to an issue that might have some relevance for HTML5's definition of the readyState property / document readiness calculation ( ). 

What happens in IE is that when a window is being navigated away from the current document, that document's readyState changes from 'complete' to 'loading'. (It would have made more sense in this case to have 'readyState' as a property on the window, but that's a sin of designers past..).

HTML5 has not noticed this, it seems (or chosen to ignore it?), so the spec as-written seems to asssume that readyState won't ever switch from complete back to loading. The site sniffs for WebKit-based browsers and Firefox, because they don't emulate IE on this point.

Now that we've realised IE does some extra stuff and found an important site depending on it. I think switching back to 'loading' when some load is pending makes sense.

(Originally posted on public-html: )
Comment 1 Michael[tm] Smith 2011-08-04 05:02:10 UTC
mass-moved component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-08-10 01:09:44 UTC
Hrm, that's kind of a pain. Do they switch it back to 'complete' if the load ends up being a download or ends up canceled or whatnot? Where does this happen relative to the onbeforeunload handler? How about relative to parser abortion in the case the readyState was still not 'complete'? How does this interact with history navigation? (e.g. if you go back to the document and it was bfcached, does it still have this new state or does it go back?)

Do other browsers do this also?

Are there any tests for this?
Comment 3 Hallvord R. M. Steen 2011-08-15 18:23:19 UTC
> How about relative to parser abortion in the case the readyState was still not 'complete'?

How can I test this - test if load or DOMContentLoaded fires before the new navigation??
Comment 4 Jonas Sicking (Not reading bugmail) 2011-08-19 00:30:45 UTC
I would rather not add this kind of complexity if we've only found one website that breaks over it.
Comment 5 Henri Sivonen 2011-08-30 13:18:14 UTC
Metooing to what Jonas said. Recently, I discovered that readyState management in Gecko isn't that great for docs that aren't of the most normal HTML kind. Patching things such that all kinds of docs have their readyStates progress reasonably and monotonically was annoying enough (I didn't even get it done all the way), so having readyStates go backwards intentionally wouldn't be nice at all.
Comment 6 Ian 'Hixie' Hickson 2011-09-10 05:29:50 UTC
To test this you just need to write pages that clearly demonstrate the difference in behaviour between what the spec says and what you want it to say. (I should say "demo", not "test", really.)

Without tests I really have no idea what to do here and am likely to agree with comment 4 and comment 5.
Comment 7 Ian 'Hixie' Hickson 2011-09-27 21:20:17 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 6. I'm happy to consider this further, but we need clear tests and ideally we need evidence of more than one site needing it.