Open Bug 691167 Opened 13 years ago Updated 1 year ago

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

Categories

(Core :: Graphics, defect)

x86
Windows Vista
defect

Tracking

()

Tracking Status
firefox8 - wontfix
firefox9 - ---
firefox10 - ---

People

(Reporter: amasson, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(1 file)

Attached file 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.
Severity: normal → major
OS: Windows Vista → Windows XP
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
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
Blocks: 562746
Severity: major → normal
Status: UNCONFIRMED → NEW
Component: General → Graphics
Ever confirmed: true
Keywords: regression
OS: Windows XP → Windows Vista
Product: Firefox → Core
QA Contact: general → thebes
Attachment #564059 - Attachment mime type: text/plain → text/html
Keywords: testcase
Version: 7 Branch → Trunk
Requesting tracking for this regression, though I guess we've already shipped 7 with it...
---------------------------------[ 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.
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?
(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.
[Triage Comment]
Still looking to get this fixed, but wouldn't block FF9/10 release.
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).
(In reply to roxana.leitan from comment #8)
easily reproduced here against trunk
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.