298112 - Failure to repaint with bfcache

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Derek Poon]

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.

Comment 1

[Jo Hermans]

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

Comment 2

[Brian Ryner (not reading)]

Attachment: patch

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 3

[Darin Fisher]

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 4

[Brian Ryner (not reading)]

Comment on attachment 187070 [details] [diff] [review]
patch

requesting approval, pretty safe fastback fix

Comment 5

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

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

Comment 6

[Brian Ryner (not reading)]

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.