event-related fixes for IE

This fixes http://code.google.com/p/google-caja/issues/detail?id=1132

1.  Support event.currentTarget on IE.

2.  YUI has a couple special behaviors on IE.
    Since YUI in caja on IE will detect the browser as IE,
    YUI will try to do the IE-specific things:

2a. IE doesn't support event.relatedTarget,
    so YUI tries to set it.
    Caja does support event.relatedTarget,
    and it's read-only (per DOM spec),
    so YUI's attempt to set it throws an exception.
    This change adds a relatedTarget setter that
    ignores the new value and doesn't throw.

2b. IE has some non-standard functions that
    YUI will call: el.hasFocus() and el.setActive().
    setActive is a weaker form of focus().
    It makes the element 'active',
    which means it will have focus when the window gets focus,
    but doesn't force the window to be focused.

    This change adds support for both methods,
    delegating to the IE functions.

    el.setActive() is restricted the same way as el.focus(),
    it's only allowed when isProcessingEvent___

[felix8a, 2009-10-24 17:29:39]

er, hangon.  the webdriver DomitaTest fails.
I suspect because it doesn't really simulate event capture/bubble.

[felix8a, 2009-10-24 17:48:54]

On 2009/10/24 17:29:39, felix8a wrote:
> er, hangon.  the webdriver DomitaTest fails.

ok, fixed.  webdriver supplies a strange value for relatedTarget
when simulating mouseclicks.

[MikeSamuel, 2009-11-05 03:56:28]

http://codereview.appspot.com/140051/diff/7/9
File src/com/google/caja/plugin/domita.js (right):

http://codereview.appspot.com/140051/diff/7/9#newcode2968
Line 2968: return void 0;
Should it return the value passed in, so that (foo = foo.relatedTarget = bar)
assign bar to foo?

[felix8a, 2009-11-05 05:17:54]

http://codereview.appspot.com/140051/diff/7/9
File src/com/google/caja/plugin/domita.js (right):

http://codereview.appspot.com/140051/diff/7/9#newcode2968
Line 2968: return void 0;
On 2009/11/05 03:56:28, MikeSamuel wrote:
> Should it return the value passed in, so that (foo = foo.relatedTarget = bar)
> assign bar to foo?

hm, it depends on the assumptions of the caller.  I can make an argument for
either returning bar or returning this.getRelatedTarget().  the only usecase I
know of is in YUI where it doesn't matter what's returned.  how about instead I
return the string "relatedTarget is readonly", so if someone happens to try
something like that it'll be more obvious what the problem is.

[MikeSamuel, 2009-11-05 05:56:36]

http://codereview.appspot.com/140051/diff/7/9
File src/com/google/caja/plugin/domita.js (right):

http://codereview.appspot.com/140051/diff/7/9#newcode2968
Line 2968: return void 0;
I think we should stick with assignment assigns, and does not read, so the value
returned is the value assigned regardless of whether the underlying setter
coerces the value to a type or ignores it entirely.

[felix8a, 2009-11-05 22:02:19]

On 2009/11/05 05:56:36, MikeSamuel wrote:
> http://codereview.appspot.com/140051/diff/7/9
> File src/com/google/caja/plugin/domita.js (right):
> 
> http://codereview.appspot.com/140051/diff/7/9#newcode2968
> Line 2968: return void 0;
> I think we should stick with assignment assigns, and does not read, so the
value
> returned is the value assigned regardless of whether the underlying setter
> coerces the value to a type or ignores it entirely.

ok.  new snapshot

[MikeSamuel, 2009-11-05 22:08:46]

http://codereview.appspot.com/140051/diff/5001/5003
File src/com/google/caja/plugin/domita.js (right):

http://codereview.appspot.com/140051/diff/5001/5003#newcode2143
Line 2143: }
Ok, this isn't a setter, so it doesn't need to return a value.

Won't this fail on non-IE browsers, but pass feature detection.

So
  if (myEl.setActive) { myEl.setActive(); }
will fail under DOMita, but wouldn't otherwise.

Can we call focus() if setActive is not supported?

http://codereview.appspot.com/140051/diff/5001/5003#newcode2147
Line 2147: this.node___.hasFocus();
Does this need a return?

And similarly, it will fail on non-IE browsers.

http://codereview.appspot.com/140051/diff/5001/5003#newcode2968
Line 2968: return newValue;
cool

[felix8a, 2009-11-05 22:46:37]

new snapshot

http://codereview.appspot.com/140051/diff/5001/5003
File src/com/google/caja/plugin/domita.js (right):

http://codereview.appspot.com/140051/diff/5001/5003#newcode2143
Line 2143: }
On 2009/11/05 22:08:46, MikeSamuel wrote:
> Ok, this isn't a setter, so it doesn't need to return a value.
> 
> Won't this fail on non-IE browsers, but pass feature detection.
> 
> So
>   if (myEl.setActive) { myEl.setActive(); }
> will fail under DOMita, but wouldn't otherwise.

ah, right.  hm.  how about I sniff for setActive before attaching it to
TameElement.prototype

> Can we call focus() if setActive is not supported?

yeah, though I'm wary of doing that since the behavior is different.

http://codereview.appspot.com/140051/diff/5001/5003#newcode2147
Line 2147: this.node___.hasFocus();
On 2009/11/05 22:08:46, MikeSamuel wrote:
> Does this need a return?

yep, thanks.

[MikeSamuel, 2009-11-05 22:53:32]

LGTM

http://codereview.appspot.com/140051/diff/5001/5003
File src/com/google/caja/plugin/domita.js (right):

http://codereview.appspot.com/140051/diff/5001/5003#newcode2143
Line 2143: }
On 2009/11/05 22:46:37, felix8a wrote:
> On 2009/11/05 22:08:46, MikeSamuel wrote:
> > Ok, this isn't a setter, so it doesn't need to return a value.
> > 
> > Won't this fail on non-IE browsers, but pass feature detection.
> > 
> > So
> >   if (myEl.setActive) { myEl.setActive(); }
> > will fail under DOMita, but wouldn't otherwise.
> 
> ah, right.  hm.  how about I sniff for setActive before attaching it to
> TameElement.prototype
> 
> > Can we call focus() if setActive is not supported?
> 
> yeah, though I'm wary of doing that since the behavior is different.
> 

Ah, I see.  focus() can cause scrolling whereas setActive does not.

http://codereview.appspot.com/140051/diff/5006/5008#newcode2154
Line 2154: };
cool

[felix8a, 2009-11-05 22:58:41]

@r3834