11247 2010-11-06 09:34:42 +0000 7.1.3.4: I think it would be a good practice to throw a QUOTA_EXCEEDED_EXCEPTION just some seconds (i.e. 5s) BEFORE the QUOTA_EXCEEDED_ERR is thrown. This would give us a way to convict the script/data in a clean state with(out) or at least less corrupted 2011-08-04 05:01:30 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#webappapis P3 normal --- 1 contributor ian ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 42214 0 contributor 2010-11-06 09:34:42 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Section: http://www.whatwg.org/specs/web-apps/current-work/#webappapis Comment: 7.1.3.4: I think it would be a good practice to throw a QUOTA_EXCEEDED_EXCEPTION just some seconds (i.e. 5s) BEFORE the QUOTA_EXCEEDED_ERR is thrown. This would give us a way to convict the script/data in a clean state with(out) or at least less corrupted data. The QUOTA_EXCEEDED_EXCEPTION-object should contain a duration (in millis), which tells us how long our cleanup could take at max, before our procedures may be killed with the QUOTA_EXCEEDED_ERR or after the user prompt (which imho also should throw an exception, if the user tells the browser to stop). Posted from: 92.75.155.123 43603 1 ian 2010-12-29 08:17:12 +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: Rejected Change Description: no spec change Rationale: In practice, things are rather more complicated. Quota could be hit unexpectedly, or could be applied by the user at the user's whim. Or it could be that the quota wasn't going to be exceeded, but the UA prompted the user to let the user know the limit was being reached, and the user decided to deny more quota to the site. What we need here is implementation experience to learn what the typical authoring patterns are, what the possible user interfaces are, and so on, before we add more standard features in this area. 52438 2 mike 2011-08-04 05:01:30 +0000 mass-moved component to LC1