36361 - Open Web Location won't load page, sometimes crashes

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P1)

Description

[sairuh (rarely reading bugmail)]

tested using the opt comm m16 bit on linux (will test other platforms soon),
2000.04.19.09-m16.

1. select File > Open Web Location to bring up dialog.
2. enter a url, eg, http://www.netscape.com/ or www.amazon.com or www.msn.com.
3. click Open or hit enter key.

result: browser blacks out while trying to load the page...and the status bar
keeps spinning and spinning, while the page doesn't load.

workaround: hit Stop button. then click Reload, and the page loads.

occaisional: the browser crashes at step 1 or 3 --esp after opening another
[new] browser window. talkback info:

http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=96&cp=3&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=9004739


 Call Stack:    (Signature = nsHTTPServerListener::OnDataAvailable() aa902f2d) 
     
  nsHTTPServerListener::OnDataAvailable() 
                                                
     
  nsOnDataAvailableEvent::HandleEvent() 
                                                
     
  nsStreamListenerEvent::HandlePLEvent() 
                                                
     
  PL_HandleEvent() 
                                                
     
  PL_ProcessPendingEvents() 
                                                
     
  nsEventQueueImpl::ProcessPendingEvents() 
                                                
     
  nsEventQueueImpl::ProcessPendingEvents() 
                                                
     
  nsAppShell::DispatchNativeEvent() 
                                                
     
  nsXULWindow::ShowModal() 
                                                
     
  nsWebShellWindow::ShowModal() 
                                                
     
  nsChromeTreeOwner::ShowModal() 
                                                
     
  GlobalWindowImpl::OpenInternal() 
                                                
     
  GlobalWindowImpl::OpenDialog() 
                                                
     
  WindowOpenDialog() 
                                                
     
  js_Invoke() 
                                                
     
  js_Interpret() 
                                                
     
  js_Invoke() 
                                                
     
  js_InternalInvoke() 
                                                
     
  JS_CallFunctionValue() 
                                                
     
  nsJSContext::CallEventHandler() 
                                                
     
  nsJSEventListener::HandleEvent() 
                                                
     
  nsEventListenerManager::HandleEventSubType() 
                                                
     
  nsEventListenerManager::HandleEvent() 
                                                
     
  nsXULElement::HandleDOMEvent() 
                                                
     
  nsMenuFrame::Execute() 
                                                
     
  nsMenuFrame::HandleEvent() 
                                                
     
  PresShell::HandleEvent() 
                                                
     
  nsView::HandleEvent() 
                                                
     
  nsView::HandleEvent() 
                                                
     
  nsViewManager2::DispatchEvent() 
                                                
     
  HandleEvent() 
                                                
     
  nsWidget::DispatchEvent() 
                                                
     
  nsWidget::DispatchWindowEvent() 
                                                
     
  nsWidget::DispatchMouseEvent() 
                                                
     
  nsWidget::OnButtonReleaseSignal() 
                                                
     
  nsWindow::HandleGDKEvent() 
                                                
     
  dispatch_superwin_event() 
                                                
     
  handle_gdk_event() 
                                                
     
  libgdk-1.2.so.0 + 0x1700b (0x407c000b) 
                                                
     
  libglib-1.2.so.0 + 0xfbe6 (0x407edbe6) 
                                                
     
  libglib-1.2.so.0 + 0x101a1 (0x407ee1a1) 
                                                
     
  libglib-1.2.so.0 + 0x10341 (0x407ee341) 
                                                
     
  libgtk-1.2.so.0 + 0x8c209 (0x40715209) 
                                                
     
  nsAppShell::Run() 
                                                
     
  nsAppShellService::Run() 
                                                
     
  main1() 
                                                
     
  main() 
                                                
     
  libc.so.6 + 0x181eb (0x402f21eb)

Comment 1

[sairuh (rarely reading bugmail)]

don't see this on the Mac and winNT m16 comm bits today.

Comment 2

[Peter Trudelle]

I"m seeing intermittent crashes loading pages from personal toolbar bookmarks
too, on win98.  should that be a separate bug?

Comment 3

[Mike Pinkerton (not reading bugmail)]

this doesn't look like a bug for bill...crash is in netlib.

Comment 4

[Bill Law]

Not my fault but I'm going to look over yesterday's changes to try to find a 
more likely suspect.

Comment 5

[sairuh (rarely reading bugmail)]

peter, did you get a trace or talkback report?

bill, pls reassign where appropriate if it's really not yours. thx!

Comment 6

[Simon Fraser [no longer active]]

cc: valeski, ruslan, since crashes are in necko code.

Comment 7

