Mouse Events are not delivered at all anymore when inside an SVG a "Use" is removed from the DOM - by Sebastian Mueller

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


ID 796745 Comments
Status Closed Workarounds
Type Bug Repros 6
Opened 8/8/2013 2:41:52 AM
Access Restriction Public

Description

In IE 11 Preview under Windows 7, mouse events are not delivered to the page anymore at all after a SVG use element which has was under the mouse is removed from the
DOM in the event listener in response to a mouse click.
Sign in to post a comment.
Posted by Cajus Pollmeier on 12/8/2015 at 1:13 AM
Having multiple IE 11 versions under different windows versions with different bugs is a total nightmare. A browser should be up to date (not only for security) on all platforms.
Posted by Microsoft on 9/24/2015 at 11:19 AM
Thank you for the feedback. This issue appears to have been fixed\no repro in Microsoft Edge and IE 11 Windows 10. We're not presently working on feature bugs in Internet Explorer outside of security-related issues.
Best Regards,
The Microsoft Edge Team
Posted by Sebastian Mueller on 9/23/2015 at 3:29 AM
I made an interesting observation: Once IE is int that "locked-up state", switching to another application (tabs don't work either) and back to IE, some functioality starts working again: E.g. mouse wheel events are delivered correctly to the page and the Developer Tools can be used again. "Just" regular mouse events are not processed anymore.

A simple workaround to this bug is declaring a css rule like this:

svg use { pointer-events:none; }

This of course also disables any mouse events (CSS-based and programmatic), as well as interferes with the hit test order of the other elements in the SVG DOM.
Posted by Renji Sam on 4/21/2015 at 3:23 AM
This bug has caused us a few issues on IE11 on windows 7. Microsoft, is there any plan on fixing this issue for customers on IE11 on Win7? I believe older versions of IE are coming up to end of life soon, so this will soon start to be a problem with our clients.
Posted by Sebastian Mueller on 11/16/2014 at 11:51 PM
Since many of our customers are affected by this problem and it doesn't look as if the IE team cares for Windows 7 users anymore, I am posting the workaround that we implemented in our application for this:

We basically carefully made each SVG "use" element mouse-invisible by setting the CSS pointer-events property to none:

<use style="pointer-events: none;" .../>

This prevents IE11 on Win7 from probably keeping an internal reference to the use element once the mouse is clicked on the element and then virtually freezing when that use element is removed from the DOM before the mouse is released. I believe IE11 keeps a reference to that DOM element and since it never receives a mouse up event on that event, it internally continues to redispatch all mouse events to that SVG element.

This solution is not very nice, because it basically prevents all mouse interaction with the elements in the use: so you cannot use CSS effects, get raw mouse events, etc. anymore. For our library this is not a problem since we usually do not rely on the low-level events at all and use our own event system, which is not affected by that problem.

So if you want to "crash" IE11 on Win7 simply trick the user into clicking on an SVG use element (as an overlay to the page maybe so it's *any* click) and on click remove that use element. The browser will appear to be frozen from there on.
Posted by Craig Waddington on 3/10/2014 at 5:37 AM
We have discovered this bug affects our product running on IE11 on Windows 7. In our case, the window becomes unresponsive to mouse events when an SVG USE element is ordered to the top of all others by using the code:

el.parentNode.appendChild(el);

where el is a USE element.

This can be verified by changing the jsfiddle http://jsfiddle.net/QbW2b/ to use appendChild instead of removeChild. (replace "rect.parentNode.removeChild(rect);" with "rect.parentNode.appendChild(rect);")
Posted by Maros Urbanec on 1/2/2014 at 10:21 PM
This issue effectively prevents the usage of USE elements as targets of click events in Single Page Applications.

Imagine you have a graph/document visualization containing many nodes (so it makes sense to utilize USE elements) and each of these elements can point to a different screen in an SPA when clicked.
The visualization might be swept when moving to a new screen, making the whole browser tab unresponsive.
Posted by Sebastian Mueller on 10/23/2013 at 5:58 AM
IE 11 has been released officially for Win8.1 and that bug does not affect that specific version, which is good.
However we are afraid that once IE11 will be released for Windows 7 users, this bug will not have been addressed. We would have to create nasty complicated workarounds in our software library in order to be able to still recommend IE for our Windows 7 users and to be able to recommend our customers (software developers) to tell their users that they can use IE.
Can you confirm that this bug will be addressed for the Windows 7 release?
Otherwise our demos will make the IE browser look crashed (were "just" the mouse input is broken), pretty much immediately:
http://live.yworks.com/yfiles-for-html/1.1/demos/Complete/demo.yfiles.graph.collapse/index.html (clicking directly on the expand/collaps icons triggers the issue).
http://live.yworks.com/yfiles-for-html/1.1/demos/Complete/demo.yfiles.layout.modules/index.html (dragging a node out of the viewport (dragging the mouse from an unselected node to the bottom right and then right clicking the mouse twice also triggers the issue).
Posted by Microsoft on 9/25/2013 at 10:46 AM
Thank you for your feedback.
This is a great bug! Unfortunately, we are not able to address this feedback in our upcoming release. We will consider your feedback for a future release. At this time we will keep this feedback active and will update as needed. Every piece of feedback we receive is important to us and helps us improve the quality of Internet Explorer.
We continue to welcome more feedback, so please don't hesitate to report other ways that we can improve Internet Explorer.
Best regards,
The Internet Explorer Beta Team
Posted by Microsoft on 8/8/2013 at 11:33 AM
Thank you for your feedback. We will be investigating this issue further.

Best regards,

The Internet Explorer Team