Re: [WebIDL] T[] migration

2016-01-07 Thread Boris Zbarsky
On 12/18/15 3:53 AM, Simon Pieters wrote: Note that it requires liveness. Does that work for a frozen array? No. You'd have to create a new array object at the point when you want to update the set of values in the array. Maybe this particular API should be a method instead that returns a

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

2015-11-30 Thread Boris Zbarsky
On 11/30/15 8:31 AM, Xiaoqian Wu wrote: The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have been widely implemented by the major browser vendors. Compatibly? Last I checked, for example, Blink doesn't support Dedicated Workers inside workers, only inside Window. I

Re: Callback when an event handler has been added to a custom element

2015-11-06 Thread Boris Zbarsky
On 11/6/15 3:44 PM, Olli Pettay wrote: You need to override addEventListener on EventTarget, and also relevant onfoo EventHandler setters on Window and Document and *Element prototypes Are we trying to just do this best-effort, or reliably? Because this: var ifr =

Re: The key custom elements question: custom constructors?

2015-07-17 Thread Boris Zbarsky
On 7/17/15 12:05 PM, Anne van Kesteren wrote: True, but either way this doesn't seem like a problem. You can create a DocumentFragment, insert a new img, and then let it be GC'd, today. Sure. In practice it won't get GC'd until the load completes, which is sucky, but that's life. -Boris

Re: The key custom elements question: custom constructors?

2015-07-17 Thread Boris Zbarsky
On 7/17/15 10:38 AM, Anne van Kesteren wrote: If I look at update the image data step 6 it seems it might be fetched at a later point? Yes, but in practice the fetch will go ahead, no? There's nothing to prevent it from happening, so it's going to happen once you reach a stable state...

Re: alternate view on constructors for custom elements

2015-07-17 Thread Boris Zbarsky
On 7/17/15 2:03 PM, Travis Leithead wrote: Something magical happens here. The use of super() is supposed to call the constructor of the HTMLElement class—but that’s not a normal JS class. It doesn’t have a defined constructor() method Sure, but neither does Array. What super() actually does

Re: [WebIDL] T[] migration

2015-07-16 Thread Boris Zbarsky
On 7/16/15 12:02 PM, cha...@yandex-team.ru wrote: But would just abandoning T[] break anything elsewhere? It's hard to break something that never worked. No browser ever implemented anything for T[] to my knowledge. -Boris

Re: [WebIDL] T[] migration

2015-07-16 Thread Boris Zbarsky
On 7/16/15 11:45 AM, Travis Leithead wrote: Now that WebIDL has added FrozenArray and dropped T[], it’s time to switch over! On the other hand, there are a number of specs that have already gone to Rec that used the old syntax. Note that since the old syntax was never supported by any UA in

Re: Async Image - ImageData conversion

2015-06-26 Thread Boris Zbarsky
On 6/26/15 4:07 AM, Ashley Gullen wrote: I don't think we should extend HTMLImageElement because it is not available in workers. Adding the conversion methods to ImageBitmap allows workers to perform conversions using Blob (compressed image data) in the place of HTMLImageElement. Maybe I

Re: Async Image - ImageData conversion

2015-06-25 Thread Boris Zbarsky
On 6/24/15 1:28 PM, Ashley Gullen wrote: I'm new to specs and WebIDL, my intent was to say those are new methods on ImageBitmap. Is partial interface ImageBitmap the correct way to say that? Yes, it is. The wording of undue latency in the ImageBitmap spec does not appear to rule out

Re: Async Image - ImageData conversion

2015-06-24 Thread Boris Zbarsky
On 6/19/15 5:43 AM, Ashley Gullen wrote: I've not done this before, so I've no idea if this is the right/useful approach, but I drafted a spec for it here: https://www.scirra.com/labs/specs/imagedata-blob-extensions.html Ashley, We at Mozilla were just discussing this proposal, and we have a

Re: Async Image - ImageData conversion

2015-06-24 Thread Boris Zbarsky
On 6/19/15 5:43 AM, Ashley Gullen wrote: I've not done this before, so I've no idea if this is the right/useful approach, but I drafted a spec for it here: https://www.scirra.com/labs/specs/imagedata-blob-extensions.html Let me know if you have any feedback on this. Ashley, I assume the

Re: Writing spec algorithms in ES6?

