Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On 11/29/12 2:32 AM, Boris Zbarsky wrote: On 11/29/12 2:07 AM, Gordon P. Hemsley wrote: I imagine this ties in, too, to the issues with sniffing CSS files that has been raised elsewhere: https://bugzilla.mozilla.org/show_bug.cgi?id=560388 https://bugzilla.mozilla.org/show_bug.cgi?id=562377 Neither one of those has anything to do with application/octet-stream as far as I can tell. Those cover cases in which data is sent with either no Content-Type header or with such a header which can't even be parsed as major/minor. Neither of which is true if the data says appliction/octet-stream. Oh, and the other important bit is that there is no sniffing CSS involved. If the load is for a link rel=stylesheet and the server doesn't send a content type or sends one that can't be parsed, Gecko just treats the data as CSS. That's not the same thing as sniffing the data. ;) -Boris
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Thu, Nov 29, 2012 at 2:32 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 11/29/12 2:07 AM, Gordon P. Hemsley wrote: So perhaps a more useful question would be what to do in situations like that—should mimesniff treat application/octet-stream as a type supported by the browser for the purposes of sniffing images, audio or video, fonts, or other media types? The way it works right now is that http://www.whatwg.org/specs/web-apps/current-work/#mime-types says: The MIME type application/octet-stream with no parameters is never a type that the user agent knows it cannot render. User agents must treat that type as equivalent to the lack of any explicit Content-Type metadata when it is used to label a potential media resource. So for the purpose of sniffing media loads specifically, that type is treated just like no type at all. But first you have to know it's a media load. Oh, this is probably the location where the HTML spec doesn't currently, but eventually should, reference the rules for sniffing audio and video specifically in mimesniff. (Is this where Opera implements such rules?) Is it just me (and my late-night reading), or is that section contradictory on how to treat application/octet-stream? At one point it says, The MIME type application/octet-stream with no parameters is never a type that the user agent knows it cannot render. User agents must treat that type as equivalent to the lack of any explicit Content-Type metadata when it is used to label a potential media resource. But later it says, The canPlayType(type) method must return the empty string if type is a type that the user agent knows it cannot render or is the type application/octet-stream; This seems to me to be unclear as to when sniffing of the audio/video resource occurs, and what it is used for. I imagine this ties in, too, to the issues with sniffing CSS files that has been raised elsewhere: https://bugzilla.mozilla.org/show_bug.cgi?id=560388 https://bugzilla.mozilla.org/show_bug.cgi?id=562377 Neither one of those has anything to do with application/octet-stream as far as I can tell. Those cover cases in which data is sent with either no Content-Type header or with such a header which can't even be parsed as major/minor. Neither of which is true if the data says appliction/octet-stream. I was grouping them together because they both rely on context clues for modifying the sniffing (fallback) behavior, but we can discuss them separately if that's easier. -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On 11/29/12 2:53 AM, Gordon P. Hemsley wrote:
At one point it says, The MIME type application/octet-stream with
no parameters is never a type that the user agent knows it cannot
render. User agents must treat that type as equivalent to the lack of
any explicit Content-Type metadata when it is used to label a
potential media resource.
But later it says, The canPlayType(type) method must return the empty
string if type is a type that the user agent knows it cannot render or
is the type application/octet-stream;
What's the contradiction? We have set S = { types the user agent knows
it cannot render }. We have set T = S union { application/octet-stream }
What the above statements tell us so far is:
1) T != S
2) canPlayType(type) must return empty string for all types in T.
But later on in the resource selection algorithm there are certain
actions taken for elements of S only.
This seems to me to be unclear as to when sniffing of the audio/video
resource occurs, and what it is used for.
It's used for actually showing the video even if it's sent as
application/octet-stream.
I was grouping them together because they both rely on context clues
for modifying the sniffing (fallback) behavior
So first of all, sniffing and default handling are not the same
thing at all.
But yes, context matters for determining default handling and also for
determining sniffing.
-Boris
Re: [whatwg] Proposal: Add window.getLastError (or modify invocation arguments of window.onerror)
On Thu, 29 Nov 2012 04:35:21 +0100, Ian Hickson i...@hixie.ch wrote: Having the exception object, if any, in the onerror callback, seems reasonable, and would indeed limit how many more arguments we may have to add over the years. It seems that providing it as an argument would be better than as a global, though. One question is what should happen with exceptions that propagate upwards in the case of dedicated workers. Should a new exception object be created for each worker up the chain, and finally for window? ErrorEvent would also need a new member for this. -- Simon Pieters Opera Software
Re: [whatwg] proposal for a location.domain property
On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak m...@apple.com wrote: I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them. For the URL http://www.apple.com/;, apple.com would be the domain, and com would be the TLD. Yes, but for the URL http://www.google.co.uk/; you would need to have publicsuffix.org information in order to determine that the effective domain is google.co.uk and not co.uk. I'm not going to add this because cookies and document.domain are not good use cases for this. Cookies should eventually move to an origin-based security model (probably via some kind of opt-in) and document.domain should simply be avoided. (Ian asked me to reply to this thread https://www.w3.org/Bugs/Public/show_bug.cgi?id=20011 as the URL Standard now deals with these attributes.) -- http://annevankesteren.nl/
[whatwg] Notifications API: minor change
Hi, Per http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0116.html I removed the string coercion done in the Notifications API. It is now up to the UI layer how to deal with lone surrogates, similar to how that is handled elsewhere in the platform. https://github.com/whatwg/notifications/commit/463112f1d38fed73eef9b8a0bd6f3fd68dc80c2d http://notifications.spec.whatwg.org/ Kind regards, -- http://annevankesteren.nl/
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Thu, Nov 29, 2012 at 3:02 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/29/12 2:53 AM, Gordon P. Hemsley wrote:
At one point it says, The MIME type application/octet-stream with
no parameters is never a type that the user agent knows it cannot
render. User agents must treat that type as equivalent to the lack of
any explicit Content-Type metadata when it is used to label a
potential media resource.
But later it says, The canPlayType(type) method must return the empty
string if type is a type that the user agent knows it cannot render or
is the type application/octet-stream;
What's the contradiction? We have set S = { types the user agent knows it
cannot render }. We have set T = S union { application/octet-stream }
What the above statements tell us so far is:
1) T != S
2) canPlayType(type) must return empty string for all types in T.
But later on in the resource selection algorithm there are certain actions
taken for elements of S only.
This seems to me to be unclear as to when sniffing of the audio/video
resource occurs, and what it is used for.
It's used for actually showing the video even if it's sent as
application/octet-stream.
The apparent contradiction occurs when, e.g., an Opus file is tagged
as application/octet-stream.
If I understand correctly, a UA would return when canPlayType() is
called against such a file—but then the file would actually play
because it is later sniffed as application/ogg.
Am I missing something?
--
Gordon P. Hemsley
m...@gphemsley.org
http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On 11/29/12 12:45 PM, Gordon P. Hemsley wrote: The apparent contradiction occurs when, e.g., an Opus file is tagged as application/octet-stream. If I understand correctly, a UA would return when canPlayType() is called against such a file canPlayType is not called against a file. It's called with a single argument which is a string MIME type. If you pass application/octet-stream, it will return . Its behavior does not depend on any state of the element it's called on (like what it's actually pointing to, etc); only on the string passed in. but then the file would actually play because it is later sniffed as application/ogg. Am I missing something? I think you're misunderstanding what canPlayType does? -Boris
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Thu, Nov 29, 2012 at 12:57 PM, Boris Zbarsky bzbar...@mit.edu wrote: canPlayType is not called against a file. It's called with a single argument which is a string MIME type. If you pass application/octet-stream, it will return . Its behavior does not depend on any state of the element it's called on (like what it's actually pointing to, etc); only on the string passed in. Oh, I see. My mistake. (One should never attempt to understand something after 2 AM.) So... are there any additional places where application/octet-stream should be treated as if the media type was undefined? Or is this conversation moot now? -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On 11/29/12 1:11 PM, Gordon P. Hemsley wrote: So... are there any additional places where application/octet-stream should be treated as if the media type was undefined? Or is this conversation moot now? To my knowledge, the only places in the web platform that special-case application/octet-stream like this are media and object... And for object I believe it falls back to @type, not to data sniffing, but it's been a while. -Boris
Re: [whatwg] [mimesniff] Sniffing archives
To be clear, I'm asking this because I would like to remove the sniffing of archive types from the mimesniff spec if there aren't any valid usecases. On Wed, Nov 28, 2012 at 12:18 PM, Gordon P. Hemsley gphems...@gmail.com wrote: The mimesniff spec currently includes signatures for ZIP, gzip, and RAR archive formats. However, no major browser seems to support them natively (they all prompt for download), and it's not clear whether the type detection is a product of the browser code or the OS, or whether it is used beyond choosing an appropriate file extension for the download. Are there any valid usecases for explicitly sniffing archive formats instead of letting them default to application/octet-stream like other binary files would? Note that Henri Sivonen has previously raised the issue that ZIP-based formats (like office suite documents), for example, would be misleadingly sniffed as ZIP files, and there is no easy way around that. -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Thu, 29 Nov 2012, Gordon P. Hemsley wrote: The apparent contradiction occurs when, e.g., an Opus file is tagged as application/octet-stream. If I understand correctly, a UA would return when canPlayType() is called against such a file—but then the file would actually play because it is later sniffed as application/ogg. canPlayType() isn't called against files, it's called against MIME type strings. The type application/octet-stream isn't a video or audio file type, so we know that the browsers can't play files actually of that type, any more than the browsers can't play videos of type text/css. But when a file is labeled with that type, we know it's probably mislabeled, so we try to do something more useful. On another note, the spec's current behavior with media elements and sniffing is actually very much up in the air, since the last time I worked on this I could not get browser vendors to agree on what to implement. Search for the note starting This specification does not currently say whether or how to check the MIME types of the media resources. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] proposal for a location.domain property
On Nov 29, 2012, at 4:31 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak m...@apple.com wrote: I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them. For the URL http://www.apple.com/;, apple.com would be the domain, and com would be the TLD. Yes, but for the URL http://www.google.co.uk/; you would need to have publicsuffix.org information in order to determine that the effective domain is google.co.uk and not co.uk. I'm not going to add this because cookies and document.domain are not good use cases for this. Cookies should eventually move to an origin-based security model (probably via some kind of opt-in) and document.domain should simply be avoided. (Ian asked me to reply to this thread https://www.w3.org/Bugs/Public/show_bug.cgi?id=20011 as the URL Standard now deals with these attributes.) To be clear, I don't support adding either location.domain or location.tld. It was messages earlier in the thread that asked for it. My remark above was just a pedantic correction. - Maciej
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley gphems...@gmail.com wrote: Based on my reading of the source code, it seems that Gecko treats a resource served as 'application/octet-stream' as an unknown type which is sniffed as if no Content-Type was specified. Are there security implications with doing this? Yes, there are very large security consequences. I'm sorry that I don't have time to respond to all of these threads in detail, but I'm worried that you don't understand the consequences of the changes you're proposing to this specification. I'm not sure how to help you succeed here, but tweaking things in the spec without a compelling reason for doing so is not likely to lead to a useful specification. I spent a great deal of time and effort studying the behaviors of many user agents and of a massive amount of content on the web. I'm certainly willing to believe that the spec can be improved, but if you don't understand these sorts of basic things about content sniffing, I worry that changes that you make to the spec won't be improvements. Adam
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On Thu, Nov 29, 2012 at 2:30 PM, Adam Barth w...@adambarth.com wrote: On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley gphems...@gmail.com wrote: Based on my reading of the source code, it seems that Gecko treats a resource served as 'application/octet-stream' as an unknown type which is sniffed as if no Content-Type was specified. Are there security implications with doing this? Yes, there are very large security consequences. I'm sorry that I don't have time to respond to all of these threads in detail, but I'm worried that you don't understand the consequences of the changes you're proposing to this specification. I'm not sure how to help you succeed here, but tweaking things in the spec without a compelling reason for doing so is not likely to lead to a useful specification. I spent a great deal of time and effort studying the behaviors of many user agents and of a massive amount of content on the web. I'm certainly willing to believe that the spec can be improved, but if you don't understand these sorts of basic things about content sniffing, I worry that changes that you make to the spec won't be improvements. Adam I and others have already made clear that I was misreading the Mozilla source code. I'm aware of the security implications of interpreting a resource as something other than what the Content-Type header says. The whole reason I sent the original e-mail was because I thought Mozilla was sniffing application/octet-stream in a way that it shouldn't, and I wanted to clarify whether there was something I was missing. I think you need to tone down your worry about my changes to the spec. If I didn't have concern for the security implications for a change, I wouldn't be sending an e-mail to the list about them, would I? -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] [mimesniff] Sniffing archives
These are supported in Chrome. That's what causes the download. From your comment, it's not clear to me if you are correctly reverse engineering existing user agents. The techniques we used to create this list originally are quite sophisticated and involved a massive amount of data [1]. It would be a shame if you destroyed that work because you didn't understand it. Adam [1] http://www.adambarth.com/papers/2009/barth-caballero-song.pdf On Thu, Nov 29, 2012 at 10:42 AM, Gordon P. Hemsley gphems...@gmail.com wrote: To be clear, I'm asking this because I would like to remove the sniffing of archive types from the mimesniff spec if there aren't any valid usecases. On Wed, Nov 28, 2012 at 12:18 PM, Gordon P. Hemsley gphems...@gmail.com wrote: The mimesniff spec currently includes signatures for ZIP, gzip, and RAR archive formats. However, no major browser seems to support them natively (they all prompt for download), and it's not clear whether the type detection is a product of the browser code or the OS, or whether it is used beyond choosing an appropriate file extension for the download. Are there any valid usecases for explicitly sniffing archive formats instead of letting them default to application/octet-stream like other binary files would? Note that Henri Sivonen has previously raised the issue that ZIP-based formats (like office suite documents), for example, would be misleadingly sniffed as ZIP files, and there is no easy way around that. -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
Re: [whatwg] AppCache Error events
So are there no objections to this, should I draft a change to the spec? -Dave On Mon, Nov 26, 2012 at 12:00 PM, David Barrett-Kahn d...@google.com wrote: Right now this event contains no structured information, just an error message. It'd be helpful to us to know more about what failed, so we can know what to report to the server and take action on. It's hard to distinguish cache update failures due to just being offline from those which are actually causing trouble. In the second case it's also hard to work out which resource is proving unavailable and why. One way to do this would be to create an AppCacheError subclass, with an errorCode parameter, and also nullable url and httpResponseCode properties. Potential error codes: * couldn't fetch manifest (includes url and httpResponseCode) * pre and post update manifest fetches mismatched (includes url) * fetching a resource failed (includes url and httpResponseCode) Related bug: https://code.google.com/p/chromium/issues/detail?id=161753 Thoughts? -Dave -- -Dave
Re: [whatwg] AppCache Error events
On Thu, 29 Nov 2012, David Barrett-Kahn wrote: So are there no objections to this, should I draft a change to the spec? The process, insofar as we have one, is what is described here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F At some point, I get around to examining all the e-mails on a topic, and I try to determine what level of interest there is from implementors, and then I respond. Right now my lag is about four months, though it tends to be longer for requests for new features and shorter for major bug fixes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache Error events
Sounds reasonable to me. Webkit and chromium expose information like this via the inspector console so users/developers at that can better diagnose problems locally. Makes sense to also expose that info to app logic so developers could diagnose from afar. On Thu, Nov 29, 2012 at 11:40 AM, David Barrett-Kahn d...@google.com wrote: So are there no objections to this, should I draft a change to the spec? -Dave On Mon, Nov 26, 2012 at 12:00 PM, David Barrett-Kahn d...@google.com wrote: Right now this event contains no structured information, just an error message. It'd be helpful to us to know more about what failed, so we can know what to report to the server and take action on. It's hard to distinguish cache update failures due to just being offline from those which are actually causing trouble. In the second case it's also hard to work out which resource is proving unavailable and why. One way to do this would be to create an AppCacheError subclass, with an errorCode parameter, and also nullable url and httpResponseCode properties. Potential error codes: * couldn't fetch manifest (includes url and httpResponseCode) * pre and post update manifest fetches mismatched (includes url) * fetching a resource failed (includes url and httpResponseCode) Related bug: https://code.google.com/p/chromium/issues/detail?id=161753 Thoughts? -Dave -- -Dave
Re: [whatwg] Adding crossorigin= to more elements
On Wed, 28 Nov 2012, Boris Zbarsky wrote: On 11/28/12 7:42 PM, Ian Hickson wrote: Done, at least on the HTML side. For now it just makes .sheet return null for cross-origin resources. Pretty sure that's not web-compatible... Yeah, I don't expect it is. This stuff is going to change as part of the bug below though so I'm not too worried for now. If that's not quite right, please update this bug with the details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703 Done. Thanks. An open issue: what to do about @import? I haven't done anything magic here yet. Inheriting the CORS mode from the importing sheet is a bit weird, and I wasn't quite sure I wanted to make CSS syntax changes at this time. Inheriting the mode isn't so bad, all it really does is decide whether or not to send an Origin header. Not quite. It also affects what happens when the server doesn't respond with an appropriate Allow-Origin. A CORS-enabled load from a server that knows nothing about CORS will throw away the sheet, while a no-CORS load will happily apply the sheet to the page (but not give access to its data). So inheriting the mode can cause drastic changes in behavior compared to not inheriting it... Well, yeah, but the sheet knows which mode it's in, so I don't think that part of it is a big deal. If the CORS mode is inherited from the importing sheet, then I think the origin for the fetch should be the page, not the importing sheet, since the page is what would get access to the stylesheet data. Right, the origin of the importing sheet in this situation is the origin of the page that imported it, not the origin of its URL. That's what CORS does, it changes the effective origin of a resource from being the origin its URL would suggest it had, to being the origin of its caller. That's not quite correct. It changes the _object_ origin to that of the caller. It doesn't change the _subject_ origin. True (assuming we define those terms somewhere). The real issue here is that CSS is different than other things we've applied CORS to before, in that it is, to some level, alive. Before we've applied it to bitmaps (that can't do anything), scripts (that aren't in any way limited in the first place), and media (that can't do anything). This is the first time, I think, that we've used CORS with something that can do something with its privileges. Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. On Wed, 28 Nov 2012, Boris Zbarsky wrote: Oh, I see. You've added this taint thing, which you're using for the CSS bit. That only applies when there's no crossorigin= attribute, unless I made a mistake in the speccing. I don't believe Gecko has any such concept. Well presumably you don't block all cross-origin loads of CSS when there's no crossorigin= attribute. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A link rel=stylesheet scoped usecase
On Fri, 8 Jun 2012, Kang-Hao (Kenny) Lu wrote: (12/06/08 7:28), Ian Hickson wrote: It still seems like a bit of an edge case, so I think it's ok for us to continue to rely on @import for this for now. But we should keep an eye out for how often people use this technique; if it is indeed something that comes up a lot, then introducing scoped= on link rel=stylesheet would make sense. (12/03/03 2:03), Kang-Hao (Kenny) Lu wrote: A reader of html5doctor had the same problem too[1] and I can certainly image other people being confused by this. [1] http://html5doctor.com/the-scoped-attribute/#link which I mentioned, Googling the string html5 scoped @import gives me the following sites which mention this technique, even if there's only one browser supporting the 'scoped' attribute at the moment: [2][3][4] [2] http://www.codingforums.com/showthread.php?t=242411#postcount1154993 [3] http://www.webdirections.org/blog/on-the-abominable-proposed-html5-scoped-attribute-for-style-elements/#comment-222761 [4] http://www.peterrknight.com/loading-javascript-and-css-mid-page-html5-wordpress-passing-validation-part-1/ Yeah, that's fair enough. Righ now I can't find any browsers that implement style scoped. Unless link scoped is preferred by vendors than style scoped, I'd rather get one implemented and proven to work before we add more, so I still haven't added link scoped. To make sure I don't forget about this, though, I've filed it as a bug and will mark it LATER. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20166 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Exposing framerate / statistics of video playback and related feedback
On Tue, 1 May 2012, Charles Pritchard wrote: The list looked at having a (canvas) ctx.stream = mediaElement; option to better copy frames from a media stream into Canvas. I don't think that the assignment operator will work, but it does seem like we could optimize our drawImage calls to only happen when needed. At present, we simply would run requestAnimationFrame. But, if a video stream is operating on a slower frame rate than rAF, then the drawImage + rAF method will be wasteful. I've suggested an onframeready event; it seems as though that event could also carry the number of dropped frames. I haven't added this, because copying a video one frame at a time doesn't seem like an efficient way to do anything. Some sort of mechanism like what I had proposed for WebRTC (not sure if it's still in there) seems like a more solid solution, letting the browser do all the heavy lifting (potentially off the main thread). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding crossorigin= to more elements
On 11/29/12 5:09 PM, Ian Hickson wrote: Well, yeah, but the sheet knows which mode it's in, so I don't think that part of it is a big deal. Maybe. Problems can arise with a sheet that itself sends CORS headers but links to sheets that don't and that's tested in a UA that doesn't do link crossorigin. But OK. I'll see about inheriting the CORS mode. The real issue here is that CSS is different than other things we've applied CORS to before, in that it is, to some level, alive. Yep. See https://bugzilla.mozilla.org/show_bug.cgi?id=732209#c1 for a (probably non-exhaustive) list of possible meanings for CORS here. I implemented option 5 in Gecko. Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. Heh. Does it affect things like CSP in any way? On Wed, 28 Nov 2012, Boris Zbarsky wrote: Oh, I see. You've added this taint thing, which you're using for the CSS bit. That only applies when there's no crossorigin= attribute, unless I made a mistake in the speccing. Oh, ok. Sorry. Reading diffs of HTML is a pain. :( Well presumably you don't block all cross-origin loads of CSS when there's no crossorigin= attribute. :-) Sure. We don't do any sort of tainting either, though; we simply remember the origin of the CSS (where it was actually loaded from, post-redirect, not the original URI) and do a same-origin check when you try to use the CSSOM on it. Note that this check is done against the effective script origin of the script doing the CSSOM access, which may not actually match the origin of the page the CSS is loaded for, etc. Not sure whether the tainting setup you describe is equivalent to that, though I doubt it is. -Boris
Re: [whatwg] Adding crossorigin= to more elements
On Thu, 29 Nov 2012, Boris Zbarsky wrote: Anyway, this is somewhat moot to me because it'll all have to be defined by whatever spec it is that currently says that a CSS sheet on http: can't import an image on file:, etc. Heh. Does it affect things like CSP in any way? No idea. Adam? That only applies when there's no crossorigin= attribute, unless I made a mistake in the speccing. Oh, ok. Sorry. Reading diffs of HTML is a pain. :( Yeah, couldn't agree more. If you have any idea how I can improve this, by the way, let me know. I tried running HTML diff tools for a while, but couldn't find one that actually could handle a 5MB file, and in any case they didn't really make things any more readable than plain text diffs in practice. Sure. We don't do any sort of tainting either, though; we simply remember the origin of the CSS (where it was actually loaded from, post-redirect, not the original URI) and do a same-origin check when you try to use the CSSOM on it. Note that this check is done against the effective script origin of the script doing the CSSOM access, which may not actually match the origin of the page the CSS is loaded for, etc. Not sure whether the tainting setup you describe is equivalent to that, though I doubt it is. The behaviour called tainting in this context in the spec just means treat as a cross-origin resource as opposed to treat as a network failure. The term comes from the first time I introduced crossorigin=, which was for img, where the default behaviour of cross-origin images as opposed to same-origin images is that they taint the canvas. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding crossorigin= to more elements
On 11/29/12 9:44 PM, Ian Hickson wrote: The behaviour called tainting in this context in the spec just means treat as a cross-origin resource Right. My point was that cross-origin for the case of stylesheet at least in Gecko depends on the origin of the script that tries to modify them, not on the origin of the document that linked to them... Wish I had any bright idea on HTML diffs. :( -Boris
Re: [whatwg] Load events fired during onload handlers
On Mon, 30 Jul 2012, James Graham wrote:
There seems to be general agreement (amongst browsers, not yet the spec)
that if a document does something that causes a new load event from
within an onload handler (document.open/document.close) the second load
event is not dispatched. This also applies to the load event on iframe
elements if an event handler in the iframe would synchronously cause a
second load event to fire.
There is not agreement about what happens where there are multiple
frames e.g. if a load event handler on iframe element A would cause a
load event in iframe B, should the handler on B fire. Gecko says yes,
WebKit no. There is a slightly rubbish demo at [1].
[1] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1686
On Tue, 31 Jul 2012, Boris Zbarsky wrote:
Gecko fires the load event on the iframe as part of the default action
of the load event on the window inside that iframe. I think the spec
might actually call for it to fire async instead, though I haven't
tested what other UAs do there.
Per spec it's effectively async. More importantly, though, per spec the
'load' event on the iframe is delayed by some stuff that the 'load'
event _in_ the iframe isn't delayed by, e.g. readyState changes,
pageshow is fired, and delayed printing steps are executed, between them.
The code for firing the load event looks somewhat like this:
if (!mEODForCurrentDocument) {
mIsExecutingOnLoadHandler = true;
// Fire onload here
mIsExecutingOnLoadHandler = false;
mEODForCurrentDocument = true;
}
and the handling for document.open() sets mEODForCurrentDocument to
false. Now what happens is we enter the above code for the normal load.
We fire the onload handler, which does the open()/write()/close() thing.
That tries to set mEODForCurrentDocument to false, but of course it's
already false. When close() happens, onload does NOT fire sync from the
close() call, because there are still outstanding async tasks on the new
document that block onload. So we unwind the stack to the code above,
and set mEODForCurrentDocument to true, and block any further firing of
onload for this document until another open() call happens.
Fundamentally, that looks like a bug in the handling of
mEODForCurrentDocument, really.
So if either that bug were fixed or item #1 above were changed, I think
you'd get two load events here in Gecko right now.
I haven't changed the spec to match Gecko here, since you seem open to
changing Gecko. :-)
On Mon, 30 Jul 2012, James Graham wrote:
On 07/30/2012 05:44 PM, Boris Zbarsky wrote:
On 7/30/12 11:10 AM, James Graham wrote:
I don't think I have a strong opinion about what should happen here,
but the Gecko behaviour could be easier to implement, and the WebKit
behaviour slightly safer (presumably the point of this anomaly is to
prevent infinite loops in load event handers).
In Gecko's case, the only thing like that I know of is that onload
fires synchronously in Gecko in some cases, I believe. So we had to
put in some sort of recursion guard to prevent firing onload on a
parent in the middle of a child firing onload or something like that.
See https://bugzilla.mozilla.org/show_bug.cgi?id=330089. Per spec,
onload is always async, so this wouldn't be a concern.
Yeah, but as far as I can tell all browsers block (same document) load
events that happen from inside onload [1], so I *guess* at some point in
the past a site got into an infinite loop by trying to use document.open
from inside onload.
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17231
I wrote a similar test to the one you put in the bug:
http://damowmow.com/playground/demos/onload/001.html
It shows the onload handler actually getting called again in Gecko.
The interesting thing about the test in the bug is that it's actually the
iframe's onload that's not being called again, no page onload is being
tested in that test. So for that test, the solution I suggested in comment
10 in that bug is worthless.
Also interesting is that if you check what's actually going on, you'll
find that in Opera and Gecko (and per spec) the iframe's onload is run
asynchronously, whereas in WebKit it's synchronous.
That it's asynchronous means that what we need to do is:
* in the iframe code that fires 'load', annotate the iframe's document so
that it knows we're in a 'load' event handler,
* in the document.open() code, set a flag to true if the aforementioned
annotation is set, and false otherwise,
* in the iframe code that fires 'load', don't fire 'load' if the
aforementioned flag is set.
Sibling frames:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1937
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1938
Gecko and Opera go on to infinity there; WebKit blocks, but being
synchronous means that the algorithm above would
