When I load http://www.flickr.com/ (while logged in), the first time I click on the "Your Contacts" link the page background doesn't paint and we just draw the new content on top of the old content. It looks pretty bad. I can reproduce it this way every time, but often only the first time in my browsing session. I have seen it happen multiple times during the same session, but it is harder for me to reproduce it that way. I'm able to reproduce this on multiple Windows machines, both on Vista and XP.

See bug 474201 and associates, this looks similar.

Stuart, dbaron says that a something that was causing this was fixed 2-3 days ago -- can you update to the latest nightly and try again?

Yep, I was thinking of the bug mentioned in comment 1.

I can't reproduce this with a build as of this morning and my flickr account, but I'm on Linux and I can't reproduce bug 475548 there either.

I can see similar things with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090127 Minefield/3.2a1pre ID:20090127032613 on my VmWare box. When having open the contacts page on flickr and opening the menus afterward the whole content area is messed-up. Steps: 1. Start Firefox and goto http://www.flickr.com 2. Login and goto contacts page 3. Using the menu to browse some sub-menus With step 3 I can see the output as what is shown by the attached screenshot.

that's helpful, but I still can't reproduce it on Linux. I will not be able to test a Windows build until tomorrow, but I'll stare at the code meanwhile.

I further tried to save the contacts page as "webpage complete", but it totally hangs my browser.

