Hi all, I've been working on fixing issues #708<https://prototype.lighthouseapp.com/projects/8886/tickets/708-mouseentermouseleave-events-have-no-relatedtarget-in-ie>and #865<https://prototype.lighthouseapp.com/projects/8886/tickets/865-mouseenterleave-fails-in-firefox-35-under-certain-conditions>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-mouseentermouseleave-events-have-no-relatedtarget-in-ie>). 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-mouseenterleave-fails-in-firefox-35-under-certain-conditions>). (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
