54739 - Assertion: NS_ENSURE_TRUE(mSessionHistory) failed

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

FreeBSD 4.1 20000928xx

At the site above (and various pages within it), you get this assertion. This
might be a docshell thing, perhaps.  It's trying to get the history length
attribute from JS when this assertion kicks out.  The JS is at
http://www.avp.ee/Est/menu.html

I don't know if this breaks the JS code, but I wouldn't be surprised.

Backtrace/structure dump attached.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: backtrace/dump

Comment 2

[Radha on family leave (not reading bugmail)]

It looks like  the history object is going to the wrong place in search of 
length.  It should be going to nsHistory.cpp  and calling in to docshell for 
history length. Instead it is calling nsJSHistory.cpp, which looks like is still 
hooked to  nsWebShell's history object which is obsolete. cc'ing nisheeth, 
rpotts

Comment 3

[Radha on family leave (not reading bugmail)]

Attachment: patch to nsHistory.cpp

Comment 4

[Radha on family leave (not reading bugmail)]

I have attached a patch that reroutes all history calls thro' Session History. I
don't see the assertion with the new change. Shall try to get a review soon.

Comment 5

[rpotts (gone)]

r=rpotts

Hey radha,
If I understand the patch correctly, it directs all of the javascript SH calls
through nsISHistory rather than calling the DocShell (which could be a frame -
without a SH instance)...

Sounds good to me :-)

Comment 6

[Radha on family leave (not reading bugmail)]

Rick,
You understood it right. Also it ties all history related queries that comes
from JS to SH. No more frame specific history navigations. Thanks,

Comment 7

[Radha on family leave (not reading bugmail)]

Fix checked in. 

Comment 8

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]