Last Comment Bug 762679 - SVG Ellipse Hit Detection Fails in Two Simple Examples
: SVG Ellipse Hit Detection Fails in Two Simple Examples
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: SVG (show other bugs)
: 13 Branch
: All All
: -- normal (vote)
: mozilla16
Assigned To: Jonathan Watt [:jwatt]
:
Mentors:
: 762847 (view as bug list)
Depends on: 1167959
Blocks: 614732
  Show dependency treegraph
 
Reported: 2012-06-07 14:33 PDT by rapodaca
Modified: 2015-05-26 00:20 PDT (History)
7 users (show)
ryanvm: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
verified
verified
fixed


Attachments
ff-13-svg-bug.html (1.29 KB, text/html)
2012-06-07 14:33 PDT, rapodaca
no flags Details
Two examples, one showing quadrant-specific hit detection, the other showing none at all. (1.25 KB, text/html)
2012-06-07 14:51 PDT, rapodaca
no flags Details
patch (4.15 KB, patch)
2012-06-12 09:06 PDT, Jonathan Watt [:jwatt]
longsonr: review+
Details | Diff | Review
patch (4.15 KB, patch)
2012-06-13 08:58 PDT, Jonathan Watt [:jwatt]
jwatt: review+
lukasblakk+bugs: approval‑mozilla‑aurora+
lukasblakk+bugs: approval‑mozilla‑beta+
Details | Diff | Review

Description rapodaca 2012-06-07 14:33:23 PDT
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.
Comment 1 rapodaca 2012-06-07 14:43:41 PDT
Possibly relevant: http://code.google.com/p/chromium/issues/detail?id=65238
Comment 2 rapodaca 2012-06-07 14:51:26 PDT
Created attachment 631156 [details]
Two examples, one showing quadrant-specific hit detection, the other showing none at all.
Comment 3 Robert Longson 2012-06-07 14:52:10 PDT
Is this new to Firefox 13? i.e. did it work in Firefox 12?
Comment 4 rapodaca 2012-06-07 14:53:42 PDT
(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.
Comment 5 rapodaca 2012-06-07 14:55:22 PDT
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.
Comment 6 Robert Longson 2012-06-07 14:57:08 PDT
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?
Comment 7 rapodaca 2012-06-07 16:18:59 PDT
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?
Comment 9 Robert Longson 2012-06-08 03:44:45 PDT
*** Bug 762847 has been marked as a duplicate of this bug. ***
Comment 10 rapodaca 2012-06-08 12:32:12 PDT
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/
Comment 11 Robert Longson 2012-06-08 12:43:57 PDT
(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.
Comment 12 rapodaca 2012-06-08 12:49:01 PDT
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.
Comment 13 Jeremie Patonnier :Jeremie 2012-06-08 15:00:33 PDT
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.
Comment 14 Robert Longson 2012-06-09 11:06:40 PDT
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.
Comment 15 Robert Longson 2012-06-10 00:53:11 PDT
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
Comment 16 Jonathan Watt [:jwatt] 2012-06-10 10:49:58 PDT
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?
Comment 18 Jonathan Watt [:jwatt] 2012-06-12 05:44:14 PDT
Thanks, Robert, that's a huge help. I'll have a fix for this up shortly.
Comment 19 Jonathan Watt [:jwatt] 2012-06-12 09:06:31 PDT
Created attachment 632279 [details] [diff] [review]
patch

The problem is that the current code is rounding coordinates too early, breaking hit-testing for small objects that have been scaled up.
Comment 20 Jonathan Watt [:jwatt] 2012-06-12 09:26:17 PDT
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 21 Jonathan Watt [:jwatt] 2012-06-12 10:17:14 PDT
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 22 Robert Longson 2012-06-12 11:31:04 PDT
Comment on attachment 632279 [details] [diff] [review]
patch

Ahh, of course. It's obvious when you see the answer :-)
Comment 23 Jonathan Watt [:jwatt] 2012-06-13 08:58:52 PDT
Created attachment 632719 [details] [diff] [review]
patch

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 24 Ryan VanderMeulen [:RyanVM] 2012-06-13 18:18:03 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/13f46ad244fc
Comment 25 Ed Morley [:emorley] 2012-06-14 02:45:10 PDT
https://hg.mozilla.org/mozilla-central/rev/13f46ad244fc
Comment 26 Jonathan Watt [:jwatt] 2012-06-14 05:59:59 PDT
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 27 Lukas Blakk [:lsblakk] use ?needinfo 2012-06-15 15:38:52 PDT
Comment on attachment 632719 [details] [diff] [review]
patch

[Triage Comment]
Looks good, low risk fix to a regression from 13, approving.
Comment 29 Paul Silaghi, QA [:pauly] 2012-06-28 06:55:19 PDT
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.
Comment 30 Paul Silaghi, QA [:pauly] 2012-08-03 04:40:48 PDT
Verified fixed on FF 15b3 on Win 7, Ubuntu 12.04 and Mac OS X 10.6.

Note You need to log in before you can comment on or make changes to this bug.