2015-06-11 Thread Boris Zbarsky
On 6/11/15 4:32 PM, Dimitri Glazkov wrote: I noticed that the CSS Color Module Level 4 actually does this, and it seems pretty nice: http://dev.w3.org/csswg/css-color/#dom-rgbcolor-rgbcolorcolor I should note that the ES code there produces semantics that don't match the IDL in this spec (or

Re: Custom Elements: insert/remove callbacks

2015-05-09 Thread Boris Zbarsky
On 5/9/15 12:40 PM, Anne van Kesteren wrote: So that seems clearly wrong (in the specification)... Are descendants notified in tree order? In Gecko, yes. Note that running script during these insert/remove notifications is not OK, so anything that needs to run script has to do it later (for

Re: Custom Elements: insert/remove callbacks

2015-05-08 Thread Boris Zbarsky
On 5/8/15 1:42 AM, Elliott Sprehn wrote: That actually seems pretty similar to what we have, ours is in the form of: Node#insertedInto(Node insertionPoint) Node#removedFrom(Node insertionPoint) To be clear, ours is also in the form of two methods (BindToTree/UnbindFromTree) that take various

Re: Custom Elements: insert/remove callbacks

2015-05-07 Thread Boris Zbarsky
On 5/7/15 3:43 AM, Anne van Kesteren wrote: On Wed, May 6, 2015 at 11:01 PM, Justin Fagnani justinfagn...@google.com wrote: How are you supposed to tell if one of your ancestors was removed? Is that a hook builtin elements have today? In Gecko, yes. The set of hooks Gecko builtin elements

Re: Why is querySelector much slower?

2015-04-29 Thread Boris Zbarsky
On 4/29/15 12:23 AM, Glen Huang wrote: because of the proxy machinery involved on the JS engine side Do you mean the cost introduced by passing a C++ object into ecmascript world? No, it's the cost introduced by needing custom property behavior for integer-named properties on lists (and in

Re: Why is querySelector much slower?

2015-04-28 Thread Boris Zbarsky
On 4/28/15 2:44 AM, Glen Huang wrote: But If I do getElementsByClass()[0], and LiveNodeList is immediately garbage collectable Then it will only be collected the next time GC happens. Which might not be for a while. -Boris

Re: Why is querySelector much slower?

2015-04-28 Thread Boris Zbarsky
On 4/28/15 1:58 AM, Glen Huang wrote: Just a quick follow up question to quench my curiosity: if I do list[1] and no one has ever asked the list for any element, Gecko will find the first two matching elements, and store them in the list, if I then immediately do list[0], the first element is

Re: Why is querySelector much slower?

2015-04-28 Thread Boris Zbarsky
On 4/28/15 2:13 AM, Glen Huang wrote: On second thought, if the list returned by getElementsByClass() is lazy populated as Boris says, it shouldn't be a problem. The list is only updated when you access that list again. Mutations have to check whether the list is marked dirty already or not.

Re: Why is querySelector much slower?

2015-04-28 Thread Boris Zbarsky
On 4/28/15 2:59 AM, Glen Huang wrote: Looking at the microbenchmark again, for Gecko, getElementById is around 300x faster than querySelector('#id'), and even getElementsByClassName is faster than it. This is why one should not write microbenchmarks. ;) Or at least if one does, examine

Re: Why is querySelector much slower?

2015-04-27 Thread Boris Zbarsky
On 4/27/15 11:27 PM, Glen Huang wrote: When you say var node = list[0]; walks the DOM until the first item is found, do you mean it only happens under the condition that some previous code has changed the DOM structure? Or that no one has ever asked the list for its [0] element before, yes.

Re: Exposing structured clone as an API?

2015-04-23 Thread Boris Zbarsky
On 4/23/15 9:31 PM, Kyle Huey wrote: Today it's not demanding, it's not even possible. e.g. how do you duplicate a FileList object? Ah, there we go. I figured there was something that would fail the ways of cloning them all test in the platform today... ;) We should make it possible to

Re: Exposing structured clone as an API?

2015-04-23 Thread Boris Zbarsky
On 4/23/15 6:34 PM, Elliott Sprehn wrote: Have you benchmarked this? I think you're better off just writing your own clone library. That requires having a list of all objects browsers consider clonable and having ways of cloning them all, right? Maintaining such a library is likely to be a

Re: Privileged context features and JavaScript

