691167 - Window content with some svg path is not repainted (FF7+XP)

Status: NEW

(Core :: Graphics, defect)

Description

[Arnaud]

Attachment: ff7_svgpath.html

User Agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.5 (KHTML, like Gecko) Chrome/16.0.891.0 Safari/535.5

Steps to reproduce:

On Windows XP, with FF7:
- open the sample HTML file
- resize the window to a very small size
- resize the window to a normal size



Actual results:

The window content is not repainted.



Expected results:

The window content is repainted correctly.

Notes:
- Switching to another tab (in the same window) and switching back to the initial tab repaints the window content.
- The problem doesn't seem to occur on Windows 7/Vista. => Problem with the old graphics engine (non-Direct2D)?
- If the SVG shape is opaque, or if the stroke width is greater than 0, or if the shape doesn't have a "hole", the problem doesn't occur.

Comment 1

[Arnaud]

My user agent when I have the problem:
Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1

Comment 2

[Alice0775 White]

This happens when I disable HWA.

Regression window (cached m-c hourly)
Works:
http://hg.mozilla.org/mozilla-central/rev/dad825159748
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110527 Firefox/7.0a1 ID:20110527011902
Fails:
http://hg.mozilla.org/mozilla-central/rev/04e8d0b481bc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110527 Firefox/7.0a1 ID:20110527081111
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dad825159748&tochange=04e8d0b481bc
Triggered by:
Bug 562746 - Update cairo to 1.10

Comment 3

[Boris Zbarsky [:bzbarsky]]

Requesting tracking for this regression, though I guess we've already shipped 7 with it...

Comment 4

[LegNeato]

---------------------------------[ Triage Comment ]---------------------------------

We are not tracking this for Firefox 8. We already shipped this in Firefox 7 and there wasn't a large amount of breakage (no real feedback, no dupes here) and we won't be backing out the cairo update (due to testing, security fixes, etc).

If a safe fix is found please nominate it for aurora and/or beta though.

Comment 5

[Arnaud]

It completely freezes the window rendering, it's not just a local rendering bug.
(Killing the rendering loop from the JS sandbox is almost a security issue? The window content can be raw pixel copy of any other window since it's not refreshed...)

Not being able to render simple SVG shape in FF7/8 is a bit disappointing,
especially when we try to move users that cannot upgrade XP from IE to Firefox (we don't have that problem with the old VML).

No real feedback: I spend some hours to find the root cause of that problem inside a large ajax app, there is no message in the web console (and just garbage chars in the DOS console), so maybe it's not easy to match that bug?

Comment 6

[LegNeato]

(In reply to Arnaud from comment #5)
> It completely freezes the window rendering, it's not just a local rendering
> bug.
> (Killing the rendering loop from the JS sandbox is almost a security issue?
> The window content can be raw pixel copy of any other window since it's not
> refreshed...)
> 
> Not being able to render simple SVG shape in FF7/8 is a bit disappointing,
> especially when we try to move users that cannot upgrade XP from IE to
> Firefox (we don't have that problem with the old VML).
> 
> No real feedback: I spend some hours to find the root cause of that problem
> inside a large ajax app, there is no message in the web console (and just
> garbage chars in the DOS console), so maybe it's not easy to match that bug?

Right, we're not saying this isn't a bad bug that should be fixed. We want a fix. We're saying for Firefox 8 we won't slam on the brakes and we can ship without this.

We very much appreciate the test case, that will go a long way to getting this fixed as soon as possible.

Comment 7

[Alex Keybl [:akeybl]]

[Triage Comment]
Still looking to get this fixed, but wouldn't block FF9/10 release.

Comment 8

[roxleitan]

20160502172042  Mozilla/5.0 (Windows NT 6.0; rv:46.0) Gecko/20100101 Firefox/46.0
20160524073714  Mozilla/5.0 (Windows NT 6.0; rv:49.0) Gecko/20100101 Firefox/49.0

I have tested your issue on latest FF release 46.0.1 and latest Nightly build and could not reproduce it.

Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).

Comment 9

[(mostly gone) XtC4UaLL [:xtc4uall]]

(In reply to roxana.leitan from comment #8)
easily reproduced here against trunk