Re: [whatwg] [canvas] Path object
On 10/3/12 11:04 PM, Boris Zbarsky wrote: I decided it wasn't worth punishing our users further if no one else in the world cared about this. Oh, and for the record we added gsp support in standards mode in Firefox 14. We kept the warning when it was used until Firefox 15, somewhat by accident; at that point we removed it, since warning on something every UA implements and the spec requires is a bit pointless. -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On 10/5/12 4:23 AM, Anne van Kesteren wrote: Note that you can append such an img to a different document later (e.g. the one that executes the script) so fetching it is probably smart. It can also lead to privacy leaks and very upset web developers and performance problems... So it's not quite clear cut. ;) -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On 10/5/12 4:09 PM, Anne van Kesteren wrote: Yeah sure, I'm not opposed to that. But that seems like a somewhat bigger change, no? E.g. then you would also change a.click() be a no-op I suppose? Or form.submit(). Are they not already? -Boris
Re: [whatwg] [canvas] Path object
On 10/5/12 4:59 PM, Glenn Maynard wrote: (I hope the other browser vendors' rationale isn't actually not caring about it.) Some of them simply care about backwards compat more than about getting rid of the global scope polluter. But some, as far as I can tell, really don't care at all. Like don't respond to any questions on the matter. But the upshot is the same. Oh, and for the record we added gsp support in standards mode in Firefox 14. We kept the warning when it was used until Firefox 15, somewhat by accident; at that point we removed it, since warning on something every UA implements and the spec requires is a bit pointless. It's not pointless: it discourages people from doing things that increase the chances of their page breaking in the future, and makes it easier for developers to ensure their own code isn't doing it by accident. Yes, but at the cost of performance and memory usage that just doesn't seem worthwhile here. And web developers get annoyed when UAs warn about various spec-compliant stuff they're doing, in my experience. So here we are. -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On 10/5/12 6:04 PM, Glenn Maynard wrote: On Fri, Oct 5, 2012 at 4:15 PM, Boris Zbarsky bzbar...@mit.edu mailto:bzbar...@mit.edu wrote: On 10/5/12 4:09 PM, Anne van Kesteren wrote: Yeah sure, I'm not opposed to that. But that seems like a somewhat bigger change, no? E.g. then you would also change a.click() be a no-op I suppose? Or form.submit(). Are they not already? a.click() is definitely not a no-op when not in a document The question is what it is when a.ownerDocument has no defaultView. The not in a document case is a different issue. -Boris
Re: [whatwg] Details on window.open
On 10/7/12 6:32 AM, David Bruant wrote: 1) what are the rules for popup blockers? Browser-dependent. Gecko uses a combination of several heuristics to block popups, based on what sort of platform event are being processed when the window.open call happens, how many popups are already open, which exact site the call is on, etc. Is every call to window.open blocked in modern browsers or are there exceptions? Well, onclick=window.open() usually works. It might be good to come up with a cross-browser list of cases like that that content actually depends on. 2) About the third argument, is there a somewhat interoperable overlap in implementations or is it just an intricable mess? The latter, especially across different kinds of devices and different browser UIs. If you limit to desktop browsers, there's some agreement on what the width and height of the resulting window should be... assuming it's actually a window that opens, not a tab. 3) Is what is returned a instance of Window or WindowProxy? Web page script never has direct access to a Window. Whenever you have an object reference, it's always a WindowProxy. -Boris
Re: [whatwg] Null characters
On 10/9/12 12:09 AM, Cameron Zemek wrote: How is it not web-compatible? Because shipping it breaks sites. As in, makes them render differently than they do in current browsers, sufficiently so that it's a problem. Yeah I don't have any numbers to see if this is the case or not. As Anne said, we tried shipping this and got user feedback indicating that sufficiently many sites are broken that it was not acceptable to us. But just thinking about it logically what issues would there be in showing Null character as the replacement character instead? Visually would see some extra characters if the document author had Null characters. What is the big deal with doing that? It makes text unreadable. Consider text that's actually UTF-16 but being declared as ISO-8859-1. If you strip the nulls, it all works out. But if you don't, every other character is a replacement character. This is not a rare situation on the web, unfortunately. Why do authors even have null characters in their HTML documents? Because they have UTF-16 text in their database that they dump into an ISO-8859-1 document. They have no idea there are any null characters involved. I assume I'm probably missing some historical reason for this Yes, that reason is the browsers all do it this way, so web sites depend on it. -Boris
Re: [whatwg] URL: URLQuery
On 10/12/12 6:02 PM, Glenn Maynard wrote: We're throwing away a ton if we suddenly decide not to take advantage of JavaScript's native syntax for dictionary-like object access. As you might have noticed, JS started adding things like Map in part because the native dictionary-like access has one significant problem: it looks up the prototype chain. Unless the suggestion is that Object.getPrototypeOf(query.values) === null? -Boris
Re: [whatwg] URL: URLQuery
On 10/13/12 11:53 AM, Glenn Maynard wrote:
You mean, people putting extra properties on things like Object.prototype
or DOMStringMap.prototype, and breaking code doing for(a in {})? I don't
find that to be a problem: that's nuts, so I don't do it.
Yes, but lots of libraries do. But even that's not the real problem.
Unless the suggestion is that Object.getPrototypeOf(query.values) === null?
That, or making the prototype immutable, as if Object.freeze was called on
it.
Making the proto immutable is not good enough.
Consider code that wants to extract a toString URL parameter. How do
you propose it go about doing that in a setup where query.values is a
normal object with a proto chain that chains up to Object.prototype?
Note that there are lots of other property names that have the same problem.
It's not clear to me to what extent implementing as a proxy can mitigate
this. I suppose you could write has() and get() traps that ignore the
proto chain, even if you for some reason want that proto chain to be
there
-Boris
Re: [whatwg] Document referrer and script entry point
On 10/22/12 1:38 PM, Adam Barth wrote: To answer these questions, you need to reverse engineer the behavior of various user agents, compare them Bobby did that already, in the first mail in this thread. See http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0014.html in case you missed it. I'm happy to change WebKit to such a consensus behavior, but I don't have the time right now to help you reverse engineer the behavior of WebKit-based user agents. The question is whether you're willing to change the the IE/Opera behavior described above, not what the WebKit behavior is. We know what the WebKit behavior is for this specific case. -Boris
Re: [whatwg] Spec for location object needs to make some properties unforgeable; need supporting WebIDL changes
On 10/23/12 5:45 PM, Ian Hickson wrote: heycam, bz, what's the conclusion on this? I don't think we ever reached one... Should I define a valueOf and make just that, the toString serializer, and href unforgeable? In the end, all properties and methods that let you read stuff out of Location need to be unforgeable as far as I can tell. Incidentally there's also a request to mark the 'location' attribute itself (on Document, presumably also the one on Window) unforgeable: It's already unforgeable on Window, fwiw. -Boris
Re: [whatwg] URL: file: URLs
On 10/27/12 3:35 PM, Anne van Kesteren wrote: This is covered as we do this for all URLs currently with a relative scheme (http/ws/...). I know you indicated this as potentially problematic Let's have that fight separately. ;) 2) file:// URIs are parsed as a no authority URL in Gecko. Quoting the IDL comment: ... The parser in the specification should handle these in the same way. Same as the comment I quoted? As same as something else? I have not introduced a no authority concept however. The parser in the specification also preserves the host as other user agents seem to preserve it. Well, the Gecko parser preserves the host at this stage assuming the URI was correctly formatted with a host. Again: blah://foo/bar = blah://foo/bar The interesting things happen when you have 0, 1, or 3 slashes between ':' and foo. The handling of foo after this point is a separate issue. 4) For no authority URLs, including file://, on Windows and OS/2 only, if what looks like authority section looks like a drive letter, it's treated as part of the path. For example, file://c:/ is treated as the filename c:\. Looks like a drive letter is defined as ASCII letter (any case), followed by a ':' or '|' and then followed by end of string or '/' or '\\'. I'm not sure why this is checking for '\\' again, honestly. ;) Is this part of URL parsing or part of doing something with the resulting URL? In Gecko, it's part of URL parsing. More precisely, it's part of the normalization performed as part of constructing a URL object from a string. Since this is also how we parse URLs, it's effectively all part of the package. But note that it would be a bit odd of file://c:/ claimed to have a host of c with a default port or some such... 5) When parsing a no authority URL (including file://), and when item 4 above does not apply, it looks like Gecko skips everything after file:// up until the next '/', '?', or '#' char before parsing path stuff. So the host is dropped? In Gecko, I believe so, yes. I'm not saying this is desirable; just what Gecko does. 6) On Windows and OS/2, when dynamically parsing a path for a no authority URL (not sure whether this is actually web-exposed, fwiw...) Gecko will do something involving looking for a path that's only an ASCII letter followed by ':' or '|' followed by end of string. ... 7) When doing URI equality comparisons ... 8) When actually resolving a file:// URL These points do not seem to be about parsing, correct? Well, point 6 is about parsing, sort of. 7 and 8 are not, though at some point we'll need to define equality comparisons anyway. -Boris
Re: [whatwg] URL: file: URLs
On 10/29/12 5:00 AM, Anne van Kesteren wrote: But note that it would be a bit odd of file://c:/ claimed to have a host of c with a default port or some such... Maybe I should introduce a file host state that supports colons in the host name (or special case the host state further, but the former seems cleaner). I don't think that's particularly desirable. The c: is totally part of the path; treating it otherwise would just be confusing. Imo. Most browsers seem to fail currently on input such as file://c:/ but this is on a Mac Yes, doing that on a Mac would just be wrong I would prefer having the parsing be consistent though. You mean across Windows and non-Windows? I'm not sure that's viable. -Boris
Re: [whatwg] URL: file: URLs
On 10/29/12 10:53 AM, Anne van Kesteren wrote: But at that point in a URL you cannot have a path. A path starts with a slash after the host. The point is that on Windows, Gecko parses file://c:/something as file:///c:/something As in, it's an exception to the general if there are two slashes after the file: then the next thing is a host rule. I suppose, I would hate it though for new URL(...) to depend on the platform. I'm not sure there are great solutions here. :( -Boris
Re: [whatwg] Proposal for window.DocumentType.prototype.toString
On 10/29/12 8:58 PM, Johan Sundström wrote: Serializing a complete HTML document DOM to a string is surprisingly hard in javascript. I thought there were plans to put innerHTML on Document. Did that go nowhere? As a fairly seasoned javascript hacker I figured this might do it: document.doctype + document.documentElement.outerHTML This seems lossy in many cases (most obviously: when the HTML uses conditional comments, though there are also various XHTML-specific issues). The most useful implementation would IMO be a native one that reproducing the doctype, as it was formatted in the source document. That might be worth doing independent of the serialization issue. -Boris
Re: [whatwg] URL: file: URLs
On 10/30/12 12:25 PM, Anne van Kesteren wrote: Thanks, I missed that. It seems however we could have that parsing rule for all platforms without issue, no? Hmm. Possibly, yes. I'd love feedback from other UAs here! -Boris
Re: [whatwg] URL: query encoding
On 10/30/12 11:43 AM, Simon Pieters wrote: The above applies to what gets sent over the wire when using the WebSocket(...) constructor. For a href, the results are different: http://simon.html5.org/test/url/url-encoding.html I don't have an opinion at this point about what to do here. In Gecko, at least , when a URL object is constructed from a string the caller can specify an encoding to use for the URL. The URL code then does things that depend on what that encoding was. Apart from the hierarchical vs not distinction, I believe the handling of the encoding does not depend on scheme in Gecko. If no encoding is specified, UTF-8 is assumed. a href passes in the document encoding as the encoding to use when constructing the URL object. The WebSocket constructor does not pass in an ecoding when constructing the URL object, so UTF-8 is used. I would not be opposed to us explicitly specifying things this way. That would incidentally require specs to say exactly when some non-UTF8 encoding is supposed to be used for their URIs and what that encoding should be, which seems like a good thing to me. -Boris
Re: [whatwg] URL: file: URLs
On 10/31/12 4:27 AM, Mikko Rantalainen wrote: (1) file://c:/foo tries to connect to server c: and request shared entity foo. I don't think that's really acceptable, but see below. I understand that (1) would behave different from some legacy user agents Well, it would behave differently from Gecko, for sure. Have you tested any other UAs? As in, do you have any evidence that some is not all in that sentence? Also, how are you defining legacy? Is it the same as existing? ;) but there really is not interoperability with such file URLs Is that a guess, or do you have data that you're forgetting to present? Serious question Some legacy user agents also support URLs such as (5) file:///c|/foo which is considered equal to (3). I have no idea why the pipe is considered better character than colon here. Such URIs were used commonly back when various things that processed URIs went into conniptions when they saw the ':' reserved character, iirc. In fact, at one point there were UAs that supported the version with '|' but not with ':'. And hence there was content that used that syntax. And again, what's needed here is data on which UAs do what, not generic statements about some. -Boris
Re: [whatwg] URL: file: URLs
On 10/31/12 9:52 AM, Anne van Kesteren wrote: I think bz made it pretty clear we need to treat as if you typed file:///c:/foo (at least on Windows, my preference is all platforms). Not sure what the rules are exactly, but I believe they are if you have a single ASCII letter followed by : or |. That's correct for Gecko. Specifically, what Gecko looks for is a URI that matches this regexp, effectively: ^file://[a-zA-Z][:|][/\\]? So file://z: and file://z|/ and file://z:\ would all be treated as having no authority and the path starting with the z in Gecko. Again, I would love info on other UAs. -Boris
Re: [whatwg] Sortable Tables
On 11/6/12 11:39 AM, Ojan Vafai wrote: This is a use-case that I absolutely think it makes sense to address. Agreed. Not that I can commit to implementing, necessarily, but I do think this is a common want. A couple thoughts off the top of my head: 1. Would sorting actually reorder the DOM nodes or just change their visual order? It's not clear to me which one is better. I think the former is what you'd want most of the time. The former also makes defining the interaction of dynamic mutations with sorting much much simpler Another obvious question: how does (or should) sorting interact with rowspans? -Boris
Re: [whatwg] Location object identity and navigation behavior
On 11/8/12 6:09 PM, Adam Barth wrote: I don't think I quite understand what you mean, but the way this works in WebKit is that each Window object has its own Location object. That's not how it works in Presto and Trident, as far as we can tell based on testing with ==. In those, each WindowProxy has its own Location object. The location object operates on the current Window for the WindowProxy. Yes. _That_ all browsers are consistent on, and is totally not what the spec says right now. In the spec, there is one Location per Window, and the object operates on the Window it's associated with. The fact that this does not match any browsers is what makes us suspect the spec is not web-compatible. In WebKit at least, it would be a security vulnerability to expose JavaScript objects that belong to Document B to Document A because that would give Document A access to the prototype objects for Document B. You presumably have a solution for this situation for the WindowProxy case, right? Certainly Gecko does, and we would be using the same solution for Location if we tie the lifetime of a Location to the lifetime of a WindowProxy. -Boris P.S. I'll leave it to Matt and Bobby to answer your question about your testcase with function f(), because while I suspect I know what UAs do there in practice there is no way to tell without actually testing...
Re: [whatwg] Location object identity and navigation behavior
On 11/9/12 2:05 PM, Adam Barth wrote: The approach we use in WebKit is quite simple---we just perform an access check before doing any sensitive operations. The issue in Gecko, as I understand, is that security checks from C++ code require introspecting running JS to figure out what the right actor (subject) origin for the security check is. This is somewhat fragile because it's easy to accidentally interpose other things that look like running JS between the caller and callee in many cases. Note that this problem would be even worse for a self-hosted (implemented in JS) implementation of something like Location... The upshot is that instead we aim to do security checks at points where control crosses from one origin to another, and use proxies to enforce the security invariants involved. Bobby knows more about this than I do, so I'll let him correct any inaccuracies. This access check is required in any case because the underlying Location object is visible across origins. In Gecko, it's actually not. A proxy is visible. One thing I'd like is some comment from Opera and Microsoft about what their situation is, since implementing what WebKit does would mean both of those changing. This is probably the wrong venue to get hold of Microsoft for an official statement, sadly. :( -Boris
Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality
On 11/12/12 1:55 AM, Boris Zbarsky wrote: Consider the attached testcase, which calls setTimeout on a window and passes in a function from a different window. Note that I observe the same behavior if I set onclick on another window too... It seems just as bizarre there. :( -Boris
Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality
On 11/12/12 2:00 AM, Boris Zbarsky wrote: On 11/12/12 1:55 AM, Boris Zbarsky wrote: Consider the attached testcase, which calls setTimeout on a window and passes in a function from a different window. Note that I observe the same behavior if I set onclick on another window too... And with addEventListener, likewise. -Boris
[whatwg] Spec for handling runtime script errors doesn't seem to match reality
Consider the attached testcase, which calls setTimeout on a window and passes in a function from a different window. When this function is then called, it throws. Gecko, WebKit, and Presto all seem to trigger the onerror handler of the window setTimeout was called on in this case. Per spec, section 7.1.3.5.1, we have: Whenever an uncaught runtime script error occurs in one of the scripts associated with a Document, the user agent must report the error at the URL of the resource containing the script (as established when the script was created), with the problematic position (line number and column number) in that resource, in the script's origin, using the onerror event handler of the script's global object. But the global object is the window the function came from. So the spec doesn't seem to match any of the above three rendering engines. Does it match Trident? I ask because I'm worried about web compat here. While I agree that what the spec says to do is the sensible thing (and in fact, I had accidentally switched Gecko to doing what the spec says here as part of working on something else entirely), if none of the UAs do it then there may be web content that relies on it not happening. There are certainly tests in Mozilla's regression test suite that inadvertently rely on Gecko's current behavior... -Boris
Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality
On 11/12/12 11:48 AM, Boris Zbarsky wrote: So I did a bit more experimenting, and at first glance when the function runs, even though the function's global is actually window A the this object seems to be set to window B... _That_'s not specced anywhere either, afaict. And in fact what the spec said was both ambiguous and not matching reality. I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=19947 about the this issue. Still looking into what IE does in terms of which onerror handler is called. -Boris
Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality
On 11/12/12 4:17 PM, Boris Zbarsky wrote: Still looking into what IE does in terms of which onerror handler is called. Looks like IE, in all the modes I can test, does what the spec says right now. I'll be changing Gecko to align with IE and the spec (and, arguably, sanity) here. -Boris
Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality
On 11/13/12 3:31 AM, Simon Pieters wrote:
onload=function(){
onerror=function(a,b,c){alert('parent: '+[a,b,c].join(' '));};
frames[0].onerror=function(){alert('child: '+[a,b,c].join(' '));};
frames[0].setTimeout(function(){ throw 'oops' }, 0);
};
...
Opera and Chrome use child and taint (alert says child: Script error.
0).
OK.
Firefox uses child taints the url and line arguments but not the message
argument (alert says child: uncaught exception: oops 0).
Actually, Firefox is not tainting anything here. A manually thrown
string exception like that in Spidermonkey just seems to not have a url
and line number attached to it.
I believe right now Gecko uses the effective script origin for
determining whether to taint, so in your case the two pages are actually
same-origin for tainting purposes in Gecko.
IE8 uses parent and doesn't taint (alert says parent: Exception thrown
and not caught http://example.org/001.html 7).
Indeed. I'm working on switching Gecko to using the parent in this case
(and still not tainting, of course).
I also tested the same as the above but with a string argument to
setTimeout with a syntax error.
This one is simpler in terms of which error handler to use, because the
string is compiled in the child to start with. Though I agree it's very
interesting for tainting purposes!
What does Opera base its tainting decision on here, exactly? The actual
origin of the script that made the setTimeout call (as opposed to the
origin it has due to being loaded by some web page)? Or just its page's
origin? Or does it track origins on individual strings?
-Boris
Re: [whatwg] URL: IPv6 parsing and model/serializing
On 11/14/12 10:35 AM, Anne van Kesteren wrote: Chrome's implementation (except for parsing invalid IPv4) makes a lot of sense I think as it allows for minimizing what needs to be stored internally. It only requires a sequence of eight 16-bit components. I believe Gecko simply stores the original string (lowercased), modulo IDN stuff. Since this works for both DNS names and IP addresses, a requirement that some other representation be stored is actually a bit of an implementation annoyance... -Boris
Re: [whatwg] URL: IPv6 parsing and model/serializing
On 11/15/12 5:45 AM, Anne van Kesteren wrote: Well and it is validated. You definitely parse the string Yes, absolutely. but I can see how that is cheaper than transforming the string. And that string is then passed to the DNS layer? I don't know offhand. I'd have to go dig... We could define that instead I suppose although it seems kind of weird to normalise domain names, but not IP addresses. We could offer an API instead I suppose that does implement http://tools.ietf.org/html/rfc5952#section-4 Just to be clear, I don't necessarily object to normalizing IPv6 addresses. Especially since I'm no longer actively working on networking code, so it's not like it would be work for _me_. I just mentioned the only concern I had about your proposal, which in general sounds excellent. -Boris
[whatwg] Document.setCapture/releaseCapture
Are setCapture/releaseCapture specified on document anywhere? The last thing I see about it is http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017415.html and then nothing... Note that I suspect we do need a releaseCapture() so pages can call it without throwing, even if we decide it should do nothing when called. -Boris
Re: [whatwg] [URL] DOM API Feedback
On 11/19/12 2:36 AM, David Bruant wrote:
An ES6 proxy could do the trick here.
But then it's not a Map at all, right? It's a proxy for maybe a Map,
maybe something else. In what sense would it be a Map at that point?
I suppose the same goes for ES6 Map.
As Tab suggested, a Map subclass could certainly work
How close are subclasses to not being vaporware (both in spec and
implementation terms)? Speccing things in terms of vaporware makes them
pretty hard to implement in actual implementations... Doesn't mean we
shouldn't do it, but I'm a bit wary of it, in general.
The ordered part for objects wasn't true in ES5 (implementation specific
order), but is considered for ES6 [1] since all web engines do the same
order
Except they don't. Here's a trivial example:
var obj = {};
obj[2] = 5;
obj[1] = 0;
which is handled differently by different UAs. The same order bit is
only true for property names that don't look like array indices. Per
proposed spec you linked to, by the way, this will enumerate properties
in the order 1 followed by 2.
Of course nothing really stops pages from using url parameters whose
names look like array indices. So if we want ordered here, we just
can't use a object to do it.
-Boris
Re: [whatwg] [URL] DOM API Feedback
On 11/19/12 11:00 AM, David Bruant wrote: How close are subclasses to not being vaporware (both in spec and implementation terms)? I don't understand what you mean by vaporware. ES6 Maps are a reality in Firefox and Chrome (behind a flag for the latter). Yes, I know that. Subclassing of ES6 maps will be possible as soon as ES6 classes do (which I admit are still unimplemented) Yes, that's what I mean by vaporware. ;) ... well... it's actually possible today with __proto__ I guess. Is it? It's not terrible possible for arrays, right? Have we checked that it is for maps? It's still possible for the spec to define an API that maps (no pun) the ES6 Map API (and does some additional magic). For those who'd care enough, it'll be possible to make this object a map. So... the question is whether the spec will require that this object is a Map, whatever that means. If not an ES6 map, the same API will be good enough to avoid API diversity. I have no problem with same API. The issue is how to define this in a way that UAs actually end up interoperable in the end. If some use Map and some don't, that's not exactly great. Interesting, I thought the proposal was meant to capture de facto standard. Did UAs converge for that behavior recently? More specifically, what does IE9 do? (I guess oldIE are the ones diverging from the others?) All UAs agree on ordering of non-index properties. For index properties, they don't agree in all sorts of ways. The behaviors I know about: 1) V8 enumerates indexed properties in index order always, for all objects, as far as I know. 2) Spidermonkey enumerates indexed properties on fast arrays (the ones that have no non-index props and don't have too many holes, and some other conditions) in index order. In all other cases it enumerates them in set order, where set order when an array transitions from fast to slow is index order. I believe we plan to change this behavior to match that of V8 sometime, but the timeframe is many months at best. 3) JSC enumerates indexed properties in set order on my testcase earlier in this thread. I didn't experiment more, because frankly you can do that just as well as I can. ;) 4) Carakan enumerates indexed properties in index order on my small testcase. Again, further experimentation is open to anyone who cares. Basically, the spec here codified the de-facto standard in the case where there was interop (non-index properties) and just picked a random behavior from the wide range of available behaviors for the case where there was so little interop that it was clear the web didn't depend on any particular behavior too much (index properties). In particular, the V8 behavior was picked, as far as I can tell. -Boris
Re: [whatwg] [URL] DOM API Feedback
On 11/19/12 11:16 AM, Tab Atkins Jr. wrote: Subclasses aren't anything new - we're just referring to the standard prototype-based subclassing. OK. That's different from ES6 classes/subclasses, so it might be good to get terminology straight here to reduce confusion -Boris
Re: [whatwg] [URL] DOM API Feedback
On 11/19/12 11:20 AM, Tab Atkins Jr. wrote: To a first approximation, they shouldn't be. ES6 classes desugar into functions and prototypes. Hmm. They didn't completely at some point, but maybe something got changed since I last looked. first approximation is not great if we actually expect people to implement stuff interoperably, not just interoperably to a first approximation. ;) -Boris
Re: [whatwg] [URL] DOM API Feedback
On 11/19/12 1:26 PM, Allen Wirfs-Brock wrote: Classes and everything else in ES6 will be precisely specified within interoperability being a paramount goal Of course. My concern is with web specs handwavily specifying things without defining them (which they have a regrettable tendency to do), not with ES doing that (because historically, it does not have such a tendency). -Boris
Re: [whatwg] URL: percent-encoded host
On 11/19/12 4:12 PM, Anne van Kesteren wrote: 3. Ignore percent-encoded bytes. ... Firefox seems to do 3. This actually causes problems; see https://bugzilla.mozilla.org/show_bug.cgi?id=309671 So I don't think we should require this behavior. -Boris
Re: [whatwg] Location object identity and navigation behavior
On 11/19/12 8:38 PM, Ian Hickson wrote: For now I've tightened up the spec so it should be implementable, secure, and Web-compatible I don't believe it's secure as currently written, actually. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20012 I'm also curious as to why figuring out the entry script's characteristics needs to use the stack introspection rather than just having an event-loop global first script variable You can maintain a stack of entry scripts. You can't use a global, because you need to push and pop entry scripts as various things happen (e.g. invoking event listeners sets the entry script to the event listener function's script for the duration of the event listener invocation). There is no such stack of entry scripts in Gecko yet, but we're working on changing that. The thing that _really_ requires stack introspection is when you need to look at the caller script instead of the entry script. Which is what you need to do when performing Location security checks (or indeed, any security checks). -Boris
Re: [whatwg] Location object identity and navigation behavior
On 11/20/12 1:23 AM, Ian Hickson wrote: Could you elaborate in the bug? I've no idea what you think is wrong. Done, but what's wrong is that the security checks described in the spec check the origin of the wrong document. You can maintain a stack of entry scripts. You can't use a global, because you need to push and pop entry scripts as various things happen (e.g. invoking event listeners sets the entry script to the event listener function's script for the duration of the event listener invocation). The way the spec does it, the stack is implemented as the actual call stack, with nested calls to jump to a code entry-point storing the old value, updating the global, running the script, then restoring the global to the stored old value. Sure, that works. One way or another, you need to have a stack. ;) And if part of your WebAPI/DOM/etc implementation itself is done in JS you have to be careful to not update the entry-point stuff when calling into that JS, of course. The thing that _really_ requires stack introspection is when you need to look at the caller script instead of the entry script. Which is what you need to do when performing Location security checks (or indeed, any security checks). Can you show an example of when that is needed? Uh... any time you do a security check, in general. As far as I can tell, the entry script always has the same origin as the running script. All you need for script A to be able to call script B as the spec us currently written is that sometime in the past the effective script origin of A matched the effective script origin of some script C and that at some point in the past (possibly a completely different point) the effective script origin of B matched the effective script origin of C (which may not have been the same at that point as when C matched A!). There is no requirement that A ever matched B, or even that the sets of effective script origins A and B have had in the past have nonempty intersection. And even that may not be true depending on whether UAs allow privileged JS in various settings. If they do, then the entry script becomes very useless for origin determination unless crossing origin barriers resets the entry script. Which, again, is not the case in Gecko right now. But that's obviously Gecko's problem, for the moment. I guess this isn't necessarily true of the effective origin, which is what we're using for the Location object security? Is that the problem here? I think the problem is that you're assuming invariants that just don't hold. There is no current requirement in the spec that there be any relationship between either the origin or effective script origin of the entry script and the origins of the currently running script. If so, why don't we just make it be an origin check of the entry script instead of an effective origin check? Because that would be totally wrong; see above. If that would make it simpler for Gecko As things stand, it wouldn't, particularly. It would actually introduce security bugs. if you have both calling each other then you can almost certainly trick the script into doing what you want either way. Who said anything about both calling each other? Gecko's security model is asymmetric in practice. -Boris
Re: [whatwg] Location object identity and navigation behavior
On 11/20/12 2:38 AM, Ian Hickson wrote: IMHO there's no point us trying to keep things locked down when you set document.domain. I believe sites actually rely on a certain amount of lockdown in situations like this... Adam can fill you in, I'm sure. But in general, as people work more and more on Widgety and Appy stuff in HTML, with various expanded privileges, granted permissions, etc, the assumption that the security model is completely symmetric just becomes false. I'd rather we didn't paint ourselves into a corner by assuming otherwise here and requiring behavior that UAs would simply refuse to implement because they view it as insecure. if you have both calling each other then you can almost certainly trick the script into doing what you want either way. Who said anything about both calling each other? If they're not calling each other, how are they both on the stack? This only requires one of them calling the other. It doesn't require the other being able to call back into one. Maybe that's not what you meant, though. So let me give you a concrete not-exactly-hypothetical example. Say I'm implementing a debugger in a web browser, and I implement my UI in HTML+JS as browsers are tending to do now. When I examine properties with scripted getters in this debugger, what should happen? I will bet money that the debugger is not, generally, running with the permissions of the page, because it needs to be able to do things that web pages aren't allowed to do. However the getters in question had better run with the permissions of the page; otherwise you open up the debugger to attacks from the web page. This problem is not solvable using the separate worlds approaches browsers use to provide extensions with an unmodified view of the DOM, since the debugger really does want to see what's going on in the web page itself; it just doesn't want to allow the page to escalate permissions. Now I know there are several possible objections to this use case, so let me just pre-address some: 1) It's not the web, so we don't have to specify it. That's true, sure. I suspect as time goes on we might in fact need to specify something like this for apps, however. And more importantly, just because it's not the web doesn't mean UAs are not implementing it, and if they're implementing it they need to make it work with their security model, whatever it is. 2) The debugger can have some magic to make it all work. Yes, but then the question is how it interacts with the web security model and how the result can be implemented. 3) The debugger should set the entry script before invoking the getter. This is a plausible approach, but it makes it very error-prone and complicated to create things like the above-described debugger: you have to manually keep track of which objects come from where instead of just having the web platform implementation (which already has that information) keep track of it for you. 4) Entry script should always be set when crossing origins (for some definition of crossing origins). This seems plausible as well. Maybe it's doable. One other note: Gecko's current model is at least somewhat influenced by the fact that in the past Gecko had expanded privileges on a per-function basis. This obviously made using the entry script a non-starter... Maybe it's more of a starter now. I'll let Bobby worry about it. ;) -Boris
Re: [whatwg] Location object identity and navigation behavior
On 11/20/12 12:46 PM, Ian Hickson wrote: Given the way JavaScript works, I just don't see a sane way to make a non-symmetric model work. How does JavaScript work in your mind? We have a good amount of experience making a non-symmetric model work in Gecko, for what it's worth. Any time you pass a string from one to the other, you're also passing a way for the callee to call back into the caller, for example (via the string's methods). Spidermonkey effectively copies strings when passing across globals; the callee never gets the caller's actual string. The methods the callee sees on strings are its own methods, not the callers. Passing any sort of structured objects similarly means passing mehods. In the case of Gecko, what the caller gets in this case is a proxy for the actual object which enforces security invariants like only properties on a whitelist are exposed for cases when the security check is asymmetric. This is handled completely on the underlying JS implementation level; individual callers don't have to do anything special to be safe this way. We have mechanisms for safe passing of data from one context to another, such as postMessage(). Doing it by having one-way glass in JS just seems like asking for trouble. postMessage doesn't work unless both sides are cooperating... Yeah, like running getters with the ability to abort them if they don't return promptly. Perhaps, yes. ;) I agree that debuggers have all sorts of weird going on, obviously! But your underlying point, that we can't rely on the entry script and the real origin, is sound. In particular, anything that's to be affected by document.domain has to use the calling script, not the entry script, and has to use the effective origin, not the real origin. It would be useful if someone (other than me) were to review the spec's uses of the term entry script and origin and verify that the checks all make sense. I'll see what I can do about finding someone for this. Might be a few weeks given holidays and whatnot, obviously. I'll let Bobby handle the Location parts of this. ;) -Boris
Re: [whatwg] Provide data chunk with the ProgressEvent
On 11/21/12 11:07 AM, Nicolas Froidure wrote: Indeed, the only way to access to the data chunk loaded is to keep a reference to the previous value of xhr.responseText. Nicolas, see http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html (implemented in Gecko as the moz-chunked-text and moz-chunked-arraybuffer response types so people can experiment with it). Would that address your use case? -Boris
Re: [whatwg] URL testing
On 11/24/12 5:49 PM, Chris Weber wrote: There also appears to be some differences in Unicode normalization (assuming I tested this enough), see: http://web.lookout.net/2012/03/unicode-normalization-in-urls.html A question. What OS or OSes did you test on? Unicode normalization differs in some browsers depending on the OS (e.g. different behavior on Windows and Mac)... -Boris
Re: [whatwg] Adding crossorigin= to more elements
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... 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. 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... 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. Otherwise loading something via CORS would allow it to act on behalf of the loading page, whereas usually pages assume that using CORS just gives them expanded access to something. Or put another way, if I have a file:// page that loads a sheet from http:// with CORS, that shouldn't imply that the sheet can then link to file:// URIs the page can link to. This is very important; oversimplifying the security model to the point where it becomes insecure is bad. ;) Maybe this is OK, but it's non-obvious; usually for security purposes the importing sheet is what affects things like can-load checks, Referer headers, etc. Presumably a CORS-same-origin sheet would use the security characteristics of the page, since the page can make the style sheet dance as if it was its puppet. No, see above. The page can make the sheet do whatever, agreed. But this is about the _sheet_ taking on the permissions of the _page_ in some sense, which may not be desirable. Anyway, that part of it belongs in CSS/CSSOM. That's fine by me. Assuming we ever end up with a CSSOM spec not holding my breath. ;) -Boris
Re: [whatwg] Adding crossorigin= to more elements
On 11/28/12 11:03 PM, Boris Zbarsky wrote: 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. Oh, I see. You've added this taint thing, which you're using for the CSS bit. I don't believe Gecko has any such concept. We simply fail the load if the CORS check fails. Furthermore, Gecko's behavior is what the CORS spec requires: failure to respond properly to a cross-origin CORS request must be treated like a network error per CORS. -Boris
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
On 11/29/12 1:30 AM, Gordon P. Hemsley 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. Only for media (video and audio) loads. Note that the HTML spec requires this behavior for those. Are there security implications with doing this? In general, yes. Doing this for document loads would be a security nightmare, for example. -Boris
Re: [whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing
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. 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. -Boris
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 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] [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 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] 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 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] Make DOMStringMap constructable, and el.dataset writeable?
On 11/30/12 2:23 PM, Tab Atkins Jr. wrote:
It would be somewhat cleaner if she could simply construct a
DOMStringMap and assign it, like so:
for(var i = 0; i cards.length; i++) {
cards[i].dataset = new DOMStringMap(carddata[i]);
So this would copy the DOMStringMap into the dataset, not actually
change the value of cards[i].dataset, right?
Given that, would it make more sense to just have a setFrom method on
dataset that takes a string? I guess the problem with that is name
collisions with data items...
Really, what we want to be able to do here is assign a string to
.dataset and have it do the right thing... WebIDL doesn't really
support that very well; perhaps it should.
Another potentially interesting use-case for this is making it
possible to transfer data-* attributes from one element to another
with a simple el1.dataset = el2.dataset; statement.
Again, this would copy, not share, yes?
-Boris
Re: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
On 11/30/12 7:07 PM, Tab Atkins Jr. wrote: Sure. I presume you're afraid of multiple elements sharing the same object? We can call it afraid or we can call it nonsensical since the object is just syntactic sugar on top of the (not shared) attributes the objects have ;) Really, what we want to be able to do here is assign a string to .dataset and have it do the right thing... WebIDL doesn't really support that very well; perhaps it should. What would the string be? String-serialized JSON object? Whatever you're proposing be passed to the DOMStringMap constructor, no? Isn't this what [PutForwards] is for? Unfortunately, no. [PutForwards] will take the RHS and pass it to the setter of some attribute of the LHS. But that requires there to be such an attribute, which is a no-go due to the name collision thing... Basically what we want here is an IDL attribute for which the getter returns one type but the setter takes a different type. Or something. We can do it the way you proposed, but it seems like a workaround for the lack of ability to declare such a thing in WebIDL. Yes. I presume same fear? Yes. -Boris
[whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
Consider this testcase:
var desc = Object.getOwnPropertyDescriptor(HTMLElement.prototype,
onscroll);
desc.set.call(document.body, function() { alert(this); });
Is the listener added on the body, or the window?
The relevant parts of the spec are:
1) onscroll is present on both HTMLElement.prototype and
HTMLBodyElement.prototype. This testcase explicitly invokes the setter
for the former.
2) The spec text at
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#handler-onscroll
(scroll up; there is no way to link to the actual text) says:
The following are the event handlers (and their corresponding event
handler event types) that must be supported by all HTML elements
other than body and frameset, as both content attributes and IDL
attributes, and on Document objects, as IDL attributes
It's not clear to me what this means since the properties are on
HTMLElement.prototype so they can be applied to all HTML elements. What
does this text mean in terms of the testcase above?
Basically, I can see three possible behaviors here. Either the
HTMLElement.prototype.onscroll setter behaves the same way on all
elements (and hence the above adds the event handler on the body) or it
behaves specially for the body element, forwarding to the window (and
then we don't need HTMLBodyElement.prototype.onscroll), or it throws for
the body element. Which one is intended?
-Boris
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On 12/3/12 2:05 PM, Ian Hickson wrote:
What do browsers do?
WebKit and Opera don't put the property on the prototype at all, so the
whole issue is not even testable there. This obviously doesn't follow
WebIDL, but that's not relevant here.
It looks like Gecko currently doesn't allow the onscroll setter gotten
from HTMLElement.prototype to be invoked on things whose prototype is
not exactly HTMLElement.prototype. In particular, applying it to an
HTMLBodyElement throws. This is an artifact of this property being
implemented via XPConnect, unlike a lot of other DOM properties; we're
in the process of switching to WebIDL for the bindings here, which is
why the question arose.
IE9 in IE9 standards mode seems to depend on the exact event handler.
Specifically, assuming I didn't mess up my tests:
1) For onload, onfocus, onblur it seems to forward the set
to the window even if it's invoked via the HTMLElement.prototype
setter.
2) For onscroll, onerror it seems to never forward to the
window, no matter how you set it.
So in terms of compat, I claim there are no constraints here. ;)
This should probably be defined in WebIDL.
You have IDL like this:
interface Foo {
attribute EventHandler onscroll;
};
interface Bar : Foo {
attribute EventHandler onscroll;
};
WebIDL already defines how this behaves: there are getters/setters on
both Foo.prototype and Bar.prototype, and it's up to the spec prose to
decribe how those getters/setters actually behave. That's really what's
missing here, no? Again, there are several possible behaviors; the
question is which one we want for this particular case.
It relatess also to:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17201
It's a similar situation, yes. But in this case I don't see why you'd
need an IDL annotation of any sort at all. If you want the behavior to
be the same, just don't define onscroll on Bar at all and define the one
on Foo to special case the two Foo subclasses you care about here. If
you don't want it to be the same, the IDL annotation doesn't help you.
-Boris
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On 12/3/12 7:33 PM, Ian Hickson wrote: Note that onerror has a different type on HTMLElement and HTMLBodyElement. Yes, indeed. That's the biggest problem with forwarding to Window for the HTMLElement.prototype case for onerror here: the types are different. onscroll is a case where there's really no reason to use a different setter, agreed. So I've commented that out (and it's similar friends). That still leaves onerror though. Indeed. I would have no problem with just having HTMLElement.prototype.onerror's setter set an error handler on the body itself, like it would on any other HTML element, and likewise for the getter. Per our IRC discussion just now, I think I would propose that when a method/setter/getter from a prototype of interface A is called against an object that is of an interface B (or one of B's descendants), where B is a subclass of A, and B defines its own method/getter/setter with the same name, then it should throw. Hmm. That, as phrased, is pretty complicated to implement in a performant way, if the two methods/getters/setters have the same signatures... -Boris
Re: [whatwg] Specification unclear about how HTMLElement.prototype.onscroll's getter/setter should behave for body elements
On 12/3/12 8:16 PM, Cameron McCormack wrote: On 4/12/12 12:11 PM, Boris Zbarsky wrote: Hmm. That, as phrased, is pretty complicated to implement in a performant way, if the two methods/getters/setters have the same signatures... Since I'm not terribly familiar with our generated bindings code, I'm not really sure what that would be. Is there a phrasing that would not be so complicated but does the same thing? :) The problem is the functionality, not the phrasing. I have to ask: are there languages or runtime systems that have that sort of behavior on method calls (as opposed to in method implementations in special cases where the operation is nonsensical)? It seems weird to be requiring this behavior, in general. -Boris
Re: [whatwg] Make the files attribute of the input element writable
On 12/15/12 8:39 PM, Jonas Sicking wrote: myFileInput.files = [ablob, afile, anotherblob, new Blob([foo])]; There's no way to express that in WebIDL, but I think that's a bug we should fix in WebIDL. We should allow getters and setters for attributes to accept different IDL types... -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 12/15/12 8:33 PM, Jonas Sicking wrote: An easy solution would be to just return null for .contentDocument in the case of cross-origin iframes. Even if that were web-compatible (which is not obvious), that doesn't solve the problem of doing the same sort of thing with .contentWindow. -Boris
Re: [whatwg] Details on window.open
On 12/18/12 3:53 PM, Ian Hickson wrote: Per the spec, calls that would create a new browsing context are blocked unless called from the handler of a trusted 'click' event. That's not web-compatible... I don't know if the spec is overly strict here; maybe it should also be possible on other trusted events e.g. mousedown or keydown? Gecko's current behavior is as follows: There are four possible states we can be in for popups: Allowed (allows popups), Controlled (allows popups, but only up to a global maximum number of popups opened from states other than Allowed), Abused (does not allow popups normally) and Overridden (does not allow popups normally). If a site is white-listed in preferences to allow popups, then for that site Controlled is treated as Allowed and Abused is treated as Controlled. The default state is Abused, I believe. During handling of user input (which is NOT the same thing as an event being trusted, iirc; in particular there is some timer involved after an actual user input event was handled during which we treat things as being user input, because of sites doing window.open() from timeouts set from onclick), the popup state is set as follows: click: Allowed if click is in the popup-allowed whitelist select, change, input, keypress, keyup, keydown, mouseup, mousedown, dblclick, error, submit, reset: Controlled if the event name is in the popup-allowed whitelist The default value of the whitelist is change click dblclick mouseup reset submit, but can be modified by the user. Furthermore, certain things propagate the popup state that was active at a previous point in time. Specifically: 1) Loading a javascript: URI will record the state that was active when the load started, and temporarily set that state during the async execution of the script. So if your click handler sets a javascript: URI that does window.open(), that will work. 2) Calling click() on an input type=file will record the active popup state and test it when the task that would actually open the file dialog runs. This is more or less an implementation detail, looks like; it's equivalent to just checking the state in click(), as long as you ignore the exact firing time of popup-blocked events. 3) Submitting a form will record the popup state at the time the submission started. When the asynchronous part of the submission happens (which is when a window would get opened if the form has an @target), this popup state is used to decide whether to allow the window to open. I think this might be it, except for some code around plug-ins that I can't make sense of right now. I strongly suggest talking to all UA vendors about how their popup blockers actually worked. The Gecko setup used to be simpler, but we've had to add complications to it as we came across site compat issues... I haven't tried to spec it, because as far as I can tell, UAs could completely ignore it with no ill effects. If I'm wrong about this, then we should spec something. I think on desktop you're somewhat wrong (e.g. it's possible to get site compat bugs where you open a window at the wrong size and users can't get to content)... Most things other than the size bit can probably be ignored in that feature string, though. -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On 12/18/12 3:25 PM, Ian Hickson wrote: Looking at the spec and at browsers more carefully, it seems that this is actually per spec (i.e. the spec says to follow the link). Does it say to do that if the ownerDocument of the a has no associated browsing context? What if it's not the currently active document? IE and Firefox apparently don't, WebKit and Opera apparently do. I've left the spec as is since it seems harmless and half the browsers do it. We can probably allow navigation for cases in which the ownerDocument is the currently active document of a browsing context, in Gecko. I don't think we'll be allowing it in the other cases... -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On 12/19/12 12:11 PM, Ian Hickson wrote: So I've put in a block on the handling of a (and area) elements specifically, making their activation behaviour nil if their doc doesn't have a browsing context Does a document that is in something like bfcache or has otherwise been unloaded have a browsing context? -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On 12/19/12 12:37 PM, Ian Hickson wrote: Yes, just not an active one. OK. I don't think we want to activate links in unloaded documents, personally -Boris
Re: [whatwg] Resource loading in browsing context-less Documents
On 12/19/12 12:55 PM, Ian Hickson wrote: On Wed, 19 Dec 2012, Boris Zbarsky wrote: On 12/19/12 12:37 PM, Ian Hickson wrote: Yes, just not an active one. OK. I don't think we want to activate links in unloaded documents, personally That's probably reasonable... Do you have a test case? :-) Not offhand. I could write one if I had to, I guess... do I have to? ;) -Boris
Re: [whatwg] video feedback
On 12/20/12 9:54 AM, Ian Hickson wrote: Everything in the Web platform already uses doubles. Except WebGL. And Audio API wave tables, sample rates, AudioParams, PCM data (though thankfully times in Audio API do use doubles). And graphics libraries used to implement canvas, in many cases... I think the only safe claim about everything in the web platform is that it's all different. ;) -Boris
Re: [whatwg] Canvas: dash list API
On 12/22/12 6:07 AM, Cameron McCormack wrote: If we don't have the type checking of array elements, and also don't need any noticing of individual element assignments, then we can just have a reference to a plain Array object and look at its elements at the time the dash array is needed. Look at elements at the time it's needed is bad for interop, because looking at the elements of a plain array means, in general, calling arbitrary script. Which means that to really get interop you need to specify exactly which elements are looked at when If we don't care about that level of interop, this is an option, of course. -Boris
Re: [whatwg] Sortable Tables
On 12/27/12 7:40 PM, Tab Atkins Jr. wrote: In JS, the comparator passed to sort() can potentially mutate the array that's being sorted, or delete it entirely. JS engines cope somehow. Note that per spec the behavior if the comparator mutates the array is undefined. Engines are allowed to go into infinite loops, crash, throw exceptions, whatever. And sometimes do all of the above. since any problems you can possibly come up with are already present in the existing Array#sort function. This part is true. -Boris
Re: [whatwg] Baseline of objects
On 12/28/12 1:42 PM, Jonas Grus Dinesen wrote: I am looking for a feature to set the baseline of an object, fx an svg figure (rectangle, triangle etc) which makes it possible to let fx height and width of an object grow upwards and not downwards. Maybe by setting horisontal and vertical baselines. For vertical, see http://www.w3.org/TR/CSS21/visudet.html#propdef-vertical-align (specifically the percentage and length values). -Boris
Re: [whatwg] Styling details
On 1/2/13 4:37 PM, Ian Hickson wrote: Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. As far as I can tell, Web Components is doing the following: 1) Defining a way for authors to implement custom widgets. 2) Defining a way to maybe describe built-in custom widgets using the same language. It is not yet, but maybe sometime (this is pretty vaporware-ish so far) doing: 3) Defining a way that author styles can be applied to browser-defined custom widgets. and it is certainly not doing: 4) Defining the browser-defined custom widgets using the capabilities of #2 such that authors can in fact style them. -Boris
Re: [whatwg] Styling details
On 1/3/13 12:10 AM, Ian Hickson wrote: On Wed, 2 Jan 2013, Boris Zbarsky wrote: On 1/2/13 4:37 PM, Ian Hickson wrote: Wait, Web Components isn't solving this? I thought this was one of the main use cases of Web Components. [...] and it is certainly not doing: 4) Defining the browser-defined custom widgets using the capabilities of #2 such that authors can in fact style them. Why not? This seems like a pretty core feature. Without being able to do this, how can anyone reliably extend an existing widget, for example? First of all, I'm not actively working on Web Components, so I can't tell you why it is or is not doing something. Second, I suspect that the browser-defined widgets can end up with somewhat different per-platform implementations. And different per-browser behavior and so forth. So speccing them might end up being pretty nontrivial, and right now Web Components have bigger fish to fry (like allowing authors to define widgets). Long-term this is probably in the goals, but we're talking years. -Boris
Re: [whatwg] Spec for handling runtime script errors doesn't seem to match reality
On 1/7/13 2:34 PM, Ian Hickson wrote: Ok. I've left the spec as is here. Please do let me know if this is the wrong thing to do after all Will do once I actually manage to get this stuff into a build people are using. For now, it runs afoul of script disabling for designMode and other such fun. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/7/13 6:20 PM, Cameron McCormack wrote: Why would this need to be on specific operations and not just be enforced on every operation? I believe Gecko currently enforces this sort of thing on every operation, for what it's worth. Or it it that only a limited set of objects is exposed cross origin anyway The set of objects exposed is not particularly limited once document.domain gets involved. Note that there is longstanding disagreemed on which cases of direct property access should perform same-origin checks. Again, Gecko I believe does it for all but a whitelist of properties like Window.top and such. For the actual wording of the check, we could either have a security check that is performed at the right time in #es-operations etc. and which HTML defines to do the origin checking, or we can make Web IDL aware of origins itself, and then HTML would define what origin different objects come from. For what it's worth, in Gecko the is same origin determination is one and the same as implements an interface determination: a cross-origin object simply claims to not implement any interfaces from the caller's point of view. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/7/13 6:41 PM, Ian Hickson wrote: Most things don't have an origin. Pretty much everything has an origin in practice: it's associated with some Window, hence can be treated as having the same origin as that Window. Origin checks are only done in some very specific places where you try to get an object's properties; what we're saying here is that for those properties, you also need to do the check when you run the code behind those properties (e.g. call a method), against the this. I'm not quite sure we're talking about the same thing here. Can you give an example of what you're thinking? What _I'm_ thinking is that there needs to be a security check when someone does Document.prototype.getElementsByTagName.call(subframe.contentDocument). This is not the same security check as the one performed by subframe.contentDocument.getElementsByTagName (note lack of call; it never gets that far in the cross-origin case). This is independent of whether we're doing security checks on all property access or on some of them. Is it that we want to avoid the overhead of origin checking if we know that calling the operation does not leak information? Or it it that only a limited set of objects is exposed cross origin anyway, so we only need to check those? Both. Implementing different security models on the IDL level is a footgun of enormous size. We should simply have IDL methods throw if called with not-same-origin this or arguments, except for a whitelist. In my opinion. Anything else is fragile and leads to security whack-a-mole. Not that we can have the argument about which interfaces are subject to this security check if you want to only limit it to some objects; or example you could argue that this is only needed on Window, EventTarget, Document, Node, and a few others. That's a separate argument from whether the security checks for those interfaces should be opt-in or opt-out. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/7/13 11:28 PM, Ian Hickson wrote: Per spec, even Windows actually don't have an origin. Things that have origins are URLs, Documents, images, audio and video elements, fonts, and scripts. Many of those things can have origins that are not that of the most obvious related (or in some cases any) Document. Yes, I know what the spec says. What I'm saying is that the spec is not doing anyone any favors by using origin to mean different things for different objects. In particular, for images/audio/video the origin in the spec is the origin that's relevant for the _data_, not necessarily for the element itself. Suppose you try to get the property from a Document whose origin doesn't match your script's origin. Right now, this throws a SecurityError Right. We all agree on this part; there is no problem here. The check we need to add is for when you actually invoke the properties, in case you got the property from another Document and then apply it to this one. Yes. The check is the same -- if the Document that is the this to which the property is being applied doesn't match the origin of the script that is doing the applying, throw SecurityError. That's an option, yes. As I said, Gecko throws TypeError like it would for a non-document. That happens to require less code, and I'm not sure people really care about the exact exception here (though I know bholley disagrees with me on this). Right. Specifically, the new security check (for compat we still need the old one too, though I guess in many cases it's now redundant) It's not redundant, because nothing says that subframeDoc.getElementsByTagName is actually the WebIDL-defined method; it could be something the script in the subframe set up. So you have to block access to it no matter what. needs to be in getElementsByTagName()'s definition or in call()'s definition. (If the latter, we also need to put it in a number of other places, like the stuff that interacts with getters/setters.) I would vastly prefer that this check be in the definition of the [[Call]], because then it can be done on the binding level, when you're checking the this object anyway. So e.g. we could put it in call() and define it as checking whether you can obtain the property on the target object before actually executing any code. Is that actually needed? There are properties you can obtain on objects cross-origin (like window.top) that I see no need to allow via this backdoor since no content depends on it now. So I would prefer simply checking whether the origin of the caller matches the origin of this. I don't want us to literally put the checks (in the spec) in each method / property of the four objects with these checks (Document, Window, Location, Storage), since that's a _lot_ of places to put these checks. We could put them in prose in the same places that have the access checks now. Or we could put them elsewhere. Where the current checks are makes the most sense to me, but I'm not sure exactly how to phrase them. Or you could spec what Gecko does, which is that any WebIDL call gets such a check, and then it's just defined in WebIDL. ;) Of course that does mean defining an origin for every object (as opposed to data associated with the object). Except for having to define the origin of things for this purpose, yes, that's what I'm essentially saying. OK. So here's the thing. Given any script-exposed object, it already has to be associated with a specific global. WebIDL makes this a requirement, since you have to find the right prototype object for it. At that point, you have a Window to work with, and a Window has an associated Document, and that has an origin. For object-access checks (again, as opposed to data-access checks), this is the right origin to use. I don't see why EventTarget would be subject to this (it's implemented by things that need checking, but presumably everything that's implemented in that way should just be handled by that host interface the same way as everything on that host interface that isn't white listed). EventTarget isn't implemented. It's inherited from. The only interfaces that are of interest here (that need them and their inherited and implemented interfaces checked) are Document, Window, Location, and Storage. At least, in the HTML spec, as far as I can tell. var myGetter = Object.getOwnPropertyDescriptor(Node.prototype, firstChild).get; var node = myGetter.call(crossOriginDoc); This should throw; we agree on that, right? So I'm not sure what we're disagreeing about here. Perhaps you're thinking of this as throwing because of something crossOriginDoc does, while I'm thinking of it as throwing because of something myGetter does? Again, right now this is implemented in Gecko as part of myGetter's [[Call]], so that's the way I'm thinking of it. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/8/13 1:42 AM, Boris Zbarsky wrote: On 1/7/13 11:28 PM, Ian Hickson wrote: The check is the same -- if the Document that is the this to which the property is being applied doesn't match the origin of the script that is doing the applying, throw SecurityError. Actually, that's not enough. You have to security-check arguments too. Otherwise this: document.createTreeWalker(crossFrameDoc, etc); would be bad. (Note that right now the DOM spec fails to handle this, which is about what I would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 3:11 AM, Adam Barth wrote: I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, Actually, what I'm talking about here has nothing to do with APIs but everything to do with wanting to write web applications that have slightly more privileges than your typical web page. Again, you may want to talk to Jonas and Mounir for details. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. My argument is that we should not lock ourselves out of adding such features in the future. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. I'm not saying we should force anyone to implement any particular security model. I'm saying we shouldn't design/spec things that become completely insecure if the security model ever changes in any way and hence prevent evolution of the security model. Which means that we should assume as little as possible about what the security model guarantees us when specifying things. In my opinion. This paragraph was too abstract for me to understand. Do you have a concrete example? For example, Ian's argument is that you can skip security checks in various places because the security model does that already. My counter-argument is that we should define the behavior of those places by referencing the security model explicitly, so that if the security model changes we won't have to hunt down all the places that had implicit dependencies on it. Does that make more sense? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The current security model describes most common cases, but not some edge cases (see above about a slightly-elevated-privileges web app that can, say, touch nodes from one and only one different origin). More seriously, life gets complicated when you introduce an asymmetric access relation I agree. I believe, however, that for many apps based on web technology you in fact might need this. Again, Sicking and Mounir would know more. https://bugzilla.mozilla.org/show_bug.cgi?id=734891 has some of the things in it, but I'm not sure it's all of them. However, the open web platform contains only a symmetric access relation Yes, I understand that's how it stands now. I'm questioning the viability of this going forward, and especially questioning to what extent we should be intentionally making it impossible to change away from this model. and I intent to argue against any attempt to introduce an asymmetric access That is, of course, your right. ;) Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. That's not enough. Window has the same problem: the document IDL getter needs to check that you're allowed to get the document of the relevant window, for example. Is the check you describe for contentDocument based on origin or effective script origin? -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 2:30 PM, Adam Barth wrote: As a consequence, I would recommend that you do not use asymmetric access relations in features that you would like other browser vendors to implement in the future. Browsers have asymmetric access relations all the time; they just have some of the code in C++. The question is why this should be restricted to C++ code. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 3:12 PM, Adam Barth wrote:
As I've stated several times on this thread (any many times over the
years), my opinion is that we should not expose an asymmetric access
relation to the web platform.
OK, let's agree to disagree on this one for now.
Do we at least agree that this code:
window.addEventListener.call(otherWindow, click, function() {});
should throw if and only window and otherWindow are not same-origin (for
some definition of same-origin, now that we have several different
origins involved...)? And if we do, do we agree that this needs to be
specified somewhere?
-Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, click, function() {});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
Hmm. I may be able to convince that turning security errors like this
into silent no-ops returning undefined is ok, but throwing an exception
seems like a much better idea to me if you're going to completely not do
what you were asked to do... The other option introduces hard-to-debug
bugs.
Yes, but this example is unrelated to the example you started this
thread with.
How so? The example was that IDL methods need to do security checks on
their arguments in various cases.
The WindowProxy and Location objects are special,
magical objects that work differently from other interfaces because
they are visible across origins.
However you prefer to think of it.
The Document interface (which is
what we started this thread discussing) is never visible across
origins
It is in the current spec.
The WindowProxy object is even more complex than the Location object.
It's actually simpler, in the aspects that matter for WebIDL security,
because underlying it is an actual Window object that you're same-origin
with or not, and you can just do security checks on it as needed. And
since the WebIDL is defined to work on the Window, it has to be able to
get to the Window from the WindowProxy anyway.
-Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:33 PM, Adam Barth wrote: For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. The HTML spec requires that property access on documents use effective script origin for checks. Effective script origins are mutable. It is in fact possible to get your hands on a document in a different effective script origin in WebKit (thanks, document.domain). Just saying, Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:28 PM, Anne van Kesteren wrote: You didn't file a bug on this I think. Yes, because the DOM spec is not the right place to address it, imo. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 5:19 PM, Adam Barth wrote: Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. OK. So what checks do you believe are required, then? Just effective script origin checks on Window? I would really appreciate it if you would actually describe the security model you think the spec should have instead of us having to guess what parts you think are needed and which parts you think are not needed, with more gotchas and details all the time. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
Adam, thank you for taking the time to put this together. I really appreciate it. There are lots of things here where we can converge behavior no matter what happens with other pieces of the platform. On 1/9/13 5:58 PM, Adam Barth wrote: Generally speaking, I'd recommend exposing as few things across origins as possible. Yes, agreed. For what it's worth, I believe Gecko recently made history not accessible cross-origin anymore, so with any luck you'll be able to make this change too if desired... 6) In addition, the following APIs have extra security checks. All these APIs return a Node. Before returning the Node, they check whether the Node's document's origin is the same origin as the script calling the API. If not, they return null instead of the node. (We could potentially throw an exception here, but I'm just describing what WebKit does, not what I think the optimum design is.) Returning null for these is probably fine. I think I'd support making this list of things return null cross-origin. Just to check, do you make this determination based on the origin or the effective script origin (in spec terms)? I should also say that it's entirely possible we've screwed up our implementation of this security model. If you discover that we have, I'd prefer if you filed a security bug rather than telling the world on this public mailing list. :) Indeed. ;) -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/11/13 1:29 AM, Adam Barth wrote: On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, agreed. For what it's worth, I believe Gecko recently made history not accessible cross-origin anymore Do you have a link to the bug where that change was made? https://bugzilla.mozilla.org/show_bug.cgi?id=801576 Returning null for these is probably fine. I think I'd support making this list of things return null cross-origin. Just to check, do you make this determination based on the origin or the effective script origin (in spec terms)? The effective script origin. Good, good. So implementing this is pretty straightforward; just have to watch out for compat issues. The fact that you guys do it already should help with that, hopefully. -Boris
Re: [whatwg] AllowSeamless feedback
On 1/18/13 8:40 AM, Anne van Kesteren wrote: On Tue, Jan 15, 2013 at 2:44 PM, Markus Ernst derer...@gmx.ch wrote: The allow-seamless mechanism is to be triggered at the side of the embedded resource, which would also be the one affected by possible security risks (if I get this right). The developer of this resource will have to be aware of these risks, and avoid to expose critical stuff in pages that allow seamless embedding. So, would it be possible to generally treat resources that allow seamless embedding as same-origin from the security POV? No. And AllowSameOrigin would not work either. Because of scripting one resource granting such access means exposing the entire origin to attacks. I'm not sure why. It sounded to me like the proposal was that if a resource is flagged as AllowSameOrigin and loaded in an iframe then the origin it gets is an alias for the origin of the ownerDocument of the iframe (basically the way data: or srcdoc work). That seems like it wouldn't expose too much... except for niggling issues around code that uses location.href to determine origins. :( -Boris
Re: [whatwg] proposal: Add support for masking to canvas
On 1/29/13 11:37 PM, Rik Cabanier wrote: So the API could be as follows: ... unrestricted double? sx; unrestricted double? sy; Do these actually need to be nullable? What's the use case for setting them to null? Same thing for the rest of this dictionary's members. -Boris
Re: [whatwg] proposal: Add support for masking to canvas
On 1/30/13 12:13 AM, Rik Cabanier wrote: ah, sorry. I looked at the dictionary for hitregions Sounds like we should consider fixing this hitregions thing whatever it is. optional unrestricted double sx; That's not actually valid WebIDL, with the optional. And that's because all dictionary members in WebIDL are always optional to start with. So just dropping all those optional should do the trick. Note that this does mean that for things you really must have the prose needs to specify throwing if they're not present. -Boris
Re: [whatwg] proposal: Add support for masking to canvas
On 1/30/13 12:37 AM, Rik Cabanier wrote:
enum CanvasMaskType { luminosity, alpha};
Last nits. Need quotes around the enum values. So:
enum CanvasMaskType { luminosity, alpha };
void maskImage(MaskOptions options);
I believe that has to be:
void maskImage(optional MaskOptions options);
to be valid WebIDL.
Apart from that, the IDL parts look fine. Can't speak to the actual
graphics bits. ;)
-Boris
Re: [whatwg] proposal: Add support for masking to canvas
On 1/30/13 12:55 AM, Rik Cabanier wrote: void maskImage(optional MaskOptions options); Why is it optional? Because http://dev.w3.org/2006/webapi/WebIDL/#idl-operations says (if you scroll down a ways): If the type of an argument is a dictionary type or a union type that has a dictionary type as one of its flattened member types, and this argument is either the final argument or is followed by an optional argument, then the argument MUST be specified as optional. Such arguments are always considered to have a default value of an empty dictionary, unless otherwise specified. It's not optional for 'addHitRegion' in the spec either... Well, then whenever someone tries to actually parse that IDL with a WebIDL parser/validator they'll come filing bugs. ;) -Boris
Re: [whatwg] Fetch: cross-origin redirect to a data URL
On 2/25/13 3:00 PM, Adam Barth wrote: Yes, that's to defend against a different sort of attack. In some browsers, like Firefox, data URLs inherit the security context of their authors. This is not the case for data: URLs that are the target of a redirect, for what it's worth. At least in Firefox, last I checked. The only argument I've seen for Chrome's behavior is in https://bugzilla.mozilla.org/show_bug.cgi?id=786275 -Boris
[whatwg] Adding a btoa overload that takes Uint8Array
The problem I'm trying to solve is sending Unicode text to consumers who need base64-encoded input. Right now the only sane way to do it (and I quote sane for obvious reasons) is something like the example at https://developer.mozilla.org/en-US/docs/DOM/window.btoa#Unicode_Strings It seems like it would be better if the output of a TextEncoder could be passed directly to btoa. But for that we need an overload of btoa that takes a Uint8Array. Thoughts? -Boris
[whatwg] Why are we merging Document and HTMLDocument again?
I'm trying to understand why Document and HTMLDocument got merged. In practice, UAs don't do that, and doing it imposes a performance penalty on manipulating, say, XMLHttpRequest response documents (because the name getter on HTMLDocument makes property access slower on that object). So why are we doing this? -Boris
Re: [whatwg] Why are we merging Document and HTMLDocument again?
On 3/5/13 11:45 AM, Anne van Kesteren wrote: On Tue, Mar 5, 2013 at 4:38 PM, Boris Zbarsky bzbar...@mit.edu wrote: I'm trying to understand why Document and HTMLDocument got merged. In practice, UAs don't do that, and doing it imposes a performance penalty on manipulating, say, XMLHttpRequest response documents (because the name getter on HTMLDocument makes property access slower on that object). So why are we doing this? Because given a random XML MIME type it might end up needing methods from any given special-case document object (you don't know what content you'll have). I suppose we could try to restrict some of the esoteric stuff to only certain objects though... I don't care about the methods. Putting all of those on Document is fine by me, I think. I care about the named getter being forced onto all documents. -Boris
Re: [whatwg] Why are we merging Document and HTMLDocument again?
On 3/5/13 3:30 PM, Ian Hickson wrote: I'd be fine with having a Document descendant that is used for Documents that have global scopes / browsing contexts / the works, and one that is used for Documents that don't (e.g. createDocument(), XHR); would that address this issue? It's one way to address it, yes... -Boris
Re: [whatwg] Proposal: ImageData constructor or factory method with preexisting data
On 3/11/13 7:28 PM, Kenneth Russell wrote:
Proposed IDL:
[NoInterfaceObject]
interface ImageDataFactories {
ImageData createImageData(Uint8ClampedArray data, double sw, double sh);
};
Window implements ImageDataFactories;
WorkerGlobalScope implements ImageDataFactories;
How about just:
[Constructor(Uint8ClampedArray data, double sw, double sh)]
interface ImageData {
/* Whatever is currently there */
};
and then you create one with:
new ImageData(someData, someWidth, someHeight);
Other than needing to specify whether the array is copied or held on to
by reference, and specifying that this interface should be exposed in
workers, this seems fine to me.
-Boris
Re: [whatwg] Proposal: ImageData constructor or factory method with preexisting data
On 3/11/13 11:58 PM, Rik Cabanier wrote: If there are use cases for creating an ImageData, I recommend not making a copy, so all this is doing is taking an existing ArrayBuffer and creating a thin wrapper around the same buffer. I think that would make implementations that defer rendering much more complex and slower. (It would force putImage to execute immediately since it doesn't know if the buffer will change in JS) You never know this anyway with an ImageData, since the data inside it can be mutated from JS. So any existing implementation of putImageData must copy the data immediately or do COW or somehow prove that the data won't be mutated in JS or something. -Boris
Re: [whatwg] Proposal: ImageData constructor or factory method with preexisting data
On 3/12/13 12:56 AM, Glenn Maynard wrote: (I suppose a simpler optimization is simply copy-on-access: make a copy of the backing store if the .data property of ImageData is accessed. This may actually be a harder optimization to make in practice. For example, Gecko+SpiderMonkey has the .data getter on ImageData objects annotated as being pure and returning a constant value. This means that if you have code like this: img.data[0] = 1; img.data[1] = 2; CSE can get rid of the redundant .data gets. Similarly, .data gets can be loop-hoisted in many cases. Based on some spot measurements, at first glance WebKit+V8 has somewhat similar behavior, however they get there (e.g. Gecko used to have a behavior somewhat like this by simply making ImageData be plain-vanilla JS objects with an own data property instead of WebIDL objects, and then the JIT can optimize gets using normal alias analysis techniques for slot gets). But if .data can have side-effects the ability to do these sort of optimizations goes out the window and you get a much slower .data getter. So you get a faster putImageData but the tradeoff is slower imagedata manipulation unless the script author performs the CSE and LICM optimizations by hand (which some do and some don't). So there's no really good way to make this optimization without degrading performance of things people commonly do -Boris
Re: [whatwg] Fetch: number of tasks queued
On 3/13/13 10:36 AM, Anne van Kesteren wrote: For the data:text/html, case Gecko reports both 2 and 4. For data:text/html,test you get 2, 3 test, 4 test. Chrome/Safari dispatch 4 (without test) and then throw mentioning a synchronous request. Seems very much like an implementation bug. IE10 throws on the open() call which is a bug too. I'm leaning towards just reporting 4 for data/about as all the data is already in. Why do you think it's in? In gecko all fetch activity is always asynchronous, independent of URL scheme. Furthermore, the network layer can chunk up the data available callbacks however it wants to ease implementation. Nothing requires it to keep data: in a single flat buffer. I'm strongly opposed to creating scheme-based special cases here based on assumptions about implementation techniques. -Boris