2015-04-17 Thread Boris Zbarsky
On 4/17/15 2:44 AM, Mike West wrote: Consider Geolocation, for instance: users can disable the API entirely in Chrome (and, I assume, other browsers). Should we remove the API in these cases as well? There's no user-facing UI to disable geolocation in Firefox, but there is a preference that

Re: Privileged context features and JavaScript

2015-04-17 Thread Boris Zbarsky
On 4/17/15 2:52 AM, Boris Zbarsky wrote: If that preference is toggled, we in fact remove the API entirely, so that 'geolocation' in navigator tests false. Oh, I meant to mention: this is more web-compatible than having the API entrypoints throw, because it can be object-detected. Of course

Re: Privileged context features and JavaScript

2015-04-17 Thread Boris Zbarsky
On 4/17/15 3:38 AM, Elliott Sprehn wrote: It's preferable not to do that for us because you can then create a static heap snapshot at compile time and memcpy to start JS contexts faster. For this specific case, where there are only two possibilities (privileged or not) it seems like you can

Re: Privileged context features and JavaScript

2015-04-17 Thread Boris Zbarsky
On 4/17/15 2:44 AM, Mike West wrote: Either way, expressing the constraint via IDL seems totally reasonable. OK, so let's say we do the API is still present but fails somehow thing. How would one express that constraint via IDL? What would the normative language be? It seems like the best

Re: Privileged context features and JavaScript

2015-04-17 Thread Boris Zbarsky
On 4/17/15 7:58 AM, Ashley Gullen wrote: I think the existence of the API functions should indicate the browser has the capability, and then the API returns an error if it's not allowed to be used in the current context. I think this would improve the quality of messages seen by users, since for

Re: Privileged context features and JavaScript