[Dan M]

law and I notice that reverting ruslan's changes made 04/18/2000 21:19 to 
nsHTTPChannel.h/cpp fix this problem. assigning to him.

Comment 8

[Judson Valeski]

hmm, I'm getting an assertion in nsHTMLContentSink.cpp::EvaluateScript. The
globalObject doesn't exist. I wonder if the disk cache is breaking things?
inline js files (and css) are loaded with the FORCE_RELOAD flag, I wonder if the
disk cache is not handling it properly?

Comment 9

[sairuh (rarely reading bugmail)]

very odd... this now happens occaisionally with the latest respin of the linux
opt comm bits, 2000.04.19.10-m16. very odd. anyone else still see this w/the
latest opt bits?

Comment 10

[Dan M]

addendum to my note above: even after backing out those changes, it's still not 
quite healthy. sometimes it will spin quite a while before loading mozilla.org. 
it seems always to succeed, given patience. but i doubt that's the whole problem.

Comment 11

[sairuh (rarely reading bugmail)]

since i cannot get this to happen *all* the time with the *current* linux bits,
am gonna remove the smoketest kw (and bumping it from the 'blocker' state).
still, this annoying issue (ie, load fails when using Open Web Location dialog)
rears its ugly head periodically --so am gonna label this as dogfood.

Comment 12

[ruslan]

Does it work with file cache disabled? David, if you don't think it's cache - 
reassign it back to me.

Comment 13

[ruslan]

My change of yesterday was to prevent redirect looping and it's very local. I 
don't think it breaks anything at all. It basically checks if the redirected url 
is the same as original url and bails.

Comment 14

[Dan M]

I take it back -- I must have hit one of sairuh's "sometimes it works anyway" 
instances when I tried backing out ruslan's changes. My build generally hangs a 
very long time and then eventually loads mozilla.org. Sometimes it loads quickly. 
This seems independent of ruslan's changes.

Comment 15

[ruslan]

It's just finished building and I backed out all of my changes from yesterday 
(just to be sure) and it still looks really bad. I don't think my changes are 
affecting anything. It behaves vastly different from yesteday and will always 
crash on shutdown, at least on win32.

Comment 16

[davidm]

I turned off the disk cache and things are still broken. I then turned caching 
off compleseem to click on any of the radio buttons using 4.7
BTW to disable the cache go to the preferences->debug there are a couple of 
checkboxes.ting and I am still getting the assertion on my win32 build ( last 
night around 10pm) about global object being null so I am guessing that the 
cache is an innocent bystander in this. Reassign back to ruslan. I'll keep 
looking in the mean time

Comment 17

[leger]

Putting on [dogfood+] radar.

Comment 18

[ruslan]

I've a linux build from yesterday with my changes in there and it does seem to 
load www.netscape.com just fine. I think we may be hitting totally unrelated 
bustage from elsewhere.

Comment 19

[Peter Trudelle]

My crashes look different, will open another bug.

Comment 20

[ruslan]

This is not a netlib bug. The problem only exists is when you type the site name 
via Open Web Location. According to the log it complains about the event being 
stuck in the queue. From the netlib log I can also see that all notifications 
stop arriving into http handler (which is on mozilla thread) at some point.

Comment 21

[davidm]

If I type finger.quakeworld.com in the url bar I crash every time because the js 
script context is null.

Comment 22

[troy]

I don't see anything that suggests layout here so reassigning back to component 
owner

Comment 23

[sairuh (rarely reading bugmail)]

this is still occurring w/today's opt comm bits, 2000.04.26.09.

Comment 24

[Jim Roskind]

Don,
Can you get us a real owner for this dogfood bug?  Reading some of the comments, 
the title should be "always crashes at some sites."
Thanks,
Jim

Comment 25

[sairuh (rarely reading bugmail)]

i know this is already marked dogfood, but am adding the beta2 kw, as this is a
purty basic thang.

Comment 26

[gstoll]

Is http://www.mozillazine.org included in this bug?  I filed another bug (bug
37863) on that URL, but these results looks suspiciously similar.  However, I'm
quite sure that mozillazine loaded just fine not too long ago (a week or so...)

Comment 27

[don]

Bill, who should get this bug?

Comment 28

[Bill Law]

Who should get this bug?  Somebody else, please!  I can open pages this way a 
few times but eventually got an assertion (script global object is null) at the 
point indicated in the stack trace below.  Could be a networking thing, could be 
a window thing, could be a webshell thing.  In this case, we seem to be 
executing the JS code that puts up the Netcenter ad popup.  I wonder if that's 
the common denominator (doing window.open())?

