305995 - crash going back from onunload trap [@ nsDocShell::RestoreFromHistory] [@ nsDocShell::CreateContentViewer]

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Jesse Ruderman]

TB8722232Z

Comment 1

[Jesse Ruderman]

Attachment: testcase (simple onunload trap)

Testcase stolen from bug 305978.

Comment 2

[Jesse Ruderman]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050825
Firefox/1.0+

Only happens when bfcache is enabled.

Steps to reproduce:
1. Click the link to the testcase (attachment 193872 [details]).
2. Click the back button.

Result: boom.

Comment 3

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050825
Firefox/1.0+ ID:2005082514

TB8723769Z

Comment 4

[Jesse Ruderman]

TB8723764E (wgianopoulos)
TB8723858 (ispiked)

Comment 5

[Mike Schroepfer]

Bryner - since it looks to be bfcache related can you take a look?

Comment 6

[Brian Ryner (not reading)]

Attachment: patch

This patch doesn't attempt to address bug 251944, it just keeps us from
crashing in the fastback case.	If any type of load happens that changes mLSHE,
we'll stop the restore.  At this point we haven't done anything that commits us
to finishing the restore.  As I understand it, the request for the document we
started to restore should be removed from the loadgroup via nsDocLoader::Stop()
if a new load is started.

Comment 7

[Brian Ryner (not reading)]

checked in on trunk.

Comment 8

[Tracy Walker [:tracy]]

verified on trunk with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050901 Firefox/1.6a1

no crash...
bug 251944 still present; can't go back from the testcase page.

Comment 9

[Brian Ryner (not reading)]

checked in on the branch

Comment 10

[Tracy Walker [:tracy]]

verified on Firefox 1.4 -mozilla1.8 branch- Win, Lin and Mac : 2005-09-07