2015-04-17 Thread Boris Zbarsky
On 4/17/15 11:13 AM, Anne van Kesteren wrote: A bunch of the new non-legacy APIs (that is geolocation doesn't count) have some kind of promise thing you need to get past before things start working. For those APIs we could have something with normative language. I don't see how we could make

Re: [Imports] Considering imperative HTML imports?

2015-04-16 Thread Boris Zbarsky
On 4/16/15 12:37 AM, Travis Leithead wrote: Was an imperative form of HTML imports already considered? E.g., the following springs to mind: PromiseDocument importDocument(DOMString url); How is this different from a promise-ified version of XHR, exactly? (Not that there's anything wrong

Re: WebIDL Plans

2015-04-14 Thread Boris Zbarsky
On 4/14/15 8:22 AM, Yves Lafon wrote: I remember ArrayClass removed from NodeList for the reason of lack of implementations, and even plans for implementation It was removed because as things stand it's not web-compatible. Once @@isConcatSpreadable exists in implementations, we could and

Re: [websockets] Test results available

2015-04-02 Thread Boris Zbarsky
On 4/2/15 8:15 AM, Simon Pieters wrote: http://www.w3c-test.org/websockets/keeping-connection-open/001.html -- the test is wrong. Passing undefined means the argument is not present per Web IDL, so this should not throw. I assume you mean some other test since that test doesn't use undefined.

Re: [W3C TCP and UDP Socket API]: Status and home for this specification

2015-04-01 Thread Boris Zbarsky
On 4/1/15 12:50 PM, Domenic Denicola wrote: Do you think it's acceptable for browser to experiment with e.g. auto-granting permission if the requested remoteAddress is equal to the IP address of the origin executing the API? This particular example sets of alarm bells for me because of

Re: [websockets] Test results available

2015-03-26 Thread Boris Zbarsky
On 3/26/15 10:51 AM, Arthur Barstow wrote: If anyone is willing to help with the failure analysis, that would be very much appreciated. Taking a brief look at some of the failures in Firefox, in addition to the ones Olli already posted about:

Re: [websockets] Test results available

2015-03-26 Thread Boris Zbarsky
On 3/26/15 10:51 AM, Arthur Barstow wrote: * All results http://w3c.github.io/test-results/websockets/all.html * 2 passes http://w3c.github.io/test-results/websockets/less-than-2.html Overall these results are pretty good: 97% of the 495 tests have two or more passes. Arthur, It looks like

Re: [websockets] Test results available

2015-03-26 Thread Boris Zbarsky
On 3/26/15 1:02 PM, Boris Zbarsky wrote: It looks like the tests that are failed with an Error as opposed to a Fail are not being counted in the 2 passes list? And the for http://www.w3c-test.org/websockets/keeping-connection-open/001.html which is all-Timeout. -Boris

Re: Custom elements: synchronous constructors and cloning

2015-02-23 Thread Boris Zbarsky
On 2/23/15 4:27 AM, Anne van Kesteren wrote: 1) If we run the constructor synchronously, even during cloning. If the constructor did something unexpected, is that actually problematic? It is not immediately clear to me what invariants we might want to preserve. Possibly it's just that the code

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Boris Zbarsky
On 2/11/15 3:04 PM, Brendan Eich wrote: If you want multi-threaded DOM access, then again based on all that I know about the three open source browser engines in the field, I do not see any implementor taking the huge bug-risk and opportunity-cost and (mainly) performance-regression hit of

Re: Thread-Safe DOM // was Re: do not deprecate synchronous XMLHttpRequest

2015-02-11 Thread Boris Zbarsky
On 2/11/15 9:45 PM, Marc Fawzi wrote: this backward compatibility stuff is making me think that the web is built upon the axiom that we will never start over and we must keep piling up new features and principles on top of the old ones Pretty much, yep. this has worked so far, miraculously

Re: do not deprecate synchronous XMLHttpRequest

2015-02-10 Thread Boris Zbarsky
On 2/10/15 12:28 PM, Marc Fawzi wrote: Launch an async xhr and monitor its readyState in a while loop and don't exit the loop till it has finished. Per spec (and in implementations last I checked), the readyState isn't allowed to change during the loop. So all that will happen is you will

Re: oldNode.replaceWith(...collection) edge case

2015-01-21 Thread Boris Zbarsky
On 1/21/15 3:52 AM, Simon Pieters wrote: This jsperf might be interesting: http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/81 Or misleading. Again, in real life what matters most here is what else is on the page, which the jsperf doesn't capture. The other thing that really

Re: oldNode.replaceWith(...collection) edge case

2015-01-20 Thread Boris Zbarsky
On 1/20/15 6:45 PM, Glen Huang wrote: I vaguely remember document fragment is introduced just to reduce reflows. Looks like this best practice is obsolete now? You don't have to use a document fragment to reduce reflows, as long as you don't query layout information between your DOM

Re: Minimum viable custom elements

2015-01-14 Thread Boris Zbarsky
On 1/14/15 9:45 AM, Anne van Kesteren wrote: * No subclassing of normal elements for now. You mean subclassing anything more specific than HTMLElement/SVGElement, yes? Presumably we still want subclassing of HTMLElement and maybe SVGElement? * Parsing of declarative syntax invokes the

Re: Custom element design with ES6 classes and Element constructors

2015-01-14 Thread Boris Zbarsky
On 1/14/15 8:28 AM, Anne van Kesteren wrote: On Wed, Jan 14, 2015 at 2:00 PM, Boris Zbarsky bzbar...@mit.edu wrote: Wanting things like custom buttons is _very_ common. What is your proposal for addressing this use case? I have no good answer. appearance:button seems to work okayish I

Re: Custom element design with ES6 classes and Element constructors

2015-01-14 Thread Boris Zbarsky
On 1/14/15 11:52 AM, Dimitri Glazkov wrote: Would like to point out that we're not talking about a general case here. The actual proto munging in custom elements spec is minimized to a pretty small set. Pretty small set of which? Possible mutations, elements, something else. Given that most

Re: Custom element design with ES6 classes and Element constructors

2015-01-14 Thread Boris Zbarsky
On 1/14/15 7:51 AM, Anne van Kesteren wrote: I would rather we gave up on subclassing normal elements Wanting things like custom buttons is _very_ common. What is your proposal for addressing this use case? -Boris

Re: Custom element design with ES6 classes and Element constructors

2015-01-13 Thread Boris Zbarsky
On 1/13/15 12:06 PM, Gabor Krizsanits wrote: I think this part of the spec was largely written before ES6 class stuff stabilized, fwiw. Which is not hard, since it's still not stabilized. ;) Isn't there a chance to consider our use-case in ES6 spec. then? I suspect not in time for ES6.

Re: Defining a constructor for Element and friends

2015-01-13 Thread Boris Zbarsky
On 1/13/15 12:05 PM, Domenic Denicola wrote: From: Boris Zbarsky [mailto:bzbar...@mit.edu] var x = new Element(a, http://www.w3.org/1999/xhtml;) The idea is that your above example throws, preserving the invariant. That sounds annoying Presumably this means

Re: Defining a constructor for Element and friends

2015-01-13 Thread Boris Zbarsky
On 1/13/15 1:18 PM, Ryosuke Niwa wrote: I agree. It's unusual for a constructor of a super class to automatically instantiate an arbitrary subclass based on its arguments. And we usually solve that convenience problem by introducing a factory class/function. While true, I do think there's a

Re: Custom element design with ES6 classes and Element constructors

2015-01-13 Thread Boris Zbarsky
On 1/13/15 12:50 PM, Domenic Denicola wrote: Agreed. That needs to be done with img is=my-img, IMO. (Assuming the upgrading design doesn't get switched to DOM mutation, of course.) Although! Briefly yesterday Arv mentioned that for Blink's DOM implementation there's no real difference in

Re: Custom element design with ES6 classes and Element constructors

2015-01-13 Thread Boris Zbarsky
On 1/13/15 12:10 PM, Domenic Denicola wrote: Hmm. So given the current direction whereby ES6 constructors may not even be [[Call]]-able at all, I'm not sure we have any great options here. :( Basically, ES6 is moving toward coupling allocation and initialization but the upgrade scenario

Re: Defining a constructor for Element and friends

2015-01-13 Thread Boris Zbarsky
On 1/13/15 1:33 PM, Ryosuke Niwa wrote: Shouldn't we throw in this case because the concert type of somename is HTMLUnknownElement? Oh, hmm. Yes, I guess so. That's very non-obvious to an author. Even less obvious because for some tag names using the HTMLElement constructor is in fact

Re: Adopting a Custom Element into Another Document

2015-01-13 Thread Boris Zbarsky
On 1/13/15 2:43 PM, Domenic Denicola wrote: Why is the tree data structure embodied by the DOM any different? The issue is not the tree structure but rather 1) what it means to have a certain document as your ownerDocument and 2) Whether there are footguns here that make it too easy for

Re: [Selection] Should selection.getRangeAt return a clone or a reference?

2015-01-12 Thread Boris Zbarsky
On 1/12/15 1:56 PM, Olivier Forget wrote: Unfortunately multiple range selections are not a nice to have. All real editors (MS Word, Google Docs, etc..) support selecting multiple ranges Precisely. This is why Gecko ended up supporting it: it was needed for the editor that was part of the

Re: Custom element design with ES6 classes and Element constructors

2015-01-12 Thread Boris Zbarsky
On 1/12/15 12:20 PM, Tab Atkins Jr. wrote: Proto munging isn't even that big of a deal. That really depends. For example, dynamically changing __proto__ on something somewhat permanently deoptimizes that object in at least some JS engines. Whether that's a big deal depends on what you do

Re: Defining a constructor for Element and friends

2015-01-12 Thread Boris Zbarsky
On 1/11/15 2:33 PM, Domenic Denicola wrote: Terminology: In what follows I use 'own-instances of X' to mean objects where obj.constructor === X, That doesn't make much sense to me as a useful test, since it's pretty simple to produce, say, an HTMLParagraphElement instance on the web that

Re: Custom element design with ES6 classes and Element constructors

2015-01-12 Thread Boris Zbarsky
On 1/11/15 3:13 PM, Domenic Denicola wrote: So, at least as a thought experiment: what if we got rid of all the local name checks in implementations and the spec. I think then `my-q` could work, as long as it was done *after* `document.registerElement` calls. Yes. However, I don't

Re: Custom element design with ES6 classes and Element constructors

2015-01-12 Thread Boris Zbarsky
On 1/12/15 7:24 PM, Domenic Denicola wrote: One crazy idea for solving B is to make every DOM element (or at least, every one generated via parsing a hyphenated or is= element) into a proxy whose target can switch from e.g. `new HTMLUnknownElement()` to `new MyEl()` after upgrading. Like

Re: Defining a constructor for Element and friends

2015-01-09 Thread Boris Zbarsky
On 1/9/15 8:01 PM, Domenic Denicola wrote: I was writing up my ideas in an email but it kind of snowballed into something bigger so now it's a repo: https://github.com/domenic/element-constructors Domenic, thanks for putting this together. Caveat: I won't get a chance to read through this

Re: Custom element lifecycle callbacks

2015-01-09 Thread Boris Zbarsky
On 1/9/15 9:33 AM, Anne van Kesteren wrote: On Fri, Jan 9, 2015 at 3:09 PM, Boris Zbarsky bzbar...@mit.edu wrote: In any case, the fact that we're even _having_ this discussion and that it needs careful reading of the HTML spec is my point. It does seem however we could define this in a way

Re: Custom element lifecycle callbacks

2015-01-09 Thread Boris Zbarsky
On 1/9/15 8:46 AM, Anne van Kesteren wrote: As far as I can tell from the specification, when the value IDL attribute is in the filename mode, any values that might be stored in internal slots are ignored. Hmm... That was not obvious to me, but OK. I guess it uses the list of selected files

Re: Custom element lifecycle callbacks

2015-01-09 Thread Boris Zbarsky
On 1/9/15 7:14 AM, Anne van Kesteren wrote: Both parent and input need to be cloned in this case. While parent's callback runs it changes the type of input, at which point input's callback runs. So, yes. OK. So just to be clear, the type will be set before the input's cloning callback runs,

Re: Custom element lifecycle callbacks

2015-01-09 Thread Boris Zbarsky
On 1/9/15 4:28 AM, Anne van Kesteren wrote: On Thu, Jan 8, 2015 at 5:54 PM, Boris Zbarsky bzbar...@mit.edu wrote: var input = document.createElement(input); input.value = file:///etc/passwd; var newInput = input.cloneNode(); newInput.type = file; Note that in the above example

Re: Custom element lifecycle callbacks

2015-01-08 Thread Boris Zbarsky
On 1/8/15 10:56 AM, Anne van Kesteren wrote: 2) For normal elements we act directly when they are cloned or adopted. How much interest is there in delaying what happens for normal elements to align them with custom elements? Which things are we talking about delaying? I'm pretty sure the

