Closed
Bug 304896
Opened 19 years ago
Closed 19 years ago
Assertion on reload
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mrbkap, Assigned: mrbkap)
References
Details
(Keywords: assertion, fixed1.8)
Attachments
(3 files)
3.11 KB,
text/plain
|
Details | |
2.42 KB,
patch
|
jst
:
review+
jst
:
superreview+
brendan
:
approval1.8b4+
|
Details | Diff | Splinter Review |
1.35 KB,
patch
|
jst
:
review+
jst
:
superreview+
brendan
:
approval1.8b4+
|
Details | Diff | Splinter Review |
Occasionally, when I reload, I hit: ###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property! This is pretty much always bad. It usually means that native code is making a callback to an interface implemented in JavaScript, but the document where the JS object was created has already been cleared and the global properties of that document's window are *gone*. Generally this indicates a problem that should be addressed in the design and use of the callback code. I'll attach the stack in an attachment. jst and I spent some time yesterday debugging this and weren't able to figure out why this was happening. It seems like the code was doing the right thing. I don't know if this was introduced by my checkin for bug 303267.
Assignee | ||
Comment 1•19 years ago
|
||
Updated•19 years ago
|
Blocks: splitwindows
Flags: blocking1.8b4?
Comment 2•19 years ago
|
||
Can you reproduce and determine if this is critical enough to block?
Flags: blocking1.8b4? → blocking1.8b4+
Comment 3•19 years ago
|
||
This is splitwindow fallout that should IMO be fixed on the branch. We just figured out what's causing this and the fix is very straight forward. Blake's hacking up the patch.
Assignee | ||
Comment 4•19 years ago
|
||
The problem was that we weren't correctly reparenting the navigator object in xpconnect, so that we ended up looking up its scope into the (cleared) old inner window's global object. This was because the navigator was having its docshell cleared in SetNewDocument and the docshell wasn't getting reset when it was pulled out of the bfcache. Now we do that (and refuse to create the navigator altogether if it's unable to get a good global object to attach to.
Attachment #193000 -
Flags: review?(jst)
Comment 5•19 years ago
|
||
Comment on attachment 193000 [details] [diff] [review] reset mNavigator's docshell Yeah, r+sr=jst
Attachment #193000 -
Flags: superreview+
Attachment #193000 -
Flags: review?(jst)
Attachment #193000 -
Flags: review+
Comment 6•19 years ago
|
||
Comment on attachment 193000 [details] [diff] [review] reset mNavigator's docshell NS_ERROR_UNEXPECTED seems better than NS_ERROR_INVALID_POINTER. a=me either way. /be
Attachment #193000 -
Flags: approval1.8b4+
Assignee | ||
Comment 7•19 years ago
|
||
Fix checked into trunk.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 8•19 years ago
|
||
Comment on attachment 193000 [details] [diff] [review] reset mNavigator's docshell > mNavigator = wsh->GetNavigator(); // This assignment addrefs. >+ >+ // Update mNavigator's docshell pointer now. >+ mNavigator->SetDocShell(mDocShell); >+ mNavigator->LoadingNewDocument(); Is it reasonable for mNavigator to be null here, or was my crash caused by a different bug?
Comment 9•19 years ago
|
||
Yes, it's reasonable for mNavigator to be null, see the other GetNavigator.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 10•19 years ago
|
||
This caused bug 305166?
Assignee | ||
Comment 11•19 years ago
|
||
Easy workaround: only go back to pages that have scrollbars ;-).
Attachment #193174 -
Flags: superreview?(jst)
Attachment #193174 -
Flags: review?(jst)
Comment 12•19 years ago
|
||
Comment on attachment 193174 [details] [diff] [review] null-check mNavigator r+sr=jst
Attachment #193174 -
Flags: superreview?(jst)
Attachment #193174 -
Flags: superreview+
Attachment #193174 -
Flags: review?(jst)
Attachment #193174 -
Flags: review+
Assignee | ||
Comment 13•19 years ago
|
||
Comment on attachment 193174 [details] [diff] [review] null-check mNavigator Might as well get approval for this before I check the first patch into the branch.
Attachment #193174 -
Flags: approval1.8b4?
Assignee | ||
Comment 14•19 years ago
|
||
Fix checked into trunk. Marking FIXED again. Sorry for missing this on the first time around.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Comment 15•19 years ago
|
||
Comment on attachment 193174 [details] [diff] [review] null-check mNavigator a=me for 1.8b4. /be
Attachment #193174 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 16•19 years ago
|
||
Both patches checked into MOZILLA_1_8_BRANCH (at the same time).
Keywords: fixed1.8
You need to log in
before you can comment on or make changes to this bug.
Description
•