Open Web Location won't load page, sometimes crashes



19 years ago
14 years ago


(Reporter: bugzilla, Assigned: pavlov)


(4 keywords)

crash, platform-parity, regression, smoketest
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [dogfood+] ETA 6/1)


(1 attachment)



19 years ago
tested using the opt comm m16 bit on linux (will test other platforms soon),

1. select File > Open Web Location to bring up dialog.
2. enter a url, eg, or or
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:


 Call Stack:    (Signature = nsHTTPServerListener::OnDataAvailable() aa902f2d) 
                                                + 0x1700b (0x407c000b) 
                                                + 0xfbe6 (0x407edbe6) 
                                                + 0x101a1 (0x407ee1a1) 
                                                + 0x10341 (0x407ee341) 
                                                + 0x8c209 (0x40715209) 
                                                + 0x181eb (0x402f21eb)


19 years ago
Keywords: crash, smoketest

Comment 1

19 years ago
don't see this on the Mac and winNT m16 comm bits today.
Severity: critical → blocker
Keywords: pp
Hardware: PC → Other

Comment 2

19 years ago
I"m seeing intermittent crashes loading pages from personal toolbar bookmarks
too, on win98.  should that be a separate bug?
this doesn't look like a bug for bill...crash is in netlib.

Comment 4

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

Comment 5

19 years ago
peter, did you get a trace or talkback report?

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

Comment 6

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

Comment 7

19 years ago
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.
Assignee: law → ruslan

Comment 8

19 years ago
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

19 years ago
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

19 years ago
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 
it seems always to succeed, given patience. but i doubt that's the whole problem.

Comment 11

19 years ago
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.
Severity: blocker → critical
Keywords: smoketest → dogfood

Comment 12

19 years ago
Does it work with file cache disabled? David, if you don't think it's cache - 
reassign it back to me.
Assignee: ruslan → davidm

Comment 13

19 years ago
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

19 years ago
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 Sometimes it loads quickly. 
This seems independent of ruslan's changes.

Comment 15

19 years ago
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

19 years ago
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
Assignee: davidm → ruslan

Comment 17

19 years ago
Putting on [dogfood+] radar.
Whiteboard: [dogfood+]

Comment 18

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

Comment 19

19 years ago
My crashes look different, will open another bug.


19 years ago
Target Milestone: --- → M16

Comment 20

19 years ago
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.
Assignee: ruslan → troy

Comment 21

19 years ago
If I type in the url bar I crash every time because the js 
script context is null.

Comment 22

19 years ago
I don't see anything that suggests layout here so reassigning back to component 
Assignee: troy → don

Comment 23

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


19 years ago
Depends on: 35181

Comment 24

19 years ago
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."

Comment 25

19 years ago
i know this is already marked dogfood, but am adding the beta2 kw, as this is a
purty basic thang.
Keywords: nsbeta2, regression

Comment 26

19 years ago
Is 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

19 years ago
Bill, who should get this bug?
Assignee: don → law
Priority: P3 → P1

Comment 28

19 years ago
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

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 
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()
Assignee: law → don

Comment 29

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

Comment 30

19 years ago is fine...sorry about the confusion!

Comment 31

19 years ago
Dan, it looks like Bill and Jud are stumped here.  Can you help us out?
Assignee: don → danm
Component: XPApps → Browser-General
Target Milestone: M16 → ---

Comment 32

19 years ago
this is a smoketest blocker and always was, so I've added the smoketest keyword and elevated the severity to 'blocker'.
Severity: critical → blocker
Keywords: smoketest

Comment 33

19 years ago
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.
Severity: blocker → critical


19 years ago
Whiteboard: [dogfood+] → [dogfood+] investigating. no ETA.

Comment 34

19 years ago
targetting M16, cc pavlov
Target Milestone: --- → M16


19 years ago
Blocks: 40158

Comment 35

19 years ago
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

19 years ago
  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 
Whiteboard: [dogfood+] investigating. no ETA. → [dogfood+] investigating. see comments for 28.May

Comment 37

19 years ago
reassigning to pavlov
Assignee: danm → pavlov
Whiteboard: [dogfood+] investigating. see comments for 28.May → [dogfood+] NEED ETA (mm/dd)


19 years ago
Whiteboard: [dogfood+] NEED ETA (mm/dd) → [dogfood+] ETA 6/1

Comment 38

19 years ago
Created attachment 9362 [details] [diff] [review]
patch that seems to fix the problem
Marking fixed, pavlov checked in the fix on 5/30.
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 40

19 years ago
woohoo! verif using 2000.06.02.08 opt comm bits.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.