Closed
Bug 305995
Opened 19 years ago
Closed 19 years ago
crash going back from onunload trap [@ nsDocShell::RestoreFromHistory] [@ nsDocShell::CreateContentViewer]
Categories
(Core :: DOM: Navigation, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: bryner)
References
Details
(Keywords: crash, verified1.8, Whiteboard: [needs review+SR bzbarsky])
Crash Data
Attachments
(2 files)
166 bytes,
text/html
|
Details | |
1023 bytes,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
TB8722232Z
Reporter | ||
Comment 1•19 years ago
|
||
Testcase stolen from bug 305978.
Reporter | ||
Comment 2•19 years ago
|
||
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.
Reporter | ||
Updated•19 years ago
|
Blocks: blazinglyfastback
Comment 3•19 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050825
Firefox/1.0+ ID:2005082514
TB8723769Z
Reporter | ||
Comment 4•19 years ago
|
||
TB8723764E (wgianopoulos)
TB8723858 (ispiked)
Reporter | ||
Updated•19 years ago
|
Summary: crash going back from onunload trap → crash going back from onunload trap [@ nsDocShell::RestoreFromHistory] [@ nsDocShell::CreateContentViewer]
Updated•19 years ago
|
OS: MacOS X → All
Hardware: Macintosh → All
![]() |
||
Updated•19 years ago
|
Flags: blocking1.8b4?
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Updated•19 years ago
|
Flags: blocking1.8b4rc+
Comment 5•19 years ago
|
||
Bryner - since it looks to be bfcache related can you take a look?
Assignee: nobody → bryner
Assignee | ||
Comment 6•19 years ago
|
||
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.
Attachment #194148 -
Flags: superreview?(bzbarsky)
Attachment #194148 -
Flags: review?(bzbarsky)
Updated•19 years ago
|
Flags: blocking1.8b4rc+
Updated•19 years ago
|
Whiteboard: [needs review+SR bzbarsky]
![]() |
||
Updated•19 years ago
|
Attachment #194148 -
Flags: superreview?(bzbarsky)
Attachment #194148 -
Flags: superreview+
Attachment #194148 -
Flags: review?(bzbarsky)
Attachment #194148 -
Flags: review+
Assignee | ||
Comment 7•19 years ago
|
||
checked in on trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•19 years ago
|
Attachment #194148 -
Flags: approval1.8b4?
Comment 8•19 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Updated•19 years ago
|
Attachment #194148 -
Flags: approval1.8b4? → approval1.8b4+
Comment 10•19 years ago
|
||
verified on Firefox 1.4 -mozilla1.8 branch- Win, Lin and Mac : 2005-09-07
Keywords: fixed1.8 → verified1.8
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Updated•14 years ago
|
Crash Signature: [@ nsDocShell::RestoreFromHistory]
[@ nsDocShell::CreateContentViewer]
You need to log in
before you can comment on or make changes to this bug.
Description
•