Implement event propagation for listeners on TameWindow and TameDocument.

For the most part, we use browser native event dispatch for our
virtualized events. load and DOMContentLoaded events have been an
exception for historical reasons (less confidence in the safe use of
initEvent/dispatchEvent) and because there is no host DOM object
corresponding to our TameWindow.

With this change, we now always use native event dispatch (except for
the window.onload _handler_, which is still a specialized kludge).

* Refactor add/removeEventListener's "wrappedListeners" facility into
  new type EventListenerTable, which can be used standalone to perform
  virtual dispatch.
* Introduce SplitEventTarget, which implements a virtual EventTarget
  for each of tameWindow and tameDocument, which dispatches events
  its own listeners see on the containerNode as if there were two
  distinct nodes.
* Tame{Window,Document} {add,remove}EventListener are implemented using
  SplitEventTarget instead of delegating to other nodes. There are no
  longer any special cases for _listeners_ for load or DOMContentLoaded.
  Fixes <https://code.google.com/p/google-caja/issues/detail?id=1792>.
* Implemented TameDocument.prototype.dispatchEvent (previously missing).
* Implemented TameWindow.prototype.dispatchEvent (previously no-op).

Supporting changes:
* TameWindow gets a toString method.

Some additional jQuery UI tests pass, but I have not updated the counts
due to <https://code.google.com/p/google-caja/issues/detail?id=1803>.

[kpreid2, 2013-07-10 19:29:46]

Meta comment: I would be interested in ways to accomplish the same correctness
improvements with less additional code.

[felix8a, 2013-07-10 21:32:52]

I'm confused about this change. it looks like dispatching an event to the tame
window will also dispatch it to the tame document? that isn't what browsers do.

would it be simpler to wrap everything in an actual <caja-v-window> or
<caja-v-defaultView> element?

https://codereview.appspot.com/11128043/diff/1/src/com/google/caja/plugin/dom...
File src/com/google/caja/plugin/domado.js (right):

https://codereview.appspot.com/11128043/diff/1/src/com/google/caja/plugin/dom...
src/com/google/caja/plugin/domado.js:3493: var i;  // closed over!
er, yeah. it took a couple minutes to figure out why that matters. I'd be
happier if that remove() function were a literal within the loop

https://codereview.appspot.com/11128043/diff/1/src/com/google/caja/plugin/dom...
src/com/google/caja/plugin/domado.js:3495: var record = typeTable[+i];
why the + ?

https://codereview.appspot.com/11128043/diff/1/src/com/google/caja/plugin/dom...
src/com/google/caja/plugin/domado.js:3553: match.add(remove);
match.add(remove) reads weirdly. the effect is not at all what I'd expect if I
saw this line of code anywhere else. it's more like
notMatched.addSelfToTableThatDidntFindMeAlongWith(removeHook), but I haven't
thought of a more concise way to say what it means.

maybe change the api to be: table.add(match, removeHook)?

[kpreid2, 2013-07-10 21:44:26]

On 2013/07/10 21:32:52, felix8a wrote:
> I'm confused about this change. it looks like dispatching an event to the tame
> window will also dispatch it to the tame document? that isn't what browsers
do.

Er, no? TameWindow.prototype.dispatchEvent dispatches via windowSplitTarget
only. Events dispatched on TameDocument will be seen at TameWindow, but that
_is_ what browsers do.

> would it be simpler to wrap everything in an actual <caja-v-window> or
> <caja-v-defaultView> element?

Yes, but doing exactly that would be incompatible with the planned
iframe-document-as-container feature. However, what we could do in that case is
use the feral window itself as the extra container to put listeners on (and in
the current world, we can just use the outer level of the double-div — that just
means letting Domado know about it).

I initially avoided this because I didn't want to make Domado care about the
outer container, but after having written this version, I can see that that
might be worth doing instead. It would eliminate the need for both
SplitEventTarget and for extracting EventListenerTable.

So, given that we're not in a hurry about this, I'll write that implementation
and see whether we like it.

[kpreid2, 2013-07-24 22:38:39]

Closing this review as it is superseded by
<https://codereview.appspot.com/11775043/>.

https://codereview.appspot.com/11128043/diff/1/src/com/google/caja/plugin/dom...
File src/com/google/caja/plugin/domado.js (right):

https://codereview.appspot.com/11128043/diff/1/src/com/google/caja/plugin/dom...
src/com/google/caja/plugin/domado.js:3495: var record = typeTable[+i];
On 2013/07/10 21:32:52, felix8a wrote:
> why the + ?

There is an optimization in ES5/3 when the subscript is statically obviously a
number.