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)
Core
SVG
Tracking
()
NEW
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).
Test case attached with description in case the linked page disappears.
Comment 2•14 years ago
|
||
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.
Comment 4•14 years ago
|
||
You may well be right with your second paragraph.
Updated•8 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•8 years ago
|
||
I've also repro'd this on OS X, so Platform should probably be changed to All.
Updated•8 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
Updated•8 years ago
|
Has STR: --- → yes
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•