I have this for IE in my event manager:
event.relatedTarget =
event[(event.target == event.fromElement ? 'to' : 'from') +
'Element'];
other browsers would never walk through the above code, they should
not even if just for an initial conditional forking based on browsers.
The forking of IE methods from other browsers (especially for event
handling, but also for other low level parts) should be done at load
time (lazy definition), so no extra overhead is inferred to correctly
behaving browsers and alternative paths are maintained for buggy or
inferior browsers...
I agree that the Event ".relatedTarget" property may have some
relevance in specific mouse/keyboard related task.
Diego
On Dec 6, 8:32 am, Simon Charette <charett...@gmail.com> wrote:
> Hi all, I've been working on fixing issues
> #708<https://prototype.lighthouseapp.com/projects/8886/tickets/708-mouseen...>and
> #865<https://prototype.lighthouseapp.com/projects/8886/tickets/865-mouseen...>while
> reducing overhead caused by the current fix for those inconsistencies.
>
> On master branch, IE doesn't pass functional test for mouseleave because we
> rely on event.relatedTarget which is not set on the event returned by
> Prototype
> (#708<https://prototype.lighthouseapp.com/projects/8886/tickets/708-mouseen...>).
> Another issue is caused by this Firefox < 3.6
> bug<https://bugzilla.mozilla.org/show_bug.cgi?id=463644>which is
> not<http://github.com/charettes/prototype/blob/master/src/dom/event.js#L344>handled
> correctly <http://dev.jquery.com/browser/trunk/jquery/src/event.js#L511> in
> the current mouse(enter|leave) simulation implementation
> (#865<https://prototype.lighthouseapp.com/projects/8886/tickets/865-mouseen...>).
> (We should *break* in the catch block in order to dispatch the event when we
> mouse(over|out) observed element parent scrollbars).
>
> Solving the *detection* part of the mouse(enter|leave) implementation is
> easy enough (breaking does it), however patching the XULElement as
> relatedTarget in mouse(over|out) one is tricky since the relatedTarget is
> readonly and thus cannot be reassigned a correct value. I had a first quick
> attempt at this
> problem<http://github.com/charettes/prototype/commits/events>but then
> I realised it never really fixed the main issue because
> mouse(over|out) events were still able to dispatch erronous relatedTarget.
>
> I came out with what seems to be a viable
> solution<http://github.com/charettes/prototype/commits/event-related-element>that
> introduce a new method to the Event api but reduce the overhead on IE
> (_relatedTarget) and wrap the issues in a thin abstraction layer. I also
> adapted the functional test and added a new one to test the scrollbar issue
> on Firefox.
>
> I'm aware that this solution might cause problems to the few people that
> were relying on the* *undocumented addition of the relatedTarget property to
> event on IE but IMO performance gains and the fact that this method offers a
> way to ensure cross-browser compatibility are worth the introduction of this
> method in a future release (1.7+).
>
> Let me know what you guys think.
>
> Simon
>
> ps: The method name could probably be more concise and the documentation
> more elaborated, feel free to suggest alternatives.
--
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
