577785 - SVG mouseOut event not always firing on dynamic svg:use element

Status: NEW

(Core :: SVG, defect)

Description

[Alex Haan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.7) Gecko/20100701 Firefox/3.6.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.7) Gecko/20100701 Firefox/3.6.7

Moving the mouse pointer quickly over multiple svg:use elements that changes their xlink:href on mouseOver and mouseOut might not always trigger a mouseOut event for the svg:use elements.

Reproducible: Always

Steps to Reproduce:
1. Create a set of svg:use elements pointing to a defined svg (rectangle, path, etc.) element.
2. Setup mousevent listeners for mouseOver and mouseOut for all these events.
3. In the mouseOver event point the element's xlink:href to a different defined svg element (different color).
4. In the mouseOut event point the element's xlink:href back to the first defined element.
5. Move the mouse quickly over the rectangles.
Actual Results:  
Some svg:use elements will stay in the second color, clearly no mouseOut event was fired for this element.

Expected Results:  
All events should fired a mouseOut event.

This redefining of the element causes a second mouseOver event to be triggered, which is understandable and can be filtered out based on currentTarget and relatedTarget event properties.

Sometimes no mouseOut event will be triggered for some element. Actually, this element will only have had one mouseOver event fired.

I guess before the element is changed (causing the second event), the mouse pointer has already left the element. Shouldn't then at least the mouseOut still be triggered?

In some cases an element only shows one mouseOver and one mouseOut event though, which would match a too quick movement like before. That would then mean that the previous issue is an actual bug?


This happened both in Firefox 3.6.7 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.7) Gecko/20100701 Firefox/3.6.7) as well as Firefox 4.0b2pre (Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100707 Minefield/4.0b2pre). This also happens in Google Chrome (5.0.375.99), but not in Opera (Opera/9.80 (Windows NT 6.1; U; en) Presto/2.6.30 Version/10.60) (though that has its own different issues).

Comment 1

[Alex Haan]

Attachment: test case

Test case attached with description in case the linked page disappears.

Comment 2

[Robert Longson [:longsonr]]

use creates a copy of the href data and shows it to you. When you change the href it destroys the copy and asynchronously creates a new one. Thus if you do stuff quickly enough you can move the mouse out before the async creation of the new copy. I'm not sure we're likely to fix this.

Comment 3

[Alex Haan]

I understand the problem better now you say the new copy is created asynchronously.

Still sometimes there is one mouseOver event and a mouseOut event. Where normally there are two mouseOver events and a mouseOut event. Though, I guess in those cases the mouseOut is perhaps triggered on the first copy, before it is even destroyed in the mouseOver event handler yet.

I already planned on making a work around for it though.

Comment 4

[Robert Longson [:longsonr]]

You may well be right with your second paragraph.

Comment 6

[Chris Rebert]

I've also repro'd this on OS X, so Platform should probably be changed to All.

Comment 8

[jbstrater]

Sorry I didn't notice the duplication, but the titles are quite different, and this didn't show up in my search - different but related events.

This bug is 14 years old. What are it's chances of getting fixed in the foreseeable future?

Comment 9

[jbstrater]

Is there a workaround? I suppose I could check for the proper conditions, then focus the element and call the click event handler. Any other suggestions?

Comment 10

[Robert Longson [:longsonr]]

It's pretty hard to fix, or we would likely have fixed it by now. I was trying to rewrite use elements in bug 738574 but I just can't quite get that to work. Even then I don't know whether that would have fixed this issue.

Alternatively, this is all open source so if you want to work on it yourself, have at it, just like me. I don't think this is likely to be the ideal first bug to tackle though.

We could be smarter about updates i.e. compare the before and after shadow DOMs as we do with display lists (maybe reuse some display list logic). And then not reclone everything when the href changes.

Workaround - stop using use elements. They are almost always misused - you're almost always better off just creating copies yourself rather than having use element do your cloning for you.

Comment 11

[jbstrater]

Yea, I don't think this would be a good first bug-fix attempt for me in this arena. Stop using <use> elements is a novel idea for me in this context. My next attempt at a workaround will be to set pointer-events="none" for the svg element and to add an invisible <rect> covering the full viewBox that handles all the events. That way it shouldn't matter what the <use> element does, as it will never be an event target.

If that fails then I'll abandon <use> and start cloning, adding, and removing elements on the fly. But it strikes me that I might end up with the same problem in this case. Swapping the element for another element could cause the same loss of focus if that element is the event target or currentTarget. I'll post my findings here, unless you'd prefer that I don't.

Comment 12

[Robert Longson [:longsonr]]

Maybe post your findings in your bug, that way you won't disturb people who only care about this one.