I'll let you make the call, Don.  Whoever you assign this to isn't going to be 
happy so I don't want to do it.

NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x01c37458, const char * 0x01c37448, const char 
* 0x01c3740c, int 0x000010d1) line 191 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x01c37458, const char * 0x01c37448, const 
char * 0x01c3740c, int 0x000010d1) line 249 + 21 bytes
HTMLContentSink::EvaluateScript(nsString & {...}, nsIURI * 0x034cdcb0, int 
0x00000001, const char * 0x00000000) line 4305 + 38 bytes
HTMLContentSink::OnStreamComplete(HTMLContentSink * const 0x034b0df4, 
nsIStreamLoader * 0x034c90e0, nsISupports * 0x00000000, unsigned int 0x00000000, 
unsigned int 0x000005ae, const char * 0x025684a8) line 4448 + 42 bytes
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x034c90e4, nsIChannel * 
0x034cdac0, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned 
short * 0x00000000) line 120 + 78 bytes
nsHTTPFinalListener::OnStopRequest(nsHTTPFinalListener * const 0x034cdc10, 
nsIChannel * 0x034cdac0, nsISupports * 0x00000000, unsigned int 0x00000000, 
const unsigned short * 0x00000000) line 1115 + 42 bytes
InterceptStreamListener::OnStopRequest(InterceptStreamListener * const 
0x034da7c0, nsIChannel * 0x034cdac0, nsISupports * 0x00000000, unsigned int 
0x00000000, const unsigned short * 0x00000000) line 1155
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x034da7c0, unsigned int 
0x00000000, const unsigned short * 0x00000000) line 1586 + 36 bytes
nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x034de740, 
nsIChannel * 0x034cc8c4, nsISupports * 0x034cdac0, unsigned int 0x00000000, 
const unsigned short * 0x00000000) line 659
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x034c5a30) line 
307
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x034c59e0) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x034c59e0) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x010db510) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x04f00728, unsigned int 0x0000c0db, unsigned int 
0x00000000, long 0x010db510) line 1030 + 9 bytes
USER32! 77e713ed()
010db510()

Comment 29

[Judson Valeski]

definately not a necko issue. I see this same assert periodically; then it goes
away...

Comment 30

[gstoll]

http://www.mozillazine.org is fine...sorry about the confusion!

Comment 31

[don]

Dan, it looks like Bill and Jud are stumped here.  Can you help us out?

Comment 32

[Claudius Gayle]

this is a smoketest blocker and always was, so I've added the smoketest keyword and elevated the severity to 'blocker'.

Comment 33

[Peter Trudelle]

Using today's bits on Linux, I just loaded all the URLs in this bug report.  
The last one (mozillazine) stalled, but reloaded after I cancelled it.  I then 
crashed just selecting Open Web Location from the file menu.  I agree that this 
is dogfood, but I don't see why it is suddenly a smoketest blocker.  If we 
haven't kept the tree closed for this during the past 30 days, I don't think we 
are going to start now.  Lowering severity to critical. Claudius, if you have 
any reason to differ, lets discuss it.

Comment 34

[Peter Trudelle]

targetting M16, cc pavlov

Comment 35

[leger]

Per claudius..using May 23 build:
"not always with other url's (something to do with the redirect?). Trying to 
access the dialog for a second time has resulted in a crash for me twice today 
with today's linux bits - once with mozilla and once with commercial bits." 

Comment 36

[Dan M]

  Progress so far (too long for the status field): in short, I haven't solved it 
yet. I had a vain hope that it would be related to bug 35921, but that didn't 
work out. It seems this has something to do with a bad interaction between the 
http protocol handler and NSPR event handling.
  Notice that the page will load eventually: in my testing, I generally see the 
app stall for maybe thirty seconds, and then the page loads normally. This may be 
related to the often noted (though I can't find a bug for it at the moment) 
problem that Linux Mozilla seems to occasionally need nearly a minute to bring up 
a dialog. Sometimes page loads hang for a while. No one knows why yet.
  Notice also that this problem seems confined to the http protocol (ftp and file 
protocols don't have this problem for me), and also disappears if the Open Web 
Location dialog is made non-modal. Mysterious and icky. Nothing of substance to 
report.

Comment 37

[Peter Trudelle]

reassigning to pavlov

Comment 38

[Stuart Parmenter]

Attachment: patch that seems to fix the problem

Comment 39

[Brian Ryner (not reading)]

Marking fixed, pavlov checked in the fix on 5/30.

Comment 40

[sairuh (rarely reading bugmail)]

woohoo! verif using 2000.06.02.08 opt comm bits.