SVG Ellipse Hit Detection Fails in Two Simple Examples

RESOLVED FIXED in Firefox 14

Status

()

Core
SVG
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: rapodaca, Assigned: jwatt)

Tracking

(Depends on: 1 bug, {regression})

13 Branch
mozilla16
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox13 affected, firefox14 verified, firefox15 verified, firefox16 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Comment 1

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

Updated

5 years ago
Component: Untriaged → SVG
Product: Firefox → Core
QA Contact: untriaged → general

Updated

5 years ago
Attachment #631143 - Attachment mime type: text/plain → text/html
(Reporter)

Updated

5 years ago
Summary: SVG Ellipse Hit Detection Only Occurs When Mouse Cursor in Lower Left Quadrant → SVG Ellipse Hit Detection Fails in Two Simple Examples
(Reporter)

Comment 2

5 years ago
Created attachment 631156 [details]
Two examples, one showing quadrant-specific hit detection, the other showing none at all.

Comment 3

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

Updated

5 years ago
Attachment #631156 - Attachment mime type: text/plain → text/html
(Reporter)

Comment 4

5 years ago
(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.
(Reporter)

Comment 5

5 years ago
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

5 years ago
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?

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 7

5 years ago
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 8

5 years ago
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/

Updated

5 years ago
Duplicate of this bug: 762847
(Reporter)

Comment 10

5 years ago
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

5 years ago
(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.
(Reporter)

Comment 12

5 years ago
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.

Comment 14

5 years ago
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

5 years ago
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

Updated

5 years ago
Keywords: regression
(Assignee)

Comment 16

5 years ago
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 17

5 years ago
http://hg.mozilla.org/mozilla-central/rev/6d5192687c91 OK
http://hg.mozilla.org/mozilla-central/rev/a439c947dc99 Bad
Blocks: 614732
(Assignee)

Comment 18

5 years ago
Thanks, Robert, that's a huge help. I'll have a fix for this up shortly.
(Assignee)

Comment 19

5 years ago
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.
Assignee: nobody → jwatt
Status: NEW → ASSIGNED
Attachment #632279 - Flags: review?(longsonr)
(Assignee)

Comment 20

5 years ago
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/
(Assignee)

Comment 21

5 years ago
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

5 years ago
Comment on attachment 632279 [details] [diff] [review]
patch

Ahh, of course. It's obvious when you see the answer :-)
Attachment #632279 - Flags: review?(longsonr) → review+
(Assignee)

Updated

5 years ago
status-firefox14: --- → affected
status-firefox15: --- → affected
status-firefox16: --- → affected
(Assignee)

Comment 23

5 years ago
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.
Attachment #632279 - Attachment is obsolete: true
Attachment #632719 - Flags: review+
(Assignee)

Updated

5 years ago
status-firefox13: --- → affected
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/13f46ad244fc
Flags: in-testsuite+
Keywords: checkin-needed
Target Milestone: --- → mozilla16
https://hg.mozilla.org/mozilla-central/rev/13f46ad244fc
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
status-firefox16: affected → fixed
(Assignee)

Updated

5 years ago
OS: Mac OS X → All
Hardware: x86 → All
(Assignee)

Comment 26

5 years ago
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
Attachment #632719 - Flags: approval-mozilla-beta?
Attachment #632719 - Flags: approval-mozilla-aurora?
Comment on attachment 632719 [details] [diff] [review]
patch

[Triage Comment]
Looks good, low risk fix to a regression from 13, approving.
Attachment #632719 - Flags: approval-mozilla-beta?
Attachment #632719 - Flags: approval-mozilla-beta+
Attachment #632719 - Flags: approval-mozilla-aurora?
Attachment #632719 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/7df01f66f753
https://hg.mozilla.org/releases/mozilla-beta/rev/58761960aa8a
status-firefox14: affected → fixed
status-firefox15: affected → fixed
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.
status-firefox14: fixed → verified
Verified fixed on FF 15b3 on Win 7, Ubuntu 12.04 and Mac OS X 10.6.
status-firefox15: fixed → verified

Updated

2 years ago
Depends on: 1167959
You need to log in before you can comment on or make changes to this bug.