This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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 )
mass-moved component to LC1
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?
> 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??
I would rather not add this kind of complexity if we've only found one website that breaks over it.
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.
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.
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.