Re: [webkit-dev] DOM tree traversal on detached nodes
On Thu, Jun 7, 2012 at 10:27 AM, Darin Adler da...@apple.com wrote: On Jun 6, 2012, at 6:14 PM, Kentaro Hara hara...@chromium.org wrote: IMHO, (a) would be the best semantics. I agree, and I think that the specification actually does require this. The real issue here is how to fix this bug efficiently. I believe that Geoff Garen has been contemplating this and also has a proposal for how to do it. I’d love to see that proposal. Is it written up anywhere? Regarding efficiency: what are the constraints? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Wed, Dec 7, 2011 at 4:53 PM, Oliver Hunt oli...@apple.com wrote: On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote: On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt oli...@apple.com wrote: On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote: Good day, everyone! I am sorry if it didn't sound clear enough in our original message, but we're not proposing a new language support, but we're proposing a patch which allows others runtimes to run along with JS in the browser. Of course, we're doing this because of our work on Dart, but our intent was to solicit a feedback from the WebKit community if there is any interest in supporting runtimes additional to JS (and not JS + Dart) in the first place. As I have already said, we already support multiple bindings being in use at the same time. Those bindings are different because the code that uses them is not activated from web pages. Looking at the specific posted patches, those changes seem necessary to support activating a different language from a page eg script tag. So I think while that your specific claim that WebKit supports multiple bindings at the same time is true, it misses the point. No I was getting sick of the continual claim that this was about supporting multiple VMs/bindings, rather than adding proprietary extensions to webkit Continuing to claim that is your goal is not helpful. Your goal is to allow additional non-standard languages to be provided by webcontent. This is an academic exercise as it doesn't match webkit's goal of being a standards compliant engine, Is that WebKit’s goal? Um, yes. From http://www.webkit.org/projects/goals.html (I'm fairly sure this has already been quoted in an earlier email but just to bring it back in context): GoalsWeb Content EngineThe project's primary focus is content deployed on the World Wide Web, using standards-based technologies such as HTML, CSS, JavaScript and the DOM. --Oliver I intended the question about whether standards compliance was a goal rhetorically, in that it seems to me that this goal is honored or ignored capriciously. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Standard Compliance as a Project Goal (Was WebKit branch to support multiple VMs)
First: Oliver and webkit-dev, sorry for the above email; I wrote it in haste and am now repenting it at leisure. Ryosuke—you’re right; given that the WebKit project goals page has ten high-level goals, of course activity is guided by some trade-off between them. Dominic On Thu, Dec 8, 2011 at 3:00 AM, Ryosuke Niwa rn...@webkit.org wrote: Starting new thread... On Wed, Dec 7, 2011 at 1:13 AM, Dominic Cooney domin...@chromium.orgwrote: On Wed, Dec 7, 2011 at 4:53 PM, Oliver Hunt oli...@apple.com wrote: On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote: On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt oli...@apple.com wrote: On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote: Good day, everyone! I am sorry if it didn't sound clear enough in our original message, but we're not proposing a new language support, but we're proposing a patch which allows others runtimes to run along with JS in the browser. Of course, we're doing this because of our work on Dart, but our intent was to solicit a feedback from the WebKit community if there is any interest in supporting runtimes additional to JS (and not JS + Dart) in the first place. As I have already said, we already support multiple bindings being in use at the same time. Those bindings are different because the code that uses them is not activated from web pages. Looking at the specific posted patches, those changes seem necessary to support activating a different language from a page eg script tag. So I think while that your specific claim that WebKit supports multiple bindings at the same time is true, it misses the point. No I was getting sick of the continual claim that this was about supporting multiple VMs/bindings, rather than adding proprietary extensions to webkit Continuing to claim that is your goal is not helpful. Your goal is to allow additional non-standard languages to be provided by webcontent. This is an academic exercise as it doesn't match webkit's goal of being a standards compliant engine, Is that WebKit’s goal? Um, yes. From http://www.webkit.org/projects/goals.html (I'm fairly sure this has already been quoted in an earlier email but just to bring it back in context): GoalsWeb Content EngineThe project's primary focus is content deployed on the World Wide Web, using standards-based technologies such as HTML, CSS, JavaScript and the DOM. --Oliver I intended the question about whether standards compliance was a goal rhetorically, in that it seems to me that this goal is honored or ignored capriciously. While standards compliance is clearly a good goal, we do have constraints such as having to be compatible with the existing Web content, and for that matter, be consistent with other UAs. Perhaps, what you experienced is that? (i.e. conflict of interests between standards compliance vs. Web/backwards compatibility) - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt oli...@apple.com wrote: On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote: Good day, everyone! I am sorry if it didn't sound clear enough in our original message, but we're not proposing a new language support, but we're proposing a patch which allows others runtimes to run along with JS in the browser. Of course, we're doing this because of our work on Dart, but our intent was to solicit a feedback from the WebKit community if there is any interest in supporting runtimes additional to JS (and not JS + Dart) in the first place. As I have already said, we already support multiple bindings being in use at the same time. Those bindings are different because the code that uses them is not activated from web pages. Looking at the specific posted patches, those changes seem necessary to support activating a different language from a page eg script tag. So I think while that your specific claim that WebKit supports multiple bindings at the same time is true, it misses the point. Continuing to claim that is your goal is not helpful. Your goal is to allow additional non-standard languages to be provided by webcontent. This is an academic exercise as it doesn't match webkit's goal of being a standards compliant engine, Is that WebKit’s goal? OT: Could I get you to review this first patch of many which puts EventTarget on the prototype chain, in accordance with the relevant standards? https://bugs.webkit.org/show_bug.cgi?id=67329 and also has dubious advantage even when supported -- as Vijay said multiple languages already compile to EcmaScript, there is no reason that Dart can't as well. So even if it turns out that this can be implemented without regressing performance of those parts of webkit responsible for supporting open standards, it has a maintenance burden required to support a feature that has no business being in webkit. --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] -webkit-inline-box and visible descendants
Hi webkittens,
Is there a spec for -webkit-inline-box?
I am investigating an assertion failure I can tickle using
-webkit-inline-box. But to fix this, I first need to understand what the
intended behavior is. If I have this markup:
!DOCTYPE html
style
#a {
display: -webkit-inline-box;
visibility: collapse;
}
#b {
visibility: visible;
}
/style
div id=a
div id=b
foo
/div
/div
This displays foo--pretty unsurprising. Same result as if #a had display:
inline-block, incidentally.
However if I wrap #b in another div, nothing is displayed. Plausible because
the new div inherits visibility: collapse from #a. But is this
intended/correct? Because it breaks the analogy with display: inline-block,
which still displays foo.
Any advice appreciated!
Dominic
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Replacing DOM Mutation Events
This looks awesome. Do you have a link to Jonas‘ latest proposal? Because the original one you linked to http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1318.html seems to be different to your patch (eg in API names, etc.) The asymmetry between addMutationListener, which can incrementally register for specific types, and removeMutationListener, which is a blunt instrument, is curious… I would like to read the specific proposal. It would be nice if there was an open source test suite that is easily accessible to UA implementors to ensure implementations are consistent. Dominic On Wed, Aug 17, 2011 at 11:07 AM, Adam Klein ad...@chromium.org wrote: Greetings webkit-dev, It's generally agreed upon in the web community, and in WebKit specifically, that DOM Mutation Events are a bad thing. See, e.g., discussion on https://bugs.webkit.org/show_bug.cgi?id=8191 (relating to DOMAttrModified, and why WebKit does not wish to implement it) and https://lists.webkit.org/pipermail/webkit-dev/2010-August/013805.html (a discussion of replacing DOM mutations with something better, or removing them entirely). In late June, Jonas Sicking and Olli Pettay from Mozilla put forward proposals on public-webapps (http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1318.html) to replace mutation events with a different API, one that avoids the problems associated with the existing spec. Rafael Weinstein has helpfully summarized the public-webapps thread (which is now upwards of 200 messages long) in http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html, and discussion is ongoing in http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0780.html. Any WebKit folks interested in the future of mutation events in the DOM are invited to join that discussion, and their input would be much appreciated. I've also put together a partial implementation of Jonas' most recent proposal and uploaded my work-in-progress patch to https://bugs.webkit.org/show_bug.cgi?id=66079. Note that this is very early work, and if I were submitting it for review it would be in much smaller chunks, but I welcome any comments or questions on the code as-is. - Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS bindings: Adding EventTarget to the prototype chain
Thread necromancy! To summarize the original post: Currently WebKit’s JS binding implements EventTarget as a mixin—all event targets have addEventListener, removeEventListener and dispatchEvent methods. I propose WebKit put EventTarget on the prototype chain. There were two basic questions in response: (1) Why? and (2) Where are the specs going? (1) Why? To summarize the rationale from off-list replies, spec mailing list threads, and webapps bug threads: Making event targets inherit from EventTarget simplifies hooking that functionality from a single choke-point. Otherwise, the web developer has to track down all those separate objects hook each one. Why is EventTarget special? What about other mixins? At the TC39 meeting in November, during a discussion about removing multiple inheritance, EventTarget was brought up as the mixin what would probably want to have global hooking done to it the most. (2) Where are the specs going? The momentum for specifying EventTarget as an interface is building. In my original post I noted that many specs (DOM Core, Notifications, Indexed DB, SVG, XHR) already specified EventTarget as an interface; now the specs Hixie edits (HTML5, Web RTC, Workers, Web Sockets) and FileReader do too. Furthermore, there’s a comment from Jonas Sicking http://www.w3.org/Bugs/Public/show_bug.cgi?id=12574#c3 indicating that Firefox is going to implement EventTarget this way, and from Travis Leithead http://www.w3.org/Bugs/Public/show_bug.cgi?id=12574#c15 endorsing implementing EventTarget this way. Which by my rough reckoning of specs implemented by WebKit, leaves just FileWriter and Web Audio. Both of those specs are in a funny place where they don’t specify EventTarget at all, but are event targets in WebKit. I will follow up with Eric Urhane and Chris Rogers about these. As I mentioned in my original post, the performance impact of this change is minimal. So now that the specs are lined up, are there any objections to making this change? If not I am going to work on reworking the prototype I used to measure performance into a proper patch. Dominic On Fri, Jun 10, 2011 at 7:53 AM, Maciej Stachowiak m...@apple.com wrote: I don't have a personal opinion on which way is technically better myself. But I think the key is getting our code aligned with where standards are going, wether by changing he code or the standards. EventTarget in the prototype chain seems neither especially awesome nor especially terrible to me, it is not really clear to me why editor's drafts of the listed specs decided to change. Cheers, Maciej On Jun 9, 2011, at 1:14 PM, Sam Weinig wrote: I don't think we should do this. EventTarget is really just an abstract interface, and changing its implementation globally is of limited utility. -Sam On Jun 8, 2011, at 5:54 PM, Dominic Cooney wrote: [If you don't care about JSC or V8 bindings you can safely ignore this.] TL;DR I want to change the JavaScript bindings to put EventTarget on the prototype chain so it is easier to work with event targets from JavaScript. What do you think? Here is the prototype chain for a button today: HTMLButtonElement-HTMLElement-Element-Node-Object (add/removeEventListener and dispatchEvent are on Node.) Here is how I think we should make it look: HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object (addEventListener etc. are on EventTarget.) Here’s why I think we should do this: - Specs are moving towards specifying EventTarget as living on the prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR already do it this way. (* Editor’s draft.) - Frameworks that want to hook add/removeEventListener will be able to do it in one place: on EventTarget.prototype. In WebKit today they have to hook the prototypes of window, Node, XMLHttpRequest, etc. individually (Because WebKit implements EventTarget as a mixin everywhere, there are 20+ different kinds of event targets to hook if you want to be comprehensive.) If we make this change, it gets easier to tell if a given object is an EventTarget; just do EventTarget.prototype.isPrototypeOf(something). - It will modestly simplify WebKit’s IDLs and bindings. Instead of declaring addEventListener in two dozen places in IDLs, it will be in one place; instead of calling visitJSEventListeners in dozens of places for JSC GC, it will be called in one place; instead of assuming that EventTarget parameters are all Node* under the covers for V8 code generation, we can treat EventTargets uniformly; instead of redundantly specifying EventTarget on Document and Node inheritance will do what you want; etc. Will doing this break the web? I don’t think so: Anyone who calls or hooks addEventListener, etc. will continue to work, just their foo.addEventListener might be resolved at one level higher up the prototype chain than it is today. To really observe the different placement of addEventListener, etc. minutely you need
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. window.WebKitShadowTreeConstructor // all trees begin at a root, right? window.WebKitShadowTreeScopeConstructor // assuming this can only be used inside the shadow tree For uniformity we were going to also make documents tree scopes. This makes things simpler for script because every element, text node, etc. will be in a tree scope (a document or a shadow root.) Dominic Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 7:35 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote: On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. Calling it shadow tree or shadow content may be imprecise, but surely calling it shadow is outright inaccurate. Consider how you'd complete this sentence: I'd use the Element.webkitShadow API to get the __ for that element. I think I'd fill in that blank with shadow tree or shadow DOM. I certainly wouldn't fill it in with shadow. It sounds like your discussion leans in the direction of shadow container or maybe shadow root. In fact the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes sense. I think webkitShadowRoot makes sense—it is precise, the parallelism with the constructor name makes sense, and the reflexive shadowHost/shadowRoot is nice. Further question: are these APIs going to be part of whatever the XBL2 spec turns into? I can't find them in the latest Editor's draft: http://dev.w3.org/2006/xbl2/Overview.html In fact, XBL2 itself maintains the invariant that the shadow dom cannot be directly observed from the outside at all. Is there a record of the rationale for this rather different direction? Are Mozilla and other likely future implementors (Opera, Microsoft) on board with this change of direction? The aforelinked document ( http://dglazkov.github.com/component-model/dom.html) doesn't really explain the reasons . I also found a list of use cases: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases. But there's not really an explanation of how this proposal meets the use cases, and from cursory examination it seems to blatantly violate one of them in a way that XBL2 did not: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Using_Shadow_DOM_Boundary_for_Isolation These are good questions; Dimitri is a better person to answer them than me. On the security and isolation use case: I take the point about exposing shadowRoot running counter to using shadow DOM as a security boundary. I’m skeptical about that particular use case. I think isolation should be supported by something that puts less emphasis on presentation and is more closely related to the isolation boundary web pages have today (ie iframes.) Easier isolation is appealing, but feels like a pork-barrel amendment to XBL use cases. I have been and am going to keep arguing against it in other venues. I'd like to see all of this explained better before putting this experimental API in the tree. If we are going to invent a new thing instead of implementing XBL2 or working with the relevant standards groups to improve XBL2, I think everyone should understand the reasoning for doing so. Dominic Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JS bindings: Adding EventTarget to the prototype chain
[If you don't care about JSC or V8 bindings you can safely ignore
this.]
TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?
Here is the prototype chain for a button today:
HTMLButtonElement-HTMLElement-Element-Node-Object
(add/removeEventListener and dispatchEvent are on Node.)
Here is how I think we should make it look:
HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
(addEventListener etc. are on EventTarget.)
Here’s why I think we should do this:
- Specs are moving towards specifying EventTarget as living on the
prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
already do it this way. (* Editor’s draft.)
- Frameworks that want to hook add/removeEventListener will be able to
do it in one place: on EventTarget.prototype. In WebKit today they
have to hook the prototypes of window, Node, XMLHttpRequest, etc.
individually (Because WebKit implements EventTarget as a mixin
everywhere, there are 20+ different kinds of event targets to hook if
you want to be comprehensive.) If we make this change, it gets easier
to tell if a given object is an EventTarget; just do
EventTarget.prototype.isPrototypeOf(something).
- It will modestly simplify WebKit’s IDLs and bindings. Instead of
declaring addEventListener in two dozen places in IDLs, it will be in
one place; instead of calling visitJSEventListeners in dozens of
places for JSC GC, it will be called in one place; instead of assuming
that EventTarget parameters are all Node* under the covers for V8 code
generation, we can treat EventTargets uniformly; instead of
redundantly specifying EventTarget on Document and Node inheritance
will do what you want; etc.
Will doing this break the web? I don’t think so:
Anyone who calls or hooks addEventListener, etc. will continue to
work, just their foo.addEventListener might be resolved at one level
higher up the prototype chain than it is today. To really observe the
different placement of addEventListener, etc. minutely you need to
access __proto__ and hasOwnProperty. Other browsers are already differ
from WebKit in this regard, too: For example, Firefox reports
addEventListener is an own property on *every* step in the prototype
chain of DOM objects (until Object.)
Scripts that squirrel up the prototype chain themselves will see one
more link (EventTarget’s) but it is towards the top of the chain, past
most prototypes they care about (every prototype except Object.)
I tried changing half of the EventTargets in WebKit to put EventTarget
in the prototype chain, including Node and XHR (but not window) and
used it to surf the web for a few days. I didn’t notice anything break
:)
There is also the possibility that this could hurt performance,
because accessing addEventListener, etc. will have to search more
prototypes (usually just one more.) Accessing the properties of Object
on an event target via the prototype chain will have to squirrel
through one more prototype (EventTarget’s.) So I prototyped this
change in the JSC bindings and put EventTarget in the prototype chain
of a number of event targets in WebKit, including Node. Here are the
results for Dromaeo’s dom and jslib tests:
http://dromaeo.com/?id=141811,141813
(141811 on the left is the status quo.)
I expect the Prototype and jQuery events benchmarks are of particular
interest, and the result looks particularly bad for Prototype (~3%
slowdown). So I reran http://dromaeo.com/?event half a dozen times,
and couldn’t produce the poor result for Prototype; on average the
prototype was 1.0% slower for Prototype and 0.5% slower for jQuery. I
think Dromaeo is too noisy for measuring something as fine as this.
So I wrote three microbenchmarks:
1. Add/remove click listener on a button.
2. Add/remove progress listener on an XHR.
3. Test property presence with 'in':
if ('dispatchEvent' in target)
n++;
// return n outside of loop
where target is an XMLHttpRequest and n is a local var n = 0.
Here are the results. A brief note on methodology: release build
running in Mac Safari, JSC, averaging 500 samples with 1,000,000
iterations of the inner loop per sample.
1. Add/remove on button
Before (ms): min=409, median=434, mean=434.4, max=472
After (ms): min=410, median=453.5, mean=452.4, max=497 (mean is 1.04x)
2. Add/remove on XHR
Before (ms): min=286, median=298, mean=298.6, max=315
After (ms): min=287, median=300.5, mean=300.7, max=320 (mean is 1.01x)
3. 'dispatchEvent' in XHR
Before (ms): min=85, median=88, mean=87.7, max=91
After (ms): min=89, median=91, mean=91.0, max=95 (mean is 1.04x)
So this shows that, yes, this is not free, but it is low-single
digits. Since adding and removing event listeners is a relatively
infrequent operation, I think this is OK. I want to emphasize that the
change I’m proposing has no impact on native event *dispatch*, which
is obviously a lot more performance-sensitive than adding and