Re: Defining a constructor for Element and friends

2015-01-07 Thread Boris Zbarsky
On 1/7/15 6:17 AM, Anne van Kesteren wrote: The main tricky thing here I think is whether it is acceptable to have an element whose name is a, namespace is the HTML namespace, and interface is Element. That depends on what you mean by interface is Element. If you mean that it has all the

Re: Defining a constructor for Element and friends

2015-01-07 Thread Boris Zbarsky
On 1/7/15 9:51 AM, Anne van Kesteren wrote: That is what I meant. Otherwise in order to support new Element() you'd have to support an ever growing set of more specific objects as well and layering is out of the window. Do you mean layering of implementations or specifications? For

Re: HTML imports in Firefox

2014-12-15 Thread Boris Zbarsky
On 12/15/14, 1:10 PM, Ashley Gullen wrote: Why would modules affect the decision to ship HTML imports? Because the interaction of the various import systems with each other needs to be specified, for one thing. But more to the point, we're not shipping imports because we've gotten feedback

Re: HTML imports in Firefox

2014-12-15 Thread Boris Zbarsky
On 12/15/14, 3:09 PM, Arthur Barstow wrote: Does [Bugzilla] capture all of Mozilla's Imports concerns (or at least the higher priority issues)? Not yet. We've just gotten things sorted out on our end. If not, who should I contact to request capturing your concerns? I think Anne's email

