I don't have steps to reproduce but I've seen these multiple times, it does not happen everytime. I click the back button, the page does not update, but the tab title does. Mouse moves over the page that cause invalidation draw the expected page. We suppress painting in the bfcache, there must be some corner case where the invalidate for the new page showing happens before the bfcache painting suppression is removed and PresShell::UnsuppressAndInvalidate isn't called maybe?

This might be related to the presshell being active or not, I don't know if we are guaranteed an invalidate when a presshell becomes active.

Hmm. Invalidating there shouldn't be an issue; we can just do it. You might be right that nothing guarantees it now. Do we actually use paint suppression (in the UnsuppressAndInvalidate sense) for bfcache?

I think we set mPaintingSuppressed on the presshell to true when we put the document in the bfcache. I couldn't see where UnsuppressAndInvalidate would get called when it came out of the bfcache, so maybe I have something wrong there.

Ah, indeed. We set that in Freeze. We call UnsuppressPainting() in Thaw. That should call UnsuppressAndInvalidate, I'd think.

Just found this by code inspection. Not saying that this will solve all cases.

Description of patch above: If QueryIsActive changes our status from not active to active then the invalidate resulting from UnsuppressPainting will be dropped because we drop invalidates when not active now.

When we switch tabs the tabbox widget changes the selected index on the deck content here http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/tabbox.xml#668 . This causes the deck frame to hide/show the views for the relevant boxes. This gives an invalidate to the whole content area. Then in tabbox again we dispatch a select event, which browser/base/content/tabbrowser.xml listens for and updates the relevant docshell's active flags. This happens without going back to the event loop, and none of the invalidates are immediate, so unless there are some other invalidates that are immediate or something else weird we should be good there. So I'm going to try just the one patch in this bug already and see if we still have problems here. If needed we can try to figure something else out so we don't have to accidentally do an extra paint ever.

Comment on attachment 472239 [details] [diff] [review] patch r=bzbarsky I wonder whether we can reftest this somehow...

Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre I have twice hit this since this was marked fixed, but I can't reproduce it on demand. Both times were going back from a bug attachment to a bug. Hovering over links makes them paint, but I have to scroll to cause the whole page to appear.

Ok, please file a new bug and cc me. Mark it as blocking bug 592131. Thanks.

(In reply to comment #11) > Ok, please file a new bug and cc me. Mark it as blocking bug 592131. Thanks. It would have exactly the same summary and comment 0 as this bug so I don't see a reason to file a new bug. It's not a new regression, just the same one but less often as far as I can tell. I haven't seen this again yet since comment 10 and I have no real STR. If anyone else sees this it would be good to know that it's not something in my specific setup.

That's all fine. Please file a new bug. Reopening this bug will just lead to confusion. If we don't have an open bug about this then if other people are seeing the same thing they have no place to post their comments saying "me too".

(In reply to comment #13) > That's all fine. Please file a new bug. Reopening this bug will just lead to > confusion. If we don't have an open bug about this then if other people are > seeing the same thing they have no place to post their comments saying "me > too". OK. Bug 597774. Me too comments would be welcome to start with, as it seems that no-one else has hit this yet.