DOM event detection
After a brief correspondence with Robin Berjon he suggested I post this suggestion here. After having problems with detecting support for the HTML5 'input' event ( http://goo.gl/XNSg5 http://goo.gl/rAa5f) I started wondering if there was a DOM specification for detecting support for DOM events in browsers. After a brief email correspondence with Robin Berjon, and looking around a bit myself, it appears that there is no specific mention of this in the current HTML5 or DOM specifications. There is some mention of DOM events being exposed as methods (http://goo.gl/TYm2k) but this may not necessarily apply to all DOM elements. Therefore, I'd like to suggest that we try to come up with a standard way of suggesting that support for DOM elements be exposed, to enable developers to tell which events are supported. One method that works in Webkit and Gecko for many methods, although I don't think it's in any W3C specification, is to include methods for each event them in the Event object, e.g.: 'CLICK' in Event; // true 'CHANGE' in Event; // true 'INPUT' in Event; // false Does that seem like a reasonable method of DOM event support detection? Could it be included as a recommendation in the specification somewhere? Cheers, Robin.
Re: Hash functions
I would love even a painfully slow implementation provided by the browser. I have encountered lots of cases where being able to talk a protocol requires computing a sha1 or an md5 hash. Speed has never been the problem for me, but external javascript library dependencies are painful to maintain. --Toni On Tue, Dec 21, 2010 at 2:42 AM, Glenn Maynard gl...@zewt.org wrote: Has a hash functions API been considered, so browsers can expose, for example, a native SHA-1 implementation? Doing this in JS is possible, but painfully slow, even with current JS implementations. Some fairly obvious use cases: - Avoid uploading a file to the server if it already has a copy. For example, if you attach a large file to an email, and you already have a copy of that file in your mailbox attached to another mail, don't upload the whole file; just send a reference the existing one. - Resumable file uploads. An implementation of a chunked, resumable uploader will want to validate that the file the user is sending is actually what's been received by the server so far, and roll back the transfer partially or completely if they're out of sync. - Local file validation and updating. A web-based game may want to save large blocks of resources locally, rather than depending on HTTP caching to do it, which is inappropriate for a game with several hundred megabytes or more of resources. Native hashing would help automatic updating of data. If there's a more appropriate place for this, let me know. -- Glenn Maynard
Re: Updates to FileAPI
I have updated the editor's draft of the File API (special winter solstice edition). In particular: On 12/20/10 8:32 PM, Michael Nordman wrote: On Mon, Dec 20, 2010 at 4:08 PM, Arun Ranganathana...@mozilla.com wrote: On 12/20/10 5:38 PM, Jian Li wrote: On Mon, Dec 20, 2010 at 2:10 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 20 Dec 2010, Arun Ranganathan wrote: http://dev.w3.org/2006/webapi/FileAPI/ Notably: 1. lastModifiedDate returns a Date object. I think it makes more sense to return a new Date object each time. We have the same issue with Metadata.modificationTime. There are more rigid conformance requirements around lastModifiedDate. http://dev.w3.org/2006/webapi/FileAPI/#dfn-lastModifiedDate (Ensure that your previous copy has been flushed). I think we have the expectation that any published URLs, that have not been explicitly revoked earlier, are jetisoned at some well defined document cleanup time... what hixie pointed to looks like a great place... http://www.whatwg.org/specs/web-apps/current-work/complete.html#unloading-document-cleanup-steps I've bolstered the lifetime conformance language with this: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime The only nagging doubt I have about this proposal is that the creation and revocation methods (static) are on window.URL, but the actual Blob object has an affiliated document, which upon cleanup flushes the URLs affiliated with it. We still need to address nits about event queue, abort, and sequenceT, but those will come in due course. -- A*
Re: Hash functions
On Mon, Dec 20, 2010 at 5:49 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/20/10 7:42 PM, Glenn Maynard wrote: Has a hash functions API been considered, so browsers can expose, for example, a native SHA-1 implementation? Doing this in JS is possible, but painfully slow, even with current JS implementations. Before we go further into this, can we quantify painfully slow so we have some idea of the magnitude of the problem? Using the testcase at https://bugzilla.mozilla.org/attachment.cgi?id=487844 but modifying the input string to be 768 chars, I see a current js implementation on modern laptop hardware take around 7 seconds to hash it 50,000 times. I get similar times for an MD5 implementation I found and chopped down. So I guess the question is how much data we want to be pushing through the hash function and what throughput we expect, and whether we think JS engines simply won't get there or will take too long to do so. Notice that all three of the OP's use-cases were based on checksumming files. I don't know how reading in a Blob and then hashing it would compare to just hashing an equivalent string, but I suspect it would have a decent perf hit. This seems like a pretty useful ability in general, enough so that it's probably worthwhile to build it in directly as a Blob.checksum() function or something. I still think it may be useful for the security use-case as well, where you explicitly want a slow hash to begin with. If JS imposes a slowdown on top of that, it could render a good hash too slow to actually use in practice. Plus, you have to depend on the hash implementation you pulled off the web or hacked together yourself, which you probably didn't manually verify before starting to use. ~TJ
Re: Updates to FileAPI
On Tue, 21 Dec 2010, Arun Ranganathan wrote: I've bolstered the lifetime conformance language with this: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime Just one minor nit, the unloading document cleanup steps get called both when unloading a document and when discarding a document, and may in the future be called in other situations also, so it's best to just say something like This specification defines the following unloading document cleanup step: ... rather than using the imperative (as part of the unloading document cleanup steps, user agents must...). (Another way to think about this is that there should really only be one MUST for each requirement, and there is already one that triggers the cleanup steps. You only want one MUST per requirement otherwise you end up with situations where you might have to technically do the same thing multiple times in order to fully comply with all the requirements.) The only nagging doubt I have about this proposal is that the creation and revocation methods (static) are on window.URL, but the actual Blob object has an affiliated document, which upon cleanup flushes the URLs affiliated with it. Window and Document objects have an almost 1:1 relationship. There is one edge case exception involving about:blank, but I don't think it causes an issue here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Updates to FileAPI
On Tue, Dec 21, 2010 at 11:31 AM, Arun Ranganathan a...@mozilla.com wrote: I have updated the editor's draft of the File API (special winter solstice edition). In particular: On 12/20/10 8:32 PM, Michael Nordman wrote: On Mon, Dec 20, 2010 at 4:08 PM, Arun Ranganathana...@mozilla.com wrote: On 12/20/10 5:38 PM, Jian Li wrote: On Mon, Dec 20, 2010 at 2:10 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 20 Dec 2010, Arun Ranganathan wrote: http://dev.w3.org/2006/webapi/FileAPI/ Notably: 1. lastModifiedDate returns a Date object. I think it makes more sense to return a new Date object each time. We have the same issue with Metadata.modificationTime. There are more rigid conformance requirements around lastModifiedDate. http://dev.w3.org/2006/webapi/FileAPI/#dfn-lastModifiedDate (Ensure that your previous copy has been flushed). I think we have the expectation that any published URLs, that have not been explicitly revoked earlier, are jetisoned at some well defined document cleanup time... what hixie pointed to looks like a great place... http://www.whatwg.org/specs/web-apps/current-work/complete.html#unloading-document-cleanup-steps I've bolstered the lifetime conformance language with this: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime The only nagging doubt I have about this proposal is that the creation and revocation methods (static) are on window.URL, but the actual Blob object has an affiliated document, which upon cleanup flushes the URLs affiliated with it. We still need to address nits about event queue, abort, and sequenceT, but those will come in due course. When a user agent unloads a document, as part of the unloading document cleanup steps, it MUST revoke a Blob URI which dereferences a Blob object in that document. Implementations MUST ensure that a Blob URI is revoked after URL.revokeObjectURL is called with that Blob URI as an argument. Implementations MUST respond with a 404 Not Found if a Blob URI is dereferenced after URL.revokeObjectURL is called on that paticular Blob URI. I don't know what a Blob object in that document means? That language is a confusing to me. The cleanup steps should revoke blob URIs that were created via a call to the URL.createObjectURL from within that document. Two different documents (docA and docB) may create two different URLs (urlA and urlB) for the same Blob. When docA is cleaned up, urlA should be revoke but urlB should not. -- A*
Re: Updates to FileAPI
On Tue, Dec 21, 2010 at 11:31 AM, Arun Ranganathan a...@mozilla.com wrote: There are more rigid conformance requirements around lastModifiedDate. http://dev.w3.org/2006/webapi/FileAPI/#dfn-lastModifiedDate The last modified date of the file; on getting, this MUST return a Date object [HTML5] with the last modified date on disk. On getting, user agents MUST create a new Date object with the last modified date on disk; a different Date object MUST be returned each time. On getting, if user agents cannot make this information available, they MUST return null; on getting, even if the user agent could make this information available on previous gets, if it cannot make this information available on the current access it MUST return null. This is worded really confusingly - there are 4 on gettings, and two of the phrases are just duplicating information expressed in previous phrases. Can we get something clearer, like this: The last modified date of the file. On getting, if user agents can make this information available, this MUST return a fresh Date object initialized to the last modified date of the file; otherwise, this MUST return null. ? ~TJ
Re: Updates to FileAPI
On 12/21/10 4:08 PM, Tab Atkins Jr. wrote: On Tue, Dec 21, 2010 at 11:31 AM, Arun Ranganathana...@mozilla.com wrote: There are more rigid conformance requirements around lastModifiedDate. http://dev.w3.org/2006/webapi/FileAPI/#dfn-lastModifiedDate The last modified date of the file; on getting, this MUST return a Date object [HTML5] with the last modified date on disk. On getting, user agents MUST create a new Date object with the last modified date on disk; a different Date object MUST be returned each time. On getting, if user agents cannot make this information available, they MUST return null; on getting, even if the user agent could make this information available on previous gets, if it cannot make this information available on the current access it MUST return null. This is worded really confusingly - there are 4 on gettings, and two of the phrases are just duplicating information expressed in previous phrases. Can we get something clearer, like this: The last modified date of the file. On getting, if user agents can make this information available, this MUST return a fresh Date object initialized to the last modified date of the file; otherwise, this MUST return null. This is a great correction (thanks for supplying good prose!) which I'll gladly make. I agree that it is confusing. -- A*
Re: Updates to FileAPI
On 12/21/10 4:07 PM, Michael Nordman wrote: On Tue, Dec 21, 2010 at 11:31 AM, Arun Ranganathana...@mozilla.com wrote: I have updated the editor's draft of the File API (special winter solstice edition). In particular: On 12/20/10 8:32 PM, Michael Nordman wrote: On Mon, Dec 20, 2010 at 4:08 PM, Arun Ranganathana...@mozilla.com wrote: On 12/20/10 5:38 PM, Jian Li wrote: On Mon, Dec 20, 2010 at 2:10 PM, Ian Hicksoni...@hixie.chwrote: On Mon, 20 Dec 2010, Arun Ranganathan wrote: http://dev.w3.org/2006/webapi/FileAPI/ Notably: 1. lastModifiedDate returns a Date object. I think it makes more sense to return a new Date object each time. We have the same issue with Metadata.modificationTime. There are more rigid conformance requirements around lastModifiedDate. http://dev.w3.org/2006/webapi/FileAPI/#dfn-lastModifiedDate (Ensure that your previous copy has been flushed). I think we have the expectation that any published URLs, that have not been explicitly revoked earlier, are jetisoned at some well defined document cleanup time... what hixie pointed to looks like a great place... http://www.whatwg.org/specs/web-apps/current-work/complete.html#unloading-document-cleanup-steps I've bolstered the lifetime conformance language with this: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime The only nagging doubt I have about this proposal is that the creation and revocation methods (static) are on window.URL, but the actual Blob object has an affiliated document, which upon cleanup flushes the URLs affiliated with it. We still need to address nits about event queue, abort, and sequenceT, but those will come in due course. When a user agent unloads a document, as part of the unloading document cleanup steps, it MUST revoke a Blob URI which dereferences a Blob object in that document. Implementations MUST ensure that a Blob URI is revoked after URL.revokeObjectURL is called with that Blob URI as an argument. Implementations MUST respond with a 404 Not Found if a Blob URI is dereferenced after URL.revokeObjectURL is called on that paticular Blob URI. I don't know what a Blob object in that document means? That language is a confusing to me. The cleanup steps should revoke blob URIs that were created via a call to the URL.createObjectURL from within that document. Two different documents (docA and docB) may create two different URLs (urlA and urlB) for the same Blob. When docA is cleaned up, urlA should be revoke but urlB should not. Both you and Ian make good nits about redundant conformance requirements as well as per-document cleanup. I'll take both nits into consideration and cleanup the spec. text. -- A*
Re: DOM event detection
It's actually a bug in Firefox[1] which unfortunately been around for a very long time, since 2003, and isn't isolated just on the input event it also affects the invalid event. For detecting events kangax has created a handy method called isEventSupported[2] which will detect 99% of events successfully, albeit not input or invalid events in FF due to the above mentioned bug. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=195696 [2] http://kangax.github.com/iseventsupported/ -Ryan On Tue, Dec 21, 2010 at 10:44 AM, Robin Winslow ro...@robinwinslow.co.ukwrote: After a brief correspondence with Robin Berjon he suggested I post this suggestion here. After having problems with detecting support for the HTML5 'input' event ( http://goo.gl/XNSg5 http://goo.gl/rAa5f) I started wondering if there was a DOM specification for detecting support for DOM events in browsers. After a brief email correspondence with Robin Berjon, and looking around a bit myself, it appears that there is no specific mention of this in the current HTML5 or DOM specifications. There is some mention of DOM events being exposed as methods (http://goo.gl/TYm2k) but this may not necessarily apply to all DOM elements. Therefore, I'd like to suggest that we try to come up with a standard way of suggesting that support for DOM elements be exposed, to enable developers to tell which events are supported. One method that works in Webkit and Gecko for many methods, although I don't think it's in any W3C specification, is to include methods for each event them in the Event object, e.g.: 'CLICK' in Event; // true 'CHANGE' in Event; // true 'INPUT' in Event; // false Does that seem like a reasonable method of DOM event support detection? Could it be included as a recommendation in the specification somewhere? Cheers, Robin.
Re: DOM event detection
I read Kangax's post, but I hadn't actually seen the tool on github, thanks for that. The way that one would hope Fx might support it is by providing an oninput method on the INPUT element and allowing you to support it that way. However, regardless of whether this is a bug in Fx or not, the main point is that the DOM specs as they stand don't actually specify a way that browsers should be exposing DOM event support. This is what I'm hoping we can change, so in future there's a reliable method of detecting DOM event support in all browsers. Robin. On 21 December 2010 22:37, Ryan Seddon seddon.r...@gmail.com wrote: It's actually a bug in Firefox[1] which unfortunately been around for a very long time, since 2003, and isn't isolated just on the input event it also affects the invalid event. For detecting events kangax has created a handy method called isEventSupported[2] which will detect 99% of events successfully, albeit not input or invalid events in FF due to the above mentioned bug. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=195696 [2] http://kangax.github.com/iseventsupported/ -Ryan On Tue, Dec 21, 2010 at 10:44 AM, Robin Winslow ro...@robinwinslow.co.ukwrote: After a brief correspondence with Robin Berjon he suggested I post this suggestion here. After having problems with detecting support for the HTML5 'input' event ( http://goo.gl/XNSg5 http://goo.gl/rAa5f) I started wondering if there was a DOM specification for detecting support for DOM events in browsers. After a brief email correspondence with Robin Berjon, and looking around a bit myself, it appears that there is no specific mention of this in the current HTML5 or DOM specifications. There is some mention of DOM events being exposed as methods (http://goo.gl/TYm2k) but this may not necessarily apply to all DOM elements. Therefore, I'd like to suggest that we try to come up with a standard way of suggesting that support for DOM elements be exposed, to enable developers to tell which events are supported. One method that works in Webkit and Gecko for many methods, although I don't think it's in any W3C specification, is to include methods for each event them in the Event object, e.g.: 'CLICK' in Event; // true 'CHANGE' in Event; // true 'INPUT' in Event; // false Does that seem like a reasonable method of DOM event support detection? Could it be included as a recommendation in the specification somewhere? Cheers, Robin.
Re: Rename XBL2 to something without X, B, or L?
How 'bouts a shorter version of Tab's suggestion: Web Components ? On Thu, Dec 16, 2010 at 5:59 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 16 Dec 2010 14:51:39 +0100, Robin Berjon ro...@berjon.com wrote: On Dec 14, 2010, at 22:24 , Dimitri Glazkov wrote: Looking at the use cases and the problems the current XBL2 spec is trying address, I think it might be a good idea to rename it into something that is less legacy-bound? I strongly object. We have a long and proud tradition of perfectly horrible and meaningless names such as XMLHttpRequest. I don't see why we'd ever have to change. Shadow HTML Anonymous DOm for the Web! Cause I know you are being serious I will be serious as well and point out that XMLHttpRequest's name is legacy bound as that is what implementations call it and applications are using. XBL2 has none of that. -- Anne van Kesteren http://annevankesteren.nl/
Re: Hash functions
On Tue, Dec 21, 2010 at 2:58 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Notice that all three of the OP's use-cases were based on checksumming files. I don't know how reading in a Blob and then hashing it would compare to just hashing an equivalent string, but I suspect it would have a decent perf hit. This seems like a pretty useful ability in general, enough so that it's probably worthwhile to build it in directly as a Blob.checksum() function or something. I wouldn't expect a big performance hit from that. Start reading the next block (say, 1MB at a time) asynchronously, run the SHA1 for the previous block while that's running, and repeat. (I'd do the whole thing in a worker thread, so the synchronous SHA1 call itself wouldn't bog down the UI.) I'm not up on the internals of the file API implementations, but it seems like that should be pretty efficient. (Even the async requests should be unnecessary, since the OS should be doing read-ahead anyway.) I still think it may be useful for the security use-case as well, where you explicitly want a slow hash to begin with. If JS imposes a slowdown on top of that, it could render a good hash too slow to actually use in practice. Plus, you have to depend on the hash implementation you pulled off the web or hacked together yourself, which you probably didn't manually verify before starting to use. I had to think pretty hard to come up with a use case for something like bcrypt in Javascript, and the only one I've come up with seems somewhat flimsy: Sites could avoid ever sending passwords from the client to the server. Instead of sending a password directly, the server sends the salt for the user's password (or a random salt for a new password); the client sends the password hashed with that salt. This means that sniffing the traffic--even on the server itself where you might in underneith HTTPS--couldn't record a large log of user passwords to be used elsewhere; the server would never know the password to begin with, not even when the user first sets his password. The flimsy part is it depends on the Javascript doing the hashing being secure; if the server is compromised, the script itself could just be replaced. That's still potentially a win, because that's harder to hide--the backdoored authentication code now has to stash the unencrypted password in the request somewhere, rather than being done in the server where it's completely invisible to users. Did you have any particular uses in mind? -- Glenn Maynard
Re: Updates to FileAPI
On Tue, Dec 21, 2010 at 2:31 PM, Arun Ranganathan a...@mozilla.com wrote: I've bolstered the lifetime conformance language with this: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime The only nagging doubt I have about this proposal is that the creation and revocation methods (static) are on window.URL, but the actual Blob object has an affiliated document, which upon cleanup flushes the URLs affiliated with it. Related to object URL expiration, is there a mechanism to clone an object URL? In particular, I'm thinking of what happens if you pass an object URL to a Web Worker thread or another window in the same origin: it may want to be able to use that URL without it expiring due to the original window going away. I suppose this would simply mean dereferencing the object URL back to a Blob (or File, or whatever its original Blob subclass was) in the new context, and then if needed creating a new object URL from it--though there doesn't seem to be a way to get a Blob back from an object URL yet. -- Glenn Maynard
Re: Updates to FileAPI
On Tue, Dec 21, 2010 at 4:12 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Dec 21, 2010 at 2:31 PM, Arun Ranganathan a...@mozilla.com wrote: I've bolstered the lifetime conformance language with this: http://dev.w3.org/2006/webapi/FileAPI/#lifeTime The only nagging doubt I have about this proposal is that the creation and revocation methods (static) are on window.URL, but the actual Blob object has an affiliated document, which upon cleanup flushes the URLs affiliated with it. Related to object URL expiration, is there a mechanism to clone an object URL? In particular, I'm thinking of what happens if you pass an object URL to a Web Worker thread or another window in the same origin: it may want to be able to use that URL without it expiring due to the original window going away. I suppose this would simply mean dereferencing the object URL back to a Blob (or File, or whatever its original Blob subclass was) in the new context, and then if needed creating a new object URL from it--though there doesn't seem to be a way to get a Blob back from an object URL yet. The solution is to instead pass the Blob object to the worker and inside the worker call URL.createObjectURL(blob). That way you get a URL whose lifetime is tied to that of the worker. But yes, if you've lost track of the Blob and just have the URL that isn't possible, so don't loose track of your blobs :-) / Jonas
Re: Rename XBL2 to something without X, B, or L?
I like Web Components. -- Dirk On Tue, Dec 21, 2010 at 3:34 PM, Alex Russell slightly...@google.com wrote: How 'bouts a shorter version of Tab's suggestion: Web Components ? On Thu, Dec 16, 2010 at 5:59 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 16 Dec 2010 14:51:39 +0100, Robin Berjon ro...@berjon.com wrote: On Dec 14, 2010, at 22:24 , Dimitri Glazkov wrote: Looking at the use cases and the problems the current XBL2 spec is trying address, I think it might be a good idea to rename it into something that is less legacy-bound? I strongly object. We have a long and proud tradition of perfectly horrible and meaningless names such as XMLHttpRequest. I don't see why we'd ever have to change. Shadow HTML Anonymous DOm for the Web! Cause I know you are being serious I will be serious as well and point out that XMLHttpRequest's name is legacy bound as that is what implementations call it and applications are using. XBL2 has none of that. -- Anne van Kesteren http://annevankesteren.nl/
Re: Updates to FileAPI
On Tue, Dec 21, 2010 at 7:17 PM, Jonas Sicking jo...@sicking.cc wrote: The solution is to instead pass the Blob object to the worker and inside the worker call URL.createObjectURL(blob). That way you get a URL whose lifetime is tied to that of the worker. But yes, if you've lost track of the Blob and just have the URL that isn't possible, so don't loose track of your blobs :-) Yeah. Sorry for the noise--still wrapping my head around how all these new APIs fit together. :) -- Glenn Maynard