Re: Help with WebIDL v1?

2014-12-03 Thread Boris Zbarsky
On 12/3/14, 6:02 AM, Yves Lafon wrote: Pretty much like refactoring XHR using Fetch or not. Most implementations will most probably move to the latest version, but the external interface will be the same. External interface being the IDL syntax in this case, not the resulting web-exposed

Re: Help with WebIDL v1?

2014-12-01 Thread Boris Zbarsky
On 12/1/14, 1:49 PM, Travis Leithead wrote: I believe so; this will give many specs a baseline WebIDL document to point to in their references at the very least. Many specs don't rely on the more advanced feature set being defined in WebIDL Second Edition. Here's the problem. As of today,

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

2014-10-18 Thread Boris Zbarsky
On 10/17/14, 8:19 PM, Hallvord R. M. Steen wrote: a) Ship a TR based on the spec just *before* the big Fetch refactoring. If we want to publish something at all, I think this is the most reasonable option, frankly. I have no strong opinions on whether this is done REC-track or as a Note, I

Re: PSA: publishing new WD of URL spec

2014-09-11 Thread Boris Zbarsky
On 9/11/14, 12:52 PM, Mark Baker wrote: On Thu, Sep 11, 2014 at 12:13 PM, Anne van Kesteren ann...@annevk.nl wrote: In which case the WHATWG version wouldn't be canonical anymore anyway. It would be for implementers. Only those implementers that can afford to staff a team to keep up with a