(In reply to comment #7) > I further tried to save the contacts page as "webpage complete", but it totally > hangs my browser. Well, that's not my fault :) And I'm afraid it wouldn't help, anyway -- if this is really because of bug 474201, it's an issue with the handoff from one page to another, and it has to do with how much of that work the OS does for us (which is why it's Windows-specific). It occurs to me that it would be useful to know if anyone can reproduce either this bug or bug 475548 on a Mac.

Ok, I was able to reproduce it twice with the following steps: 1. Create a fresh profile so our cache is empty 2. Open http://www.flickr.com 3. Click on login 4. Enter your credentials and click login 5. While the start page is loading immediately click on Contacts 6. Scroll up/down while the page is loading In step 6 you will see the garbled text. I hope that I'll be able to find the regression range now.

(In reply to comment #7) > I further tried to save the contacts page as "webpage complete", but it totally > hangs my browser. (FWIW, that's Bug 475078)

Marking b+

It looks like that it regressed sometime around first half of December. I will get a closer time frame...

Could someone who sees this bug please run a debug build of firefox from a command prompt, reproduce the bug, and then check whether any of these warnings appear in the console messages? WARNING: nsViewManager: Asked to paint a default background, but no default background color is set! file .../view/src/nsViewManager.cpp, line 553

For what I can see the regression started between the following builds: http://hg.mozilla.org/mozilla-central/rev/eb8abab83036 http://hg.mozilla.org/mozilla-central/rev/050ae62b7d9d http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=eb8abab83036&tochange=050ae62b7d9d I hope that helps.

Interestingly, the end of that range has a bunch of backouts, right?

I would have suspected bug 456219 as the most likely bug in that list, except that it was backed out at the end of that range. Henrik, can you focus on that changeset (4fbb9483d7e6) and see if it's guilty?

We probably should block on this.

--> Core::Layout

I've tried to create tryserver builds from the given changesets because I wasn't able to get my buildsystem running. Sadly the created builds don't respect the changeset and were build against the most recent one. :/ Is there anybody who can offer me such builds? I dont know when I will be able to create local builds. Martijn, do you have a chance?

This could be fixed by the patch in bug 475548

Roc, does it mean no further investigation is necessary at the moment?

I don't know.

Ok, I was able to identify the problem. I had to build Minefield twice. The first run was with the mentioned changeset 4fbb9483d7e6. But that build looks fine. So I thought about which could also has been caused this bug. I've seen the changeset 8fb487d20112 (bug 467423) which is directly following. So I created a build from that changeset and tested again. And finally the Flickr contacts page wasn't repainted anymore. So the cause is bug 467423 (Painting stops in this case, using -moz-transform: scale, rotate and video). Adding Jeff for further investigation.

Setting a break point on _cairo_error and getting a backtrace might give a hint as to what's going on here.

I was able to reproduce this. Unsurprisingly, it looks like this might have to do with errors propagating from scaled fonts created with bad matrices. I'll take a look. If some one can come up with very reliable steps to reproduce this, that would be helpful it seemed intermittent for me...

Jeff, my steps from comment 9 are very reliable for me. I can see it each time.

Back to GFX! I think this is worth a P1 -- Jeff, let me know if you disagree. I think we should get this fixed for b3.

I agree it would be good to get fixed for b3. I'm not sure how long it will take though...

The attached patch seems like it might fix the bug. I've sent the patch off to try server so if anyone wants to try it out to see if they can reproduce it with the patched build that would help.

Vlad: do we really think we can't ship b3 without this? I agree that it's not great, and we'd definitely take the patch should it come through in time, but I don't know if we'd block release on it. What's changed in our evaluation since when it was marked a P2?

(In reply to comment #30) > The attached patch seems like it might fix the bug. I've sent the patch off to > try server so if anyone wants to try it out to see if they can reproduce it > with the patched build that would help. The tryserver builds are available here: http://tinyurl.com/bveds3 I run this build on my Vista VM and I cannot see the repainting issues anymore with the same steps I've given in comment 9. By running current nightly builds in parallel, I still can see the issue. So this patch might really fix this problem.

This version should have the same effect and be a little less risky then the last one. New builds with this should show up on try server soon with the name jrmuizel.

Comment on attachment 359928 [details] [diff] [review] Only ignore uninvertible rank 0 matrices Looks good; did you manage to catch in the debugger the callsite that's creating a 0x0 font matrix? We should fix that as well.

I can look at the call site on Monday, I don't have a windows env setup at home.

I'll upstream this or something like it. We're currently redoing the invalid font matrix handling in cairo so it might be a little different.

Any thoughts on how this relates to bug 435459 (also a Flickr rendering problem though maybe slightly different in manifestation).

The tryserver builds at http://tinyurl.com/bp6k9t look good and also solve this painting problem. (In reply to comment #37) > Any thoughts on how this relates to bug 435459 (also a Flickr rendering problem > though maybe slightly different in manifestation). This will be solved by this bug. Please try the given tryserver build for your platform and please verify if it works now. Also remember to create a fresh profile for this test: http://tinyurl.com/yqs29d

Jeff, can you get the patch into the right format with an addition to the cairo README etc?

Johnathan pushed this on Wednesday: http://hg.mozilla.org/mozilla-central/rev/e646709ecfc5 Jeff says he's going to take care of upstreaming this fix or something like it, and will also update our in-tree cairo README.

https://hg.mozilla.org/mozilla-central/rev/db5bba11c8a4 https://hg.mozilla.org/releases/mozilla-1.9.1/rev/587d4ddd9a64

Due to I was only able to see this issue with my WinXP under VmWare I can now verify that it is fixed on trunk and 1.9.1 branch with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090208 Minefield/3.2a1pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090201 Shiretoko/3.1b3pre

This bug also exists in prior FF versions, like 3.0.x. I am running 3.0.8 and the problem is still there. Do we get also a patch/fix for the stable series please? Thanks! Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)

Thomas, this bug is a regression from a patch which went into 1.9.1 branch but not for 1.9.0.x. Probably you see another issue. Jeff, or do I miss a bug where a patch went into 1.9.0.x?

This was never fixed on 1.9.0.x I was not even aware that it could be reproduced on 1.9.0.x.

Thomas, please file a new bug on your issue and attach a screenshot and useful STR to reproduce this issue. Thanks.

I had exactly the same issue with flickr in FF 3.1b1/b2 but not anymore in later 3.1 releases or nightlys. But in FF 3.0.8 this problem still exists. I've attached a screenshot with this issue where the re-draw problem occurs.

Henrik, I did not see your comment timely. Okay, I'll create a new bug report.

I've filed a new bug report with STR and a screenshot: bug 487058

With the findings on bug 487058 we know that this patch also fix the problem on 1.9.0. Jeff, would you have time to come up with a patch?

Any news on this respectively did someone try the patch? FF 3.0.9 still shows the issue. Thanks! Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9 (.NET CLR 3.5.30729)

This has not landed on the 1.9.0 (3.0.x) Branch yet.

(In reply to comment #56) > This has not landed on the 1.9.0 (3.0.x) Branch yet. No. It hasn't got approval yet. It's a decision of the 1.9.0 drivers.

Not a "blocker" for branch security updates, but if the GFX team wants to land this on 1.9.0 request approval on the patch. (We need the request made by a module owner/peer, otherwise we'll just have to come back and ask for their review to indicate it's a branch-appropriate patch).

Comment on attachment 359928 [details] [diff] [review] Only ignore uninvertible rank 0 matrices I'd be happy to see this on 1.9.0.

Sorry for my ignorance, as I'm just an end user and not familiar with the meanings of "1.9.0" and so forth. I just wanted to note that I'm experiencing this bug on Flickr, running Firefox 3.0.10 on Vista 64. The status is listed as "verified fixed", but I'm unclear as to whether that implies that the fix has already been pushed out to us end users, or whether it's still waiting in the wings. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 GTB5 (.NET CLR 3.5.30729)

The present state of this bug is: - VERIFIED FIXED: Confirmed to be fixed on the development trunk, which is currently neither 3.0 nor even 3.5-to-be, but the version *after* 3.5 (due out probably sometime next year). Really only relevant to us developers. - verified1.9.1 (in the "keywords" box): Confirmed to be fixed in Gecko version 1.9.1, which is the rendering engine used in Firefox 3.5-to-be. - approval1.9.0.12? (on one of the attachments): Someone (specifically, Vladimir, author of comment #59) has requested that the patch be considered for inclusion in Gecko 1.9.0.12, which is the rendering engine that will be used in Firefox 3.0.12. This is not a guarantee that it *will* be included, but the conversation in comments 57 through 59 indicates that it's likely. Yes, this is confusing and arcane for end users; it's optimized for what us developers need to know, not for the sort of thing you want to know. However, there *is* a straightforward translation once you know what all the code names and version numbers mean: The bug is likely to be fixed in the next-but-one release of Firefox 3.0, which is currently scheduled for mid-July (you can see the schedule on https://wiki.mozilla.org/Releases). If you would like your own browser to be fixed before then, your best bet is to switch to a 3.5 beta (available from http://www.mozilla.com/en-US/firefox/all-beta.html -- the patch landed on the 1.9.1 branch in February, so the most recent beta will definitely have it).

Thanks very much for taking the time to write such a clear explanation, Zack. I realize everyone's quite busy, so I really appreciate it. I use Flickr quite a bit, so I'll think about giving the 3.5 beta a try.

Comment on attachment 359928 [details] [diff] [review] Only ignore uninvertible rank 0 matrices Approved for 1.9.0.12, a=dveditz for release-drivers

Comment on attachment 359928 [details] [diff] [review] Only ignore uninvertible rank 0 matrices unapproved for 1.9.0.12: past code-freeze and not a blocking bug. Also if we try this again we need to get a roll-up patch that includes regression fixes. Looks like this caused bug 475548, and the patch for that requires the changes in bug 473398, which in turn caused bug 474201. At one point 475548 was also blamed for regression bug 486473 (unfixed!) but more recently that was blamed on bug 479637.