javascripthtmlcsssvgsvg-transforms

weird rendering of / event handling on transformed svg children in Firefox


So, I have an SVG overlay which has a polygon drag handles for resizing a box around areas of a scalable image. In Chrome, everything is working swimmingly, but in Firefox is all falls apart in ways that are hard to describe.

Specifically, in Firefox (tested in 54 and 57), the polygon and drag-handles visibly render in the right place, but are not accessible by pointer events. I have played around with the pointer-events CSS rule, but that doesn't appear to be an issue (or at least not the obvious, primary issue).

I am able to interact with the drag handles in Firefox if I increase the r value of the drag handles or the stroke-width beyond a certain threshold.

I have created a codepen demonstrating the behavior.

In this example I have increased the size of the top-left, center-left, and bottom-left (or their stroke). The top and center left handles will demonstrate a hover effect, whereas the bottom-left does not. If I bumped the bottom left r up a notch, it will be hoverable. The rest of the handles are not hoverable in FireFox. There is also a rotate-handle which is not as large as the others, but is hoverable anyway. Again, everything works great in Chrome.

What's even weirder is that the hoverable/eventable space is usually not right over the rendered element. It's often, a little above, below, or off to the side. For instance, the hoverable space over the top left handle is a little further up and to the left of the handle.

I thought initially this might have to do with Firefox's issues around transform-origin, but after a fair amount of tinkering, I'm not sure it's relevant here; especially with the object visually rendering exactly where it's supposed to.

Totally stumped.


Solution

  • For anyone else seeing this at a later date, @ccprog was definitely on the right track. After discussing with Mozilla support, they indicated that large decimal values were above C++ precision levels, and that instead of scaling on the parent and letting the scale trickle down, just applying the scale directly to the group members fixed the rendering issue in Firefox.