User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 Steps to reproduce: I ran the attached HTML file with Firefox 13 on Windows and OS X. Actual results: Hovering mouse cursor over red circle only causes green color change when cursor in in lower-left quadrant. Other SVG-enabled browsers, including Chrome and Safari detect the hit regardless of quadrant. Expected results: The red circle should turn green regardless of where on the ellipse the mouse cursor touches.

Possibly relevant: http://code.google.com/p/chromium/issues/detail?id=65238

Is this new to Firefox 13? i.e. did it work in Firefox 12?

(In reply to Robert Longson from comment #3) > Is this new to Firefox 13? i.e. did it work in Firefox 12? I haven't tested these specific examples on FF 12, but an application I have showed similar behavior and worked fine on FF12.

Also see the second attachment, which shows the same quadrant specific behavior for the ellipse on the left, and no event detection at all for the (smaller) one on the right. (In reply to rapodaca from comment #0) > Created attachment 631143 [details] > ff-13-svg-bug.html > > User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) > AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 > > Steps to reproduce: > > I ran the attached HTML file with Firefox 13 on Windows and OS X. > > > Actual results: > > Hovering mouse cursor over red circle only causes green color change when > cursor in in lower-left quadrant. > > Other SVG-enabled browsers, including Chrome and Safari detect the hit > regardless of quadrant. > > > Expected results: > > The red circle should turn green regardless of where on the ellipse the > mouse cursor touches.

Would you be willing to find a regression range? https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/ My guess would be that this works /pub/mozilla.org/firefox/nightly/2012/02/2012-02-17-03-12-27-mozilla-central But this does not /pub/mozilla.org/firefox/nightly/2012/02/2012-02-18-03-11-56-mozilla-central Am I right?

Could you give me a download link instead of the /pub/mozilla.org thing? I have no idea what that means. (In reply to Robert Longson from comment #6) > Would you be willing to find a regression range? > https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/ > finding-a-regression-window/ > > My guess would be that this works > /pub/mozilla.org/firefox/nightly/2012/02/2012-02-17-03-12-27-mozilla-central > > But this does not > /pub/mozilla.org/firefox/nightly/2012/02/2012-02-18-03-11-56-mozilla-central > > Am I right?

Follow the instructions here: https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/ and get your downloads from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

I'm not able to find the builds you're asking me to try. If there is a direct link to the exact builds you'd like me to try, I'll be happy to try them. But I'm not seeing where to actually download the two builds you're referring to. (In reply to Robert Longson from comment #8) > Follow the instructions here: > https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/ > finding-a-regression-window/ > > and get your downloads from > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

(In reply to rapodaca from comment #10) > I'm not able to find the builds you're asking me to try. If there is a > direct link to the exact builds you'd like me to try, I'll be happy to try > them. > You need to figure out which builds fail by following the instructions in https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/ I suggested somewhere to start that's all. Follow http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and pick mozilla-central builds from the list. The build date is in the directory name so trying the directory 2012-02-17-03-12-27-mozilla-central would be my suggestion for where to start.

Robert, I think I understand what you're saying and I appreciate your help. Unfortunately, in the nightly directory, I see no directory labeled: '2012-02-17-03-12-27-mozilla-central' Did you mis-type this and mean '2012-05...' instead? I can see a lot of those, but not one directory even starts with '2012-02'. So... I can not even test your suggestion. This is why I'm asking for a direct link. (In reply to Robert Longson from comment #11) > (In reply to rapodaca from comment #10) > > I'm not able to find the builds you're asking me to try. If there is a > > direct link to the exact builds you'd like me to try, I'll be happy to try > > them. > > > > You need to figure out which builds fail by following the instructions in > https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/ > finding-a-regression-window/ > > I suggested somewhere to start that's all. > > Follow http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ and pick > mozilla-central builds from the list. The build date is in the directory > name so trying the directory 2012-02-17-03-12-27-mozilla-central would be my > suggestion for where to start.

Hello :) (In reply to rapodaca from comment #12) > Unfortunately, in the nightly directory, I see no directory labeled: > > '2012-02-17-03-12-27-mozilla-central' Yes, this is quite normal. Older version of Firefox build are stored in a sub directory labeled with the year of each build. If you look closely, you'll see a /2012 directory. Inside that directory, You'll find a /02 directory which contain all the build for February 2012 Here we are it that directory, you'll find : http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/02/2012-02-17-03-12-27-mozilla-central/ Note that each directory is labeled with the date (YYYY-MM-DD) the time (HH-MM-SS) and the build branch. In your case, just focus on "mozilla-central" From there, you have to dig into the different build dates to find the regression window.

I was hoping that the patch in bug 762411 would fix this. Unfortunately it doesn't so the regression range may be different, i.e. not February 17 2012 at all.

Here's the regresion range: 2012-02-10-03-11-50-mozilla-central (http://hg.mozilla.org/mozilla-central/rev/fb81c9a433e4) OK 2012-02-11-03-11-45-mozilla-central (http://hg.mozilla.org/mozilla-central/rev/d71dab82fff4) bad which gives us... http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fb81c9a433e4&tochange=d71dab82fff4 So most likely bug 614732 but possibly bug 725903 or bug 725897

I can build the changesets in that range, but I can't get the resulting Firefox build to actually run. It just keeps aborting as soon as it starts. I don't suppose you'd be willing to see if you fair any better at figuring out which changeset caused the problem on Windows, would you Robert?

http://hg.mozilla.org/mozilla-central/rev/6d5192687c91 OK http://hg.mozilla.org/mozilla-central/rev/a439c947dc99 Bad

Thanks, Robert, that's a huge help. I'll have a fix for this up shortly.

The problem is that the current code is rounding coordinates too early, breaking hit-testing for small objects that have been scaled up.

rapodaca: Thanks for the bug report, and for the nice small testcase! By the way, the SVG team could really do with some help catching problems like this _before_ they reach the release builds. We don't seem to have enough people testing SVG before that stage right now. The Beta builds are very stable (get virtually no changes before release), so if you'd be willing to use Beta or Aurora builds for your day-to-day browsing and report any regressions that you notice, that would be a great help. If you're interested, you can find Beta/Aurora builds here: http://www.mozilla.org/en-US/firefox/channel/

Comment on attachment 632279 [details] [diff] [review] patch The test in this patch has actually failed on at least one Linux box on Try: https://tbpl.mozilla.org/?tree=Try&rev=059849b99a3d I probably need to pull in the hit-testing coordinates slightly, since some small rounding still exists due to our use on nscoord. I'll push a further patch to try later once I see how the current push does on the other machines.

Comment on attachment 632279 [details] [diff] [review] patch Ahh, of course. It's obvious when you see the answer :-)

Seems the problem is that mochitest on Try doesn't run the test with a big enough window. I moved the circle up a bit to get it passing Try.

Comment on attachment 632719 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 614732 User impact if declined: hit-testing broken in some SVG; no workaround Testing completed (on m-c, etc.): passes preexisting and new tests Risk to taking this patch (and alternatives if risky): very low - obviously correct fix String or UUID changes made by this patch: none

Comment on attachment 632719 [details] [diff] [review] patch [Triage Comment] Looks good, low risk fix to a regression from 13, approving.

https://hg.mozilla.org/releases/mozilla-aurora/rev/7df01f66f753 https://hg.mozilla.org/releases/mozilla-beta/rev/58761960aa8a

The red circle turns green regardless of where on the ellipse the mouse cursor touches. Verified fixed on FF 14b9 on Win 7, Ubuntu 12.04 and Mac OS X 10.6.

Verified fixed on FF 15b3 on Win 7, Ubuntu 12.04 and Mac OS X 10.6.