User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050617 Firefox/1.0+ With the fast back-forward cache enabled, pages don't repaint when going back. Reproducible: Always Steps to Reproduce: 1. In about:config, set browser.sessionhistory.max_viewers to 5 as suggested, and restart Deer Park. 2. View one page ("Page 1"). 3. Navigate to another page ("Page 2"). 4. Click the Back button. Actual Results: The address bar changes to that of Page 1, but the content window remains on Page 2. By using the keyboard to scroll, the newly revealed part repaints, resulting in a view that is partly Page 1 and partly Page 2. Using the build advertised on Asa's blog: http://weblogs.mozillazine.org/asa/archives/008353.html The 20050531 build does not have this problem. No extensions installed.

I just reported this on <http://weblogs.mozillazine.org/josh/archives/2005/06/firefox_mac_bui.html> It works fine with the normal 20050618-nightly, but not with Josh experimental build (see bug 282940).

We put content viewer destruction off on a plevent, which means that the Hide() may not happen now until after we invalidate. Make the Hide() part synchronous so that the right things get painted. This is a regression from bug 294231.

Comment on attachment 187070 [details] [diff] [review] patch hiding the content viewer up front, while still deferring its destruction, seems reasonable to me. r=darin unfortunately, i don't know content viewer well enough, so i'd still recommend getting a review from dbaron, boris, or someone :)

Comment on attachment 187070 [details] [diff] [review] patch requesting approval, pretty safe fastback fix

sr=dbaron, but maybe you should remove the Hide call from DocumentViewerImpl::Destroy?

Maybe... it's a good thing to make sure of though so I think I'll leave it for now (perhaps clean it up when we clean up docviewer teardown as described in bug 297991). Checked in.