63145 - crash @ nsBrowserInstance::EndDocumentLoad

Status: RESOLVED DUPLICATE of bug 26295

(Core :: DOM: Navigation, defect)

Description

[zentronium]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID:    2000101014

BAD: most of the time it just crashes when the idrive sideload window pops up, 
one time the i-drive sideload popup window displayed it's own source, reloaded 
it and navigator crashed

Reproducible: Always
Steps to Reproduce:
1.Go to the URL
2.Click on the idrive sideload icon
3.reload if necesarry as specified in the description

Actual Results:  navigator crashes

Expected Results:  layout the popup contents, and transfer the file

Comment 1

[Henrik Gemal]

*** Bug 63146 has been marked as a duplicate of this bug. ***

Comment 2

[Andreas Franke (gone)]

From the duplicate:

------- Additional Comments From Gael Le Mignot 2000-12-18 00:42 -------

With 2000121411 on Debian Linux (XFree4/Kenel 2.2.17), Moz doesn't crash but the
pop-up window either stay blank or display the page source. The title is OK.
I'll try with a more recent build soon.



------- Additional Comments From zentronium 2000-12-18 00:59 -------

Nope, tried with Build 2000121720 and its still there, sorry for the duplicate 
with 63145, it seems as it (popup) will display something but then crashes, 
takes a little longer to crash

Comment 3

[Bernd]

This assert was recently introduced by rpotts

NS_ASSERTION(0, "The DocLoader is still busy... There is a bug in End Document
notifications\n");

KERNEL32! bff768a0()
nsDebug::Assertion(const char * 0x02ca9744, const char * 0x02ca9740, const char
* 0x02ca96fc, int 1264) line 254 + 13 bytes
nsBrowserInstance::EndDocumentLoad(nsIDOMWindow * 0x03899504, nsIChannel *
0x01598f10, unsigned int 0) line 1264 + 35 bytes
nsBrowserInstance::OnStateChange(nsBrowserInstance * const 0x036c59a8,
nsIWebProgress * 0x036b8544, nsIRequest * 0x01598f10, int 786448, unsigned int
0) line 1494 + 33 bytes
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x036b8544, nsIRequest *
0x01598f10, int 786448, unsigned int 0) line 1286
nsDocLoaderImpl::doStopDocumentLoad(nsIChannel * 0x01598f10, unsigned int 0)
line 728
nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 623
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x036b8534, nsIChannel *
0x015f10c0, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 557
nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x036b84c0, nsIChannel *
0x015f10c0, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 576 + 39 bytes
PresShell::RemoveDummyLayoutRequest() line 5335 + 44 bytes
PresShell::ReflowCommandRemoved(nsIReflowCommand * 0x015f4400) line 5288
PresShell::ProcessReflowCommands(int 1) line 5108
ReflowEvent::HandleEvent() line 4989
HandlePLEvent(ReflowEvent * 0x015f1bd0) line 5003
PL_HandleEvent(PLEvent * 0x015f1bd0) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b9eba0) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000004ac, unsigned int 55370, unsigned int 0,
long 12184480) line 1054 + 9 bytes
KERNEL32! bff7363b()
KERNEL32! bff94407()
007b8a22()

Comment 4

[Uriel]

OS: Win2k SP1
Moz Build: 2000122920

I'm unable to reproduce the crash(I tried reloading also)
but the popup renders blank.

Comment 5

[zentronium]

Could it be that i have not installed SP1 ?? It continues to crash with 
2000122990 but some very, but very few times it renders it blank.

Comment 6

[rpotts (gone)]

I have been unable to reproduce the crash :-(

I do see multiple assertions that the DocLoader is still busy (like the stack
trace above) and an empty window...

However, I saw the same empty window when I clicked on the link in Communicator
4.76 !!

Unfortunately, it looks like zdnet has changed the content of the URL above, so
it no longer has the idrive sideload icon :-(

Is there another URL that exhibits this same problem?

-- rick

Comment 7

[John G. Myers]

Another URL which exhibits the same problem: http://we-gotmail.red.iplanet.com
userid x password x

Comment 8

[Judson Valeski]

need test case. that red.iplanet url doesn't accept http connections.

Comment 9

[rpotts (gone)]

It looks like the URL http://we-gotmail.red.iplanet.com is working again. 
However, now the userid and password (x,x) no longer work :-(

Any updates?

-- rick

Comment 10

[rpotts (gone)]

I'm marking this one as a dup of bug #26295...  If it's not a dup of that one,
then its a dup of bug #63529 :-)  They are both related.

I'm getting ready to check in a patch that fixes both of thes problems.

-- rick


*** This bug has been marked as a duplicate of 26295 ***

Comment 11

[John G. Myers]

The password to "x" is now "y".  Someone changed this without telling anyone.