Re: publishing new WD of URL spec

2014-09-10 Thread Boris Zbarsky
On 9/10/14, 6:14 PM, Glenn Adams wrote: and they do not follow a consensus process. Glenn, with all due respect, neither do many W3C specifications. Case in point is http://www.w3.org/TR/navigation-timing/ which managed to get to REC while ignoring feedback that pointed out that not a

Re: Proposal for a Permissions API

2014-09-02 Thread Boris Zbarsky
On 9/2/14, 9:51 AM, Mounir Lamouri wrote: required PermissionName name; Glad to see required being put to good use. ;) interface PermissionManager { IDL nit: This needs Exposed=(Window,Worker) [NoInterfaceObject, Exposed=Window,Worker] And parens. -Boris

Re: First Draft of W3C version of URL Spec

2014-08-27 Thread Boris Zbarsky
On 8/27/14, 4:50 PM, Daniel Appelquist wrote: with a few minimal editorial changes. What are the changes, specifically? -Boris

Re: =[xhr]

2014-08-01 Thread Boris Zbarsky
On 8/1/14, 9:39 AM, nmork_consult...@cusa.canon.com wrote: All tabs, menus, etc. must be frozen. Sync XHR doesn't do that. -Boris

[imports] credentials flag bits need to be updated to current fetch terminology

2014-07-15 Thread Boris Zbarsky
In http://w3c.github.io/webcomponents/spec/imports/#fetching-import the spec says: Fetch a resource from LOCATION with request's origin set to the origin of the master document, the mode to CORS and the omit credentials mode to CORS. There is no omit credentials mode in the current Fetch

Re: Fallout of non-encapsulated shadow trees

2014-07-02 Thread Boris Zbarsky
On 7/2/14, 11:07 AM, Adam Barth wrote: I've studied the XBL implementation of marquee in Gecko, and it does leak some implementation details. Absolutely. The point of the XBL implementation was to provide the functionality (back before there was a spec for it, note) at minimal cost and core

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Boris Zbarsky
On 7/1/14, 9:16 PM, Ryosuke Niwa wrote: I would love to hear from Mozillians if they have gotten enough developer feedbacks Our implementation is currently at a stage that can best be described as not usable yet, which is most of the feedback we've gotten thus far. ;) -Boris

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Boris Zbarsky
On 7/1/14, 9:13 PM, Brendan Eich wrote: Are you sure? Because Gecko has used XBL (1) to implement, e.g., input type=file, or so my aging memory says. We use XBL to implement marquee. We do not use XBL to implement input type=file, though there was once a project to do that sort of thing.

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Boris Zbarsky
On 7/1/14, 11:20 PM, Brendan Eich wrote: XBL can expose anonymous content via special API: https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/DOM_Interfaces#getAnonymousNodes https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/XBL_Example

Re: Fallout of non-encapsulated shadow trees

2014-07-01 Thread Boris Zbarsky
On 7/2/14, 12:15 AM, Brendan Eich wrote: Boris Zbarsky wrote: On 7/1/14, 9:13 PM, Brendan Eich wrote: Are you sure? Because Gecko has used XBL (1) to implement, e.g., input type=file, or so my aging memory says. We use XBL to implement marquee. Also video playback controls, per your next

Re: Should / Can an EventHandler throw a stack overflow exception?

2014-06-30 Thread Boris Zbarsky
On 6/30/14, 4:40 AM, Anne van Kesteren wrote: Are stack overflow exceptions even a thing per standards? No. However, they come up pretty regularly in practice. In fact, some sites depend on them for proper functioning. :( -Boris

Re: WebIDL Spec Status

2014-06-24 Thread Boris Zbarsky
On 6/24/14, 6:56 AM, Charles McCathie Nevile wrote: While nobody is offering an editor who can get the work done, this argument is in any case academic (unless the editor's availability is predicated on the outcome, in which case it would be mere political machinations). I strongly disagree

Re: WebIDL Spec Status

2014-06-24 Thread Boris Zbarsky
On 6/24/14, 1:05 PM, Glenn Adams wrote: Such device certification regimes cannot work unless the referenced specifications are locked down and clearly implementable. I see. So this is not about actual spec implementations or spec authors but effectively about a QA cycle that compares the

Re: WebIDL Spec Status

2014-06-24 Thread Boris Zbarsky
On 6/24/14, 1:46 PM, Glenn Adams wrote: The primary goal of the W3C is to produce Technical Reports that reach a stable level of maturity. The Technical Reports are not an end in themselves. They're a means to an end. This is why we don't produce Technical Reports that just say do whatever

Re: HTML imports: new XSS hole?

2014-06-03 Thread Boris Zbarsky
On 6/3/14, 12:48 PM, Hajime Morrita wrote: HTML Imports are a bit more strict. They see CORS header and decline if there is none for cross origin imports. Also, requests for imports don't send any credentials to other origins. These two measures prevent attacks on other origins via imports.

Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky
On 6/2/14, 8:54 AM, James M Snell wrote: So long as they're handled with the same policy and restrictions as the script tag, it shouldn't be any worse. It's worse for sites that have some sort of filtering on user-provided content but don't catch this case right now, no? -Boris

Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky
On 6/2/14, 9:22 AM, James M Snell wrote: Yes, that's true. Content filters are likely to miss the links themselves. Hopefully, the imported documents themselves get filtered By what, exactly? I mean, CSP will apply to them, but not website content filters... One assumption we can possibly

Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky
On 6/2/14, 9:54 AM, James M Snell wrote: Im not saying it's perfect. Not by any stretch. I'm saying it shouldn't be worse. I don't understand why you think it's not worse. and content filters will need to evolve. And until they do, we may have vulnerable pages, right? How is that not

Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky
On 6/2/14, 4:21 PM, Giorgio Maone wrote: I do hope any filter already blocked out link elements, as CSS has been a XSS vector for a long time link elements without stylesheet in rel don't load CSS, though. Hence the worries about blacklist vs whitelist... -Boris

Re: HTML imports: new XSS hole?

2014-06-02 Thread Boris Zbarsky
On 6/2/14, 11:17 PM, Eduardo' Vela Nava wrote: Now, I'm not sure how many have tried to implement an HTML sanitizers. I've reviewed Gecko's implementation of one, if that counts... 1. You have to write a parser OR You have to use a third-party parser. Wasn't an issue for us obviously.

Re: Fetch API

2014-06-01 Thread Boris Zbarsky
On 6/1/14, 2:06 AM, Domenic Denicola wrote: - Named constructors scare me (I can't figure out how to make them work in JavaScript without breaking at least one of the normal invariants). I think a static factory method would make more sense for RedirectResponse. Or just a constructor

Re: Blob URL Origin

2014-05-16 Thread Boris Zbarsky
On 5/16/14, 10:11 AM, Anne van Kesteren wrote: What exactly is wrong with the data URL model that we have today The fact that some UAs don't want to implement it? and how do we plan on fixing it? We don't have a plan yet. But I guess this is a scenario you explicitly want to outlaw, even

Re: Blob URL Origin

2014-05-16 Thread Boris Zbarsky
On 5/16/14, 10:39 AM, Anne van Kesteren wrote: The fact that some UAs don't want to implement it? Do we know why? They think it's a security problem. -Boris

Re: Blob URL Origin

2014-05-16 Thread Boris Zbarsky
On 5/16/14, 11:08 AM, Anne van Kesteren wrote: Not tainting canvas? Same-origin iframe? Doesn't matter? The same-origin iframe bit. I think everyone is on board with not tainting canvas for data: things. -Boris

Re: Blob URL Origin

2014-05-13 Thread Boris Zbarsky
On 5/13/14, 1:20 AM, Frederik Braun wrote: On 12.05.2014 18:41, Jonas Sicking wrote: (new URL(url)).origin should work, no? It does not work for blob URIs in Firefox. It can't work, given how URL.origin is currently defined... It's possible that definition should change, though. -Boris

Re: Custom Elements: 'data-' attributes

2014-05-13 Thread Boris Zbarsky
On 5/13/14, 7:31 AM, Dimitri Glazkov wrote: Sole had the idea of providing hooks for attributes so a component can say it handles them rather than the user agent. That makes a lot of sense to me. That way you can grab any name, even existing ones. 3 this idea, would love to hear more. It's

Re: Blob URL Origin

2014-05-12 Thread Boris Zbarsky
On 5/12/14, 5:28 AM, Anne van Kesteren wrote: so blob:https://origin:42/uuid would be fine. I'd really rather we didn't make web pages parse these strings to get the origin. A static method on Blob that takes a valid blob: URI and returns its origin seems like it should be pretty easy for

  1   2   3   4   5   6   7   8   >