Open Bug 577785 Opened 14 years ago Updated 1 year ago

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

Categories

(Core :: SVG, defect)

defect

Tracking

()

People

(Reporter: alexhaan, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: testcase)

Attachments

(1 file)

3.47 KB, application/xhtml+xml
Details
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).
Attached file test case
Test case attached with description in case the linked page disappears.
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.
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.
You may well be right with your second paragraph.
Blocks: 1230801
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've also repro'd this on OS X, so Platform should probably be changed to All.
OS: Windows 7 → All
Hardware: x86_64 → All
Has STR: --- → yes
Keywords: testcase
Severity: normal → S3
Depends on: 738574
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: