Scaled SVG content can get the wrong metrics and poison the cache

RESOLVED FIXED

Status

()

Core
SVG
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Duncan Loveday, Assigned: longsonr)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 4 obsolete attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031806 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031806 Minefield/3.0b5pre

I'm seeing an intermittent problem where firefox gets completely confused about what is under the mouse - onclick events not firing or being routed to the wrong elements, mouseover/mouseout events not firing, hyperlinks not working or wrong hyperlinks activating. As I move the mouse pointer around the screen the status bar changes to show the hyperlinks which will activate on a click but they're not the ones under the mouse. As if the image it thinks is there is at a different offset and/or scale.

When in this state, if I zoom in or out then everything starts working. But zoom back to the original scale and the problem returns.

Regrettably I can NOT reproduce in a small test case - only my real app which is far too complex to server as a test case. And even there that application the problem is intermittent. I think there might be some sort of race condition with page load events vs zoom events or something like that. My app zooms the image as part of page load. I'll keep trying but no luck so far.

The only thing I have for definite is the regression range which is between the 18/3/2008 06 nightly and the 19/3/2008 05 nightly.

Reproducible: Sometimes

Steps to Reproduce:
No test case yet
(Reporter)

Updated

10 years ago
Keywords: regression

Updated

10 years ago
Version: unspecified → Trunk
(Assignee)

Comment 1

10 years ago
The date range corresponds to the check in for bug 392233
(Reporter)

Comment 2

10 years ago
Would there be any point in me providing a hugely complex test case so that at least you guys could see the effect ? I'm getting nowhere with minimal test cases.

Otherwise, if bug 392233 is a suspect is there a way I could get a build with just that change backed out to see if that is the culprit ?
(Assignee)

Comment 3

10 years ago
I think your best bet is to use a prior to that date nightly.
(Assignee)

Comment 4

10 years ago
It's possible that the patch in bug 423998 will fix things for you.
(Reporter)

Comment 5

10 years ago
(In reply to comment #3)
> I think your best bet is to use a prior to that date nightly.
> 
Robert - I was looking for a way of confirming specifically whether that one change you mention is what's causing the issue. I know already that the previous day's build does not have the issue but I assume there will be loads of other differences in the same time range.

Looking at the bugs you've mentioned it might be that I need to include text in order to reproduce the issue - I'll see if I can confirm that removing text from my real app makes the problem go away. If so, I'll have another crack at a test case with some text in it. As always, thanks for the info.
(Reporter)

Comment 6

10 years ago
Created attachment 312319 [details]
SVG test case
(Reporter)

Comment 7

10 years ago
Created attachment 312321 [details]
HTML test case

I have a test case for at least part of this issue now. To reproduce

1) Open the HTML attachment
2 [review]) Click on any of the rectangles or text. Notice the alert reports "y=4" for all of them when in fact they should all have different y values.
3) Clock to the right of the rectangle area - notice that a hyperlink is activated when none is present under the mouse
4) Also notice that the mouse pointer and status bar show values that are not the hyperlinks that are under the mouse.
(Reporter)

Comment 8

10 years ago
Guys - the test HTML I've attached renders at a completely different scale when it's live in the bug as compared to when opened as a local file. As a result, opening the live file doesn't reproduce the issue. To reproduce, save the HTML and SVG examples, change the link in the HTML to point to the locally-stored SVG and File->open to open the HTML in Firefox.

It must be my fault but I just can't see why the scaling is different when opened as a local file vs over HTTP.
(Reporter)

Comment 9

10 years ago
Created attachment 312374 [details]
HTML test case
Attachment #312321 - Attachment is obsolete: true
(Reporter)

Comment 10

10 years ago
Attached a file that does seem to work live in the bug and recreate the problem I'm seeing.

The original, now-obsoleted test case seems to be rendered at different scales on different PCs, different versions of firefox and when loaded as HTTP:// or FILE:// but that's a separate issue.
(Reporter)

Comment 11

10 years ago
Filed bug 425826 for the different scaling observerd with file:// vs https:// although I can only reproduce that on one of my two PCs. Definitely unrelated to this bug - didn't regress at the same time (if indeed it is a regression).
Keywords: testcase
(Assignee)

Updated

10 years ago
Blocks: 392233
(Reporter)

Comment 12

10 years ago
(In reply to comment #8)
(In reply to comment #10 para 2)
(In reply to comment #11)

The thing about scaling being different in file:// vs https:// is a red herring - however to reproduce this bug it's important NOT use page zooming as it is dependent on the scale things are drawn at. Press ctrl-0 to reset page zoom for the bugzilla domain.
(Assignee)

Comment 13

10 years ago
Created attachment 312680 [details]
simpler testcase

we seem to get the bounding box right but the hittest area for text is too big as therefore is the covered region. The mouse active area goes to the top of the screen rather than just being over the text
(Assignee)

Updated

10 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Updated

10 years ago
Attachment #312680 - Attachment is obsolete: true
(Reporter)

Comment 14

10 years ago
I think maybe this ought to be a blocker. My app is pretty much unusable since this bug appeared
Flags: blocking1.9?
(Assignee)

Comment 15

10 years ago
Created attachment 312910 [details]
ok testcase
(Assignee)

Comment 16

10 years ago
Created attachment 312911 [details]
this one doesn't work.
(Assignee)

Comment 17

10 years ago
The difference between the ok testcase and the non-working one is that the viewBox for the former is "0 0 2258 2258", whereas the viewBox for the latter is "0 0 2259 2259".

The area the mouse changes to a link covers just the text in the ok testcase whereas in the non-working testcase, the link area goes all the way to the top of the screen. Somehow the y and/or height calculation has overflowed.
(Reporter)

Comment 18

10 years ago
For me, they both behave the same - broken but not in the way you describe. To get the alert I have to click in the left portion of the text, anywhere up to the "k" of "click" in "click me". With these tests I don't see the hyperlink area extending to the top of the screen.

I do see the hyperlink area extending to the top of the screen with this attachment https://bugzilla.mozilla.org/attachment.cgi?id=312680.
(Assignee)

Comment 19

10 years ago
Resolution/screen size/browser window size dependent perhaps? Does increasing the viewBox size beyond 2259 break things eventually?
(Assignee)

Updated

10 years ago
Attachment #312910 - Attachment is obsolete: true
(Assignee)

Updated

10 years ago
Attachment #312911 - Attachment is obsolete: true
(Assignee)

Comment 20

10 years ago
Hmm, both new testcases work now that I've restarted my browser.
(Assignee)

Comment 21

10 years ago
(In reply to comment #18)
> I do see the hyperlink area extending to the top of the screen with this
> attachment https://bugzilla.mozilla.org/attachment.cgi?id=312680.
> 

For me, sometimes I run the browser and that works OK, and sometimes it doesn't.
(Reporter)

Comment 22

10 years ago
Yeah, drives you mad doesn't it ? Just now I observed both your last 2 attachments working correctly and the attachment at  https://bugzilla.mozilla.org/attachment.cgi?id=312680 not responding to clicks at all. Now I'm back to having to click on the left portion of the text.

In my real app I also observed successive runs of the same thing showing the bug and then not showing it.

Do you think there's something time dependent here ? I'm reminded slightly of bug 380516. Boris Zbarsky explained in comment 25 that reflow events can race with page load to give intermittent behaviours.
(Reporter)

Comment 23

10 years ago
Just now the attachment at https://bugzilla.mozilla.org/attachment.cgi?id=312680 responded to clicks in an area above the left portion of the rectangle extending upwards but not all the way to the top of the screen. About one third of the way up. You blink and something different happens.
(Assignee)

Comment 24

10 years ago
When it goes wrong the cause is that cached font metric information is incorrect. Since it is cached, once it is wrong it stays wrong till the browser restarts.

I suspect an uninitialised variable somewhere rather than something time dependent.
(Reporter)

Comment 25

10 years ago
Got it.

I'm a bit wary of making any definite claims about this bug because no sooner do I post a comment than something different happens, BUT I just started a new browser three times with the window maximised and the attachment https://bugzilla.mozilla.org/attachment.cgi?id=312680 didn't respond to clicks which is correct behaviour I think. Then I did the same thing with the window about half height and half width and all three times I got the effect I described in comment #23. Then I went back to maximised and it got correct behaviour.
(Reporter)

Comment 26

10 years ago
....but then I repeated all that with some of the other attachments and got wrong the bug all the time.
-'ing this as we really need a consistently reproducible test case.  Please
re-nom once we have one.

Flags: blocking1.9? → blocking1.9-
(Reporter)

Comment 28

10 years ago
(In reply to comment #27)
> -'ing this as we really need a consistently reproducible test case.  Please
> re-nom once we have one.
> 

It seems to be in the nature of this bug that it's hard to reproduce all the time but nonetheless the HTML attachment reproduces this consistently for me, so re-nominating.
Flags: blocking1.9- → blocking1.9?
What happens when you back out bug 392233? 
(Assignee)

Comment 30

10 years ago
Created attachment 313149 [details] [diff] [review]
patch

If you display the html testcase first then my testcases show the issue.
If you don't display the html testcase first then my testcases don't show any issues. 

In the html testcase the cairo ctm is 0.01499 when gfxFont::SetupGlyphExtents is called. The cairo extents values come out scaled by the inverse of this so you get really big extents in gfxFont::Measure which are never scaled back again.

Are there any other tests I can run anywhere? Non-svg tests perhaps?
Attachment #313149 - Flags: review?(roc)
Comment on attachment 313149 [details] [diff] [review]
patch

You could manually check the testcases in bug 96041
Attachment #313149 - Flags: superreview+
Attachment #313149 - Flags: review?(roc)
Attachment #313149 - Flags: review+
Assignee: nobody → longsonr
(Assignee)

Comment 32

10 years ago
Comment on attachment 313149 [details] [diff] [review]
patch

I see no difference in the testcases but I think html is always going to have an identity ctm unless it's in an SVG foreignObject, examining the testcases shows an identity ctm in all those cases.

Hopefully fairly low risk as I think it's hard to get html with a non-identity transformation matrix. 

Zooming doesn't change the transformation matrix for instance.
Attachment #313149 - Flags: approval1.9?
(Reporter)

Comment 33

10 years ago
Robert, after running the HTML test case I too see a the behaviour of your attachments changing at the 2258/2259 boundary. But what's worring me is that I also see both of the attachments misbehaving in a different way when I restart the browser and don't run the HTML test case. I see the effect I described in comment 18. Do you see that also ?
(Assignee)

Comment 34

10 years ago
Yes, but that's not this bug. Needs a new one raising.
(Reporter)

Comment 35

10 years ago
Filed 426738. I'll try to get a regression range.
(Reporter)

Updated

10 years ago
Blocks: 426738
(Reporter)

Comment 36

10 years ago
(In reply to comment #32)
> 
> Zooming doesn't change the transformation matrix for instance.
> 

For me, if I start with a new browser, reset my zoom state with ctrl-0 and click on my original attachment https://bugzilla.mozilla.org/attachment.cgi?id=312321, it behaves itself but if I zoom out four times with ctrl-- it starts misbehaving.
(Assignee)

Updated

10 years ago
No longer blocks: 426738
(Assignee)

Updated

10 years ago
Depends on: 426738
What's the risk associated with taking this patch?  Are the tests we have good enough to test for such regressions?  Comment #30 seems to imply we're not sure of regressions here.  Approval pending addressing these concerns.  
Comment on attachment 313149 [details] [diff] [review]
patch

re-request approval once above questions addressed.
Attachment #313149 - Flags: approval1.9?
Comment on attachment 313149 [details] [diff] [review]
patch

This is a very safe patch. The reason we don't have many tests covering this is that it will only affect SVG text; during normal browser operation the gfxContext will have the identity CTM so this patch will have no effect.

Furthermore the patch is "obviously correct", we completely understand this code.
Attachment #313149 - Flags: approval1.9?
Comment on attachment 313149 [details] [diff] [review]
patch

a1.9=beltzner
Attachment #313149 - Flags: approval1.9? → approval1.9+
Flags: blocking1.9?
(Assignee)

Updated

10 years ago
Summary: Weirdness with SVG hyperlinks and mouse events since 19/03/2008 nightly → Scaled SVG content can get the wrong font size and poison the font cache
(Assignee)

Comment 41

10 years ago
checked in
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Summary: Scaled SVG content can get the wrong font size and poison the font cache → Scaled SVG content can get the wrong metrics and poison the cache

Comment 42

10 years ago
I backed this out in case it caused the tbox orange we're seeing now.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 43

10 years ago
I don't think this caused the unit test failures.

Comment 44

10 years ago
Yeah, I agree.  Bug 426501 was the cause.

Updated

10 years ago
Whiteboard: checkin-needed
(Assignee)

Comment 45

10 years ago
checked in again.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
Whiteboard: checkin-needed
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.