User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150515071002 Steps to reproduce: (on firefox 38.0.0.1 // linux 4.0.4 // Xorg) -> Create a svg with a very small viewbox (~0.1) -> Add an svg-shape with event-handler attached -> fire event a few times (~5-10x) example: -> http://jsfiddle.net/uxnj7emv/3/ -> drag a few times -> drag stops working, mousedown not fired anymore Actual results: events stop firing completely Expected results: events should continue to work

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150513174244 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0 Build ID: 20150524030234 In the current Nightly, if I keep clicking the circle, it's eventually possible to drag it again.

Reproduced on Nightly41.0a1

You must call preventDefault in event handlers. In d3 I think that's written d3.event.sourceEvent.preventDefault();

I don't know exactly if that resolves the problem. The strange behavior is still existent with preventDefault. http://jsfiddle.net/uxnj7emv/8/ also using stopPropagation() http://jsfiddle.net/uxnj7emv/9/ further the bug report states misbehaviour on a small viewbox. Having a regular viewbox (size ~ 1) the behaviour is all right and event handlers remain existent. http://jsfiddle.net/uxnj7emv/7/ Please excuse me for reopening, but i can't see this neither resolved nor invalid. I dont think it is expected behavior and in my eyes it is at the very least inconsistent. (also the example given is very functional in chromium...)

http://jsfiddle.net/uxnj7emv/8/ is not right, see comment 3 for the correct code.

here you go: http://jsfiddle.net/uxnj7emv/10/ http://jsfiddle.net/uxnj7emv/11/ in the end, i don't know if there is a default action to prevent, and even if so, the event handler shouldn't be dropped by accident (randomly)...

That seems to work OK for me. I'm on a Mac rather than Linux though.

(In reply to hiaselhans from comment #6) > here you go: > > http://jsfiddle.net/uxnj7emv/10/ > http://jsfiddle.net/uxnj7emv/11/ > > in the end, i don't know if there is a default action to prevent, and even > if so, the event handler shouldn't be dropped by accident (randomly)... > http://jsfiddle.net/uxnj7emv/10/ easily reproduce the problem for me. > http://jsfiddle.net/uxnj7emv/11/ easily reproduce the problem for me. Tested with Windows7 Nightly41.01 disabled e10s. https://hg.mozilla.org/mozilla-central/rev/b6623a27fa64 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 ID:20150525030205

Open Web Console and Click black circle event not fire

this is not so small viewbox event fire as expected

Regression range with attachment 8610371 [details] Pushlog m-c: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f408698a03f&tochange=85e31a4bdd41 Pushlog m-i: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6d05ace9ed4f&tochange=7ed28c33d727 Regressed by: Bug 762679

(In reply to Robert Longson from comment #7) > That seems to work OK for me. I'm on a Mac rather than Linux though. Just tested on OSX as well and it seems to NOT work using a small viewbox

(In reply to hiaselhans from comment #13) Do you have a retina display?

(In reply to Robert Longson from comment #14) > (In reply to hiaselhans from comment #13) > > Do you have a retina display? No, using a regular macbook air 2013

This is basically the same as Alice's small viewbox testcase, just with the svg dimension changed and the <g> removed. (This is the testcase I wound up working with, so just attaching so I can reference it without caveats.)

This example turned out to be instructive for me regarding hit testing and the use of app units in general, so I wrote it up in some detail in the attached html (where I can reference images). The short version is that when we apply the viewBox transform to the point we're testing (in nsDisplayTransform::HitTest), we convert out of app units and apply the transform, which puts us (in this case) in svg user units with exact values. But we're not at the end of the hitTest pipeline yet, so we round that exact point back into int app units, which is pretty much game over in this case. IF my analysis is right here, it looks to me like it's impossible in firefox to hit test any svg object that doesn't contain a point that's a 1/60 multiple of a point with integer coordinates. i.e. if the object (in user space - i.e. the .01, .007 coordinates in my attached example) doesn't contain a point of the form (x / 60, y / 60), where x and y are integers, then hit testing will always fail. That seems to be a direct consequence of the final hit testing point being passed to nsDisplaySVGGeometry::HitTest (and through the entire display list hit testing pipeline) with nscoord units. I don't think I know how to fix that without changing display list hit testing's use of app units (nsRect) throughout... I haven't traced it through, but I suspect that in the original reported testcase, sometimes you move the circle and the new location contains a 1/60 point, other times you move the circle and the new location contains no such points, and then you can no longer move.

Also note from the description in the explanation attachment that at similar scales on similar svgs we can get successful hit testing outside the bounds of the object in question - that's because (or should be because - I haven't tested it on any actual examples in the debugger) big blocks of css pixel space are getting mapped down to a single point in svg user space (as the colored blue, red, green, and yellow blocks in that explanation). If such a block happens to map down to a 1/60 point that _does_ lie inside the object in svg user space, then the entire pixel block will register as hitting, whether the click actually occurred within the onscreen visible region of the object or not. I'm seeing that in the larger rectangle in bug 1310625 for example: the click region on the left side of the rectangle extends to the left outside its border; on the right side of the rectangle the right portion isn't clickable at all.