Re: FileSystem API: Cross origin sharing
On Tue, Aug 14, 2012 at 4:51 PM, Charles Pritchard wrote: > Is there a long term plan for transferring access to Files from the > FileSystem? > > Currently, we can using FileEntry.file semantics then post the resulting > Blob to another frame. From that point, the receiver can create a Blob URL. > I'm concerned about all the extra work with Blobs which may get stuck in > RAM. > How? The only possible way is object URL leaks (missed revokeObjectURL calls), which should be addressed by autoRevoke. -- Glenn Maynard
Re: [File API] Blob URI creation
Please note that there's one other issue outstanding: both microtasks and
stable states are very closed, but neither may be what this needs. A
separate hook may be needed.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16790#c13.
On Tue, Aug 14, 2012 at 4:37 PM, Feras Moussa wrote:
> In general we are OK with changing it to the autoRevoke behavior below,
> but have some concerns around changing the default behavior.
> Changing the default behavior is a breaking change and any apps which
> expect the URL to work multiple times will now be broken. In Windows 8, we
> also implemented the oneTimeOnly behavior and it was very widely used,
> these consumers will be broken as well.
>
> We would like to support autoRevoke as the default as it helps reduce the
> chance of leaking unintentionally, but we think developers should have a
> way to feature detect the new change. If a developer can feature detect
> which default behavior is present, then they can reason about what to
> expect from the API.
>
I agree that this needs to be feature detectable. I don't think this
should be fixed in a special way specific to getObjectURL, because this is
a general issue with the Dictionary pattern, where features are used by
setting a flag in an object. We need a general way to tell if an API
supports a particular dictionary key in its options dictionary, because
this is going to come up again as dictionaries are used in new APIs.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16953#c4 suggests using a
property of WebIDL dictionaries to accomplish this: use
Object.defineProperty to detect whether the key's value is read by the API
call:
var hasAutoRevoke = false;
var o = {};
Object.defineProperty(o, "autoRevoke", { get: function() { hasAutoRevoke =
true; return false; } });
URL.createObjectURL(new Blob(), o); // getter will be called if supported
This works (supported dictionary keys are guaranteed to be retrieved
exactly once), but it's fairly cumbersome. It also requires a close
knowledge of WebIDL details, though maybe it's OK if people copy-and-paste
this code without knowing why it works.
--
Glenn Maynard
FileSystem API: Cross origin sharing
Is there a long term plan for transferring access to Files from the FileSystem? Currently, we can using FileEntry.file semantics then post the resulting Blob to another frame. From that point, the receiver can create a Blob URL. I'm concerned about all the extra work with Blobs which may get stuck in RAM. Sure would be nice to pass strings instead. -Charles
RE: [File API] Blob URI creation
In general we are OK with changing it to the autoRevoke behavior below, but
have some concerns around changing the default behavior.
Changing the default behavior is a breaking change and any apps which expect
the URL to work multiple times will now be broken. In Windows 8, we also
implemented the oneTimeOnly behavior and it was very widely used, these
consumers will be broken as well.
We would like to support autoRevoke as the default as it helps reduce the
chance of leaking unintentionally, but we think developers should have a way
to feature detect the new change. If a developer can feature detect which
default behavior is present, then they can reason about what to expect from the
API.
If a way is provided for developers to detect the change, then we support this
change. Additionally, we support the changes outlined in the bug at
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765, and feel it resolves
several of the edge cases we saw when implementing the File API.
From: Arun Ranganathan [mailto:aranganat...@mozilla.com]
Sent: Wednesday, July 11, 2012 1:20 PM
To: Glenn Maynard
Cc: Rich Tibbett; public-webapps; Arun Ranganathan; Jonas Sicking
Subject: Re: [File API] Blob URI creation
On May 30, 2012, at 6:48 PM, Glenn Maynard wrote:
On your main question, I've had the same thought in the past--a "url" property
on Blob which simply creates a new auto-revoking blob URL. I didn't bring it
up since I'm not sure if creating a URL for a blob is actually something you do
so often that it's worth having a shortcut. If so, a function is probably
better than a property--more future-proof, and it'd be unusual on the platform
to have a property that returns a different value every time you read it.
On Wed, May 30, 2012 at 1:50 PM, Rich Tibbett wrote:
Yes, this might be a better solution. I was working on what was available in
the editor's draft and looking for a way to remove the need to ever call
revokeObjectUrl.
This is part of what's wrong with oneTimeOnly--it *doesn't* actually completely
remove the need to call revokeObjectUrl. For example:
function f(blob) {
var url = URL.createObjectURL(blob, {oneTimeOnly: true});
if(showImage)
img.src = url;
else
URL.revokeObjectURL(url);
}
Without the revoke case, the URL (and so the whole blob) is leaked as it's
never actually used. autoRevoke doesn't have this problem.
Arun/Jonas: Can we hide this feature in the spec before more people implement
it, or at least tag it with "not ready for implementations" or something?
I'll do one better, and introduce autoRevoke semantics:
http://www.w3.org/TR/2012/WD-FileAPI-20120712/#creating-revoking
By default, this does not need a corresponding revokeObjectURL() call. In
order for Blob URLs to persist past a stable state (for that unit of script)
createObjectURL has to be invoked with autoRevoke set to false.
That is, you shouldn't ever have to pass a Blob URI obtained via Blob.getURL
through revokeObjectUrl because it assumes some auto-revocation behavior. Using
microtasks to release at the next stable state does seem ok as long as
developers have a very good understanding of when a Blob URI will be implicitly
revoked. Saying that you can use a Blob URI exactly once, as per onetimeonly
could still end up being easier to understand though.
(s/microtasks/stable states/; they're not quite the same)
It's actually a bit hard to understand (or easy to misunderstand), since
there's no clear concept of "using a URL". For example, if you start two XHR's
on the same URL one after the other in the same script, the order in which the
fetches actually begin is undefined (they happen in different task queues), so
which would succeed is undefined. (Some work would also be needed here for the
autoRevoke approach, but it's much simpler.)
autoRevoke is pretty simple from the user's perspective: the URL is revoked
when your script returns to the browser.
In fact, I think this addresses the lion's share of use cases, and if a
developer wants to explicitly create "longer lasting" Blob URLs, they have that
option (just not by default).
-- A*
[Bug 18558] New: [IndexedDB] Define error seen when key generator maximum value is reached
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18558
Summary: [IndexedDB] Define error seen when key generator
maximum value is reached
Product: WebAppsWG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jsb...@chromium.org
QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
The spec says:
"When the current number of a key generator reaches above the value 2^53
(9007199254740992) any attempts to use the key generator to generate a new key
will result in an error."
.. but the specifics of the error and how it manifests is not defined.
The logical place would be at the point where the key generator is queried, in
the "Object Store Storage Operation":
"If store uses a key generator and key is undefined, set key to the next
generated key."
In the Chrome implementation, if the key generator results in an error, the
storage operation fails at this point with a DataError.
This can be exercised by:
store = db.createObjectStore('store', {autoIncrement: true});
store.put('a', 9007199254740992);
r = store.put('b');
r.onerror = function(e) { alert(e.target.error.name); };
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
Re: Acceptable for CSS to add a "window.CSS" global?
TL;DR: Conway's law is already validated in this instance, but maybe there's no real harm, and stuff to like about the proposal anyway. On balance I think it is a good idea. (Plus a lot of stuff about @supports ...) On Tue, 14 Aug 2012 01:59:28 +0200, Tab Atkins Jr. wrote: On Mon, Aug 13, 2012 at 4:42 PM, Ian Hickson wrote: On Mon, 13 Aug 2012, Tab Atkins Jr. wrote: The CSSWG would like to add a new top-level object called "CSS" that we can hang several functions and constructors off of, so that we can avoid the excessive verbosity that's probably required if we just put everything on window. [...] Does anyone see any problems with this? Do we think there's a significant compat risk to claiming an all-caps "CSS" variable? Seems reasonable in principle, but there's a risk of running into Conway's law [...] The Conway's Law concern is reasonable, though minor. Noted. Hmm. I am not sure if it is minor or not. Depends how important you think clean architecture is - personally I think it is lovely but not something the Web has or relies on so I can live with what I think is a high probability of an API that reflects the CSS group more than anything else... (Right now, the only thing we want to add is a "supports()" function, which is the API version of the upcoming @supports rule. In the future, we'd like to add things like the CSSOM Value API constructors to it [...]) As a general rule, @supports and supports() sound like they're run into the antipattern [of hasFeature() returning useless information] @supports was designed very specifically to make this as small of a problem as possible. If a browser supports "foo: bar;" well enough to actually parse it and keep it around, it's - by definition - good enough for authors to use it. Maybe (but I am unconvinced). But when a browser just *says* it can handle it, that is not good enough on its own. While it's theoretically possible that a particular browser's implementation is really shitty so that you don't want to use it, in practice I don't think that's ever been a problem (or if it has, it's been rare enough that I don't remember it). Too make the thing useless for authors there doesn't have to be a terrible implementation, just different ones in different browsers. And browsers have differently implemented pretty basic parts of CSS before, unless my memory is playing tricks. There's also a granularity issue. [...] Valid in principle, but I don't think it's a big deal. There are some issues like that, but authors can know about them and work around them. Actually, this is the crux of the issue. Anything that relies on authors knowing the issues is something that makes the proposed use case for supports less interesting. On the other hand, it doesn't have to work perfectly to be useful, it just has to work well enough often enough to make using it worthwhile. [...] The failure of hasFeature() greatly informed the design of this feature. And yet the technical design boils down to the same thing - asking the browser a question about whether it can do something, where there is a penalty for answering "I can't". The penalty, quite often, is being told to advertise a rival product to the user. Without wanting to anthopomorphise companies, and still less software, this is something that hurts both the dignity and actual well-being of the browser, so the motivation to stretch the truth (an in equal measure distort what this feature tries to do) is pretty strong. The issue is social - if it were worse to lie in hasFeature than not having the feature requested, there would be no need for supports() since we could just add the CSS tests to hasFeature. Frankly, I am deeply sceptical that the CSS group has managed to solve the social problem sufficiently well to make the technical solution noticeably different from hasFeature. Which leads me to the conclusion that "Conway's Law" has already been borne out here. However... If you'd like to discuss the supports() function further, could you do it on www-style? I'd prefer this thread to stay on the original subject. Right. As Odin said, window.* is a pretty big collection, and being able to simplify CSS-specific stuff is probably going to bring more value than problems. Overall, I think the idea is reasonable. cheers Chaals -- Chaals - standards declaimer
Re: Acceptable for CSS to add a "window.CSS" global?
On Mon, 13 Aug 2012 20:19:29 +0200, Tab Atkins Jr. wrote: The CSSWG would like to add a new top-level object called "CSS" that we can hang several functions and constructors off of, so that we can avoid the excessive verbosity that's probably required if we just put everything on window Cool! While reviewing some @supports tests just a few weeks ago I in fact wondered about the same thing. We tend to have long names and they're not always that easy to remember or use. And @supports corresponds to CSS.supports() sure sounds much nicer than supportsCSS(). And it's not like we have too few functions hanging directly off window. Another benefit is that with a CSS top-level object, you can expand that in your debugger and hopefully get some relevant "documentation" right there, instead of looking for functions with "CSS" in them on window. FWIW I really like it. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
