13498 2011-08-01 10:36:36 +0000 document.readyState should return to 'loading' on navigation 2011-09-27 21:20:17 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified PC Windows XP RESOLVED NEEDSINFO test needed P2 normal --- 1 hsteen ian bzbarsky hsivonen ian jonas mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 51895 0 hsteen 2011-08-01 10:36:36 +0000 Opera has problems with uploading attachments on T-Online.de's webmail, it boils down to an issue that might have some relevance for HTML5's definition of the readyState property / document readiness calculation ( http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#current-document-readiness ). 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: http://lists.w3.org/Archives/Public/public-html/2011Jul/0199.html ) 52514 1 mike 2011-08-04 05:02:10 +0000 mass-moved component to LC1 54524 2 ian 2011-08-10 01:09:44 +0000 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? 55121 3 hsteen 2011-08-15 18:23:19 +0000 > 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?? 55456 4 jonas 2011-08-19 00:30:45 +0000 I would rather not add this kind of complexity if we've only found one website that breaks over it. 56040 5 hsivonen 2011-08-30 13:18:14 +0000 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. 56600 6 ian 2011-09-10 05:29:50 +0000 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. 57449 7 ian 2011-09-27 21:20:17 +0000 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: http://dev.w3.org/html5/decision-policy/decision-policy.html 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.