294610 - fastback/bfcache remembers DOM state after event processing on page quit

Status: RESOLVED INVALID

(Core :: DOM: Navigation, defect)

Description

[Francois Ingelrest]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050515 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050515 Firefox/1.0+

See steps to reproduce.

Reproducible: Always

Steps to Reproduce:
1. Go to the given URL
2. Perform a search on the term 'video'
3. When the results are displayed, hit the back button

Actual Results:  
The button 'Valider' has disappeared.

Expected Results:  
It should not.

Comment 1

[Frank Wein [:mcsmurf]]

This code gets executed when submitting the form:
onclick="document.form1.Valider.style.visibility='hidden';"
Hm...looks like it's doing this so you don't submit twice when the results page
takes a bit longer to load. Opera has the same problem here.

Comment 2

[Francois Ingelrest]

You are right, so my title for this bug is not correct but I don't know which
one would suit the best.
If the goal of the new "Instant Back/Forward" feature is to display the page
exactly as it was when the user left it, then this should perhaps not be
considered as a bug...

Comment 3

[Magnus Melin [:mkmelin]]

FWIW, the button doesn't show in opera8 either after going back. (But it does
show in ff with fasback disabled.)

Comment 4

[Brian Ryner (not reading)]

The behavior is by design, however, I suspect in browsers such as IE, the DOM is
not cached because of one of:

<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Cache-Control" content="no-cache, must-revalidate" />

I'm wondering if we should try to emulate IE a bit more closely for
compatibility here.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: patch to fix

I had to add the mDocument member because some callsites first calls Destroy()
on the contentviewer before calling SetContentViewer(nsnull) on the SHEntry. In
that case we wouldn't be able to get to the document to remove ourselvs as
observer causing the document to have a dangling pointer once the SHEntry goes
away.

The PLEvent fixes two problems. First of all we don't want to risk dropping the
last reference to the contentviewer during mutation causing the contentviewer
and document to die. Second, calling Destroy on the viewer during mutation
seemed to remove some other documentobservers (probably the presshell). The
notification code can't deal with observers other then the current one being
removed during notification.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Opps, previous comment was for bug 292962

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think this is a problem in IE because AFAICT they never cache the DOM.
I'm not sure there is much we can do about this type of problem besides
evangilizing. This is the same type of problem as we have with going back to a
google search result.

Comment 8

[Brian Ryner (not reading)]

Ok, I think this is not a bug.