[Bug 25054] Should the API be exposed to non-Mobile?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25054 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Mounir Lamouri mou...@lamouri.fr --- Implementations are allowed to deny locking by rejecting the promise with NotSupportedError. https://github.com/w3c/screen-orientation/commit/6cc33d3e871274963044b8db28f5007ff31b1dd5 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25987] Blob URL parsing / fetching model
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24338] Spec should have Fetch for Blob URLs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338 Bug 24338 depends on bug 25987, which changed state. Bug 25987 Summary: Blob URL parsing / fetching model https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25915] Cross-origin requests
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25915 Arun a...@mozilla.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Arun a...@mozilla.com --- (In reply to Anne from comment #8) Yeah I think so. Unless you think Fetch should defer to the File API for the extracting bits from a blob bit, but I'm not sure why we would intertwine them like that. Any FileAPI guidance on request/response when fetching Blob URLs is now non-normative, and I consider it provisional (e.g. can delete finally) when Fetch fully owns Blob URLs as per bug 24338, which is assigned to annevk. http://dev.w3.org/2006/webapi/FileAPI/#requestResponseModel -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25914] No definition of parsing blob's scheme data
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914 Arun a...@mozilla.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Arun a...@mozilla.com --- (In reply to Anne from comment #24) You don't need to define 1. That is already handled by the generic URL parser. Done per http://dev.w3.org/2006/webapi/FileAPI/#extractionOfOriginFromIdentifier -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25987] Blob URL parsing / fetching model
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25987 Bug 25987 depends on bug 25914, which changed state. Bug 25914 Summary: No definition of parsing blob's scheme data https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 25994] invalid extended attribute list syntax
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25994 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Arun a...@mozilla.com --- Fixed. 1. http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob 2. http://dev.w3.org/2006/webapi/FileAPI/#dfn-file 3. http://dev.w3.org/2006/webapi/FileAPI/#dfn-filereader 4. http://dev.w3.org/2006/webapi/FileAPI/#readingOnThreads -- You are receiving this mail because: You are on the CC list for the bug.
Re: Indexed DB Transactions vs. Microtasks
On Fri, Jun 6, 2014 at 5:51 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 5, 2014 at 12:59 PM, Joshua Bell jsb...@google.com wrote:
case 1:
var tx;
Promise.resolve().then(function() {
tx = db.transaction(storeName);
// tx should be active here...
}).then(function() {
// is tx active here?
});
For case 1, ISTM that yes matches the IDB spec, since control has not
returned to the event loop while the microtasks are running.
Implementations
appear to agree.
Yes. I believe that this is what the spec currently calls for.
However I think it would actually be good to change the spec to say
that the transaction is closed at the end of the current microtask.
When we originally designed microtasks for Mutation Observers, one of
the goals was to ensure that there were not accidental
interdependencies between different event handlers to the same event.
By flushing end-of-microtask work after each event handler you ensure
that each event handler gets a clean slate.
I realize that this is a backwards-incompatible change. However it
seems pretty unlikely to break any existing content. So it'd be nice
to give it a try.
While I agree that the original microtask intent would suggest we change
this, and I concur that it seems unlikely to break content, I worry about
the spec and implementation complexity that would be incurred by having to
support the notion of at the end of the current microtask. It suggests
one of:
1. A new task queue, which runs after microtasks (nanotasks?)
2. The ability to put tasks at the start of the microtask queue rather than
at the end
(1) seems like a bad idea for a variety of reasons, not least of which that
it would soon lead us to need picotasks once an actor other than IDB saw a
need for it.
(2) strikes me as just plain hard to reason about. And again, if anyone
other than IDB tried to use that capability, it would become problematic.
Code running at end-of-microtask already has to deal with being in a
slightly different environment than normal event-handling code. I think
it might be worth avoiding additional complexity to make this quirk one of
those caveats.
- Adam
(resending from correct address, a dup may show up at some point)
Re: Indexed DB Transactions vs. Microtasks
On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein ad...@google.com wrote: While I agree that the original microtask intent would suggest we change this, and I concur that it seems unlikely to break content, I worry about the spec and implementation complexity that would be incurred by having to support the notion of at the end of the current microtask. It suggests one of: 1. A new task queue, which runs after microtasks (nanotasks?) 2. The ability to put tasks at the start of the microtask queue rather than at the end I was just thinking to hardcode this into the algorithm that's run at the end of the microtask. Note that closing the transaction never runs code, which means that very little implementation complexity is needed. I definitely agree that both of the above options are pretty unattractive. / Jonas
RE: Indexed DB Transactions vs. Microtasks
[+Yehuda, +Raf] From: Jonas Sicking [mailto:jo...@sicking.cc] On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein ad...@google.com wrote: While I agree that the original microtask intent would suggest we change this, and I concur that it seems unlikely to break content, I worry about the spec and implementation complexity that would be incurred by having to support the notion of at the end of the current microtask. It suggests one of: 1. A new task queue, which runs after microtasks (nanotasks?) 2. The ability to put tasks at the start of the microtask queue rather than at the end I was just thinking to hardcode this into the algorithm that's run at the end of the microtask. Note that closing the transaction never runs code, which means that very little implementation complexity is needed. I definitely agree that both of the above options are pretty unattractive. This recalls Yehuda's proposal for a bucketed microtask queue. It seems like this is a very strong argument for it.
Re: Indexed DB Transactions vs. Microtasks
On Wed, Jun 18, 2014 at 9:13 PM, Domenic Denicola dome...@domenicdenicola.com wrote: [+Yehuda, +Raf] From: Jonas Sicking [mailto:jo...@sicking.cc] On Thu, Jun 19, 2014 at 8:44 AM, Adam Klein ad...@google.com wrote: While I agree that the original microtask intent would suggest we change this, and I concur that it seems unlikely to break content, I worry about the spec and implementation complexity that would be incurred by having to support the notion of at the end of the current microtask. It suggests one of: 1. A new task queue, which runs after microtasks (nanotasks?) 2. The ability to put tasks at the start of the microtask queue rather than at the end I was just thinking to hardcode this into the algorithm that's run at the end of the microtask. Note that closing the transaction never runs code, which means that very little implementation complexity is needed. I definitely agree that both of the above options are pretty unattractive. This recalls Yehuda's proposal for a bucketed microtask queue. It seems like this is a very strong argument for it. This seems orthogonal to bucketing. The IDB transaction deactivation step isn't a sort of work that we'd want to bucket (as I argued in my previous message, treating this IDB work as a task leads down some bad roads); as Jonas says, we would actually want to hardcode it as a thing that just happens after each microtask is run (an idea that would have unappealing consequences for the Chromium implementation of microtasks, but one which I'll mull over). - Adam
RE: Indexed DB Transactions vs. Microtasks
From: ad...@google.com [mailto:ad...@google.com] On Behalf Of Adam Klein This seems orthogonal to bucketing. The IDB transaction deactivation step isn't a sort of work that we'd want to bucket (as I argued in my previous message, treating this IDB work as a task leads down some bad roads) Hmm, it seems pretty related to me. In particular if we say that the IDB microtask bucket always runs after all other microtask buckets, doesn't that achieve the goals? It's essentially a generalization of your (1), by putting them into a larger conceptual framework. More explicitly, it achieves (1) since the last bucket in the microtask list is essentially nanotasks. But if we later decided something else needed to run after IDB (your picotasks), then we could demote IDB to second-to-last bucket without having to overhaul the overall model.
