474886 - Not redrawing the background when changing page on flickr

Status: VERIFIED FIXED

(Core :: Graphics, defect, P1)

Description

[Stuart Parmenter]

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.

Comment 1

[Nochum Sossonko [:Natch]]

See bug 474201 and associates, this looks similar.

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 4

[Zack Weinberg (:zwol)]

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.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: Garbled contacts page

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.

Comment 6

[Zack Weinberg (:zwol)]

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.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 8

[Zack Weinberg (:zwol)]

(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.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 10

[Daniel Holbert [:dholbert]]

(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)

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Marking b+

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 13

[Zack Weinberg (:zwol)]

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

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We probably should block on this.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

--> Core::Layout

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This could be fixed by the patch in bug 475548

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't know.

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 25

[Jeff Muizelaar [:jrmuizel]]

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

Comment 26

[Jeff Muizelaar [:jrmuizel]]

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...

Comment 27

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 28

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 29

[Jeff Muizelaar [:jrmuizel]]

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

Comment 30

[Jeff Muizelaar [:jrmuizel]]

Attachment: Disable putting ourselves in an error state.

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.

Comment 31

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.

Comment 33

[Jeff Muizelaar [:jrmuizel]]

Attachment: Only ignore uninvertible rank 0 matrices

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 34

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 35

[Jeff Muizelaar [:jrmuizel]]

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

Comment 36

[Jeff Muizelaar [:jrmuizel]]

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.

Comment 37

[John Zwinck]

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

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 40

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 41

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 42

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/releases/mozilla-1.9.1/rev/3b74600289bb

Comment 43

[:Gavin Sharp [email: [e-mail]]]

Attachment: cairo README

Comment 44

[:Gavin Sharp [email: [e-mail]]]

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

Comment 45

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 46

[Thomas Babut]

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)

Comment 47

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 48

[Jeff Muizelaar [:jrmuizel]]

This was never fixed on 1.9.0.x

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

Comment 49

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 50

[Thomas Babut]

Attachment: FF 3.0.8 with the flickr re-draw problem

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.

Comment 51

[Thomas Babut]

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

Comment 52

[Thomas Babut]

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

Comment 54

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?

Comment 55

[Thomas Babut]

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)

Comment 56

[Nochum Sossonko [:Natch]]

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

Comment 57

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(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.

Comment 58

[Daniel Veditz [:dveditz]]

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 59

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 359928 [details] [diff] [review]
Only ignore uninvertible rank 0 matrices

I'd be happy to see this on 1.9.0.

Comment 60

[Wally Hartshorn]

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)

Comment 61

[Zack Weinberg (:zwol)]

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).

Comment 62

[Wally Hartshorn]

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 63

[Daniel Veditz [:dveditz]]

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 64

[Daniel Veditz [:dveditz]]

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.