Closed Bug 69586 Opened 24 years ago Closed 23 years ago

crash loading webpage after closing sidebar

Categories

(SeaMonkey :: General, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME
mozilla0.9.1

People

(Reporter: danm.moz, Assigned: danm.moz)

Details

(Keywords: qawanted)

I have no idea who to give this to. I don't particularly want it. But I guess 
I'll hold onto it for the nonce.

1) Launch Mozilla browser with sidebar visible
2) Close the sidebar (View->My Sidebar)
3) Type something into the URL bar (http://www.mozilla.org, say) and hit return

All steps are necessary: there's no problem working with a window opened with the 
sidebar already hidden.

The first sign of trouble comes with an assertion in the JS engine. Power through 
it and eventually, you crash. I'll concentrate on the assertion, which has enough 
going wrong with it to make me think it's worth concentrating on.

The assertion complains that the JS engine is being asked to allocate a new 
JSObject while the JS GC is running. Way up on the stack, an nsGlobalWindow is 
being given a new mDocument (SetNewDocument()), which is causing a GC on the old 
mContext. Frames and views are consequently destroyed. One of the views destroys 
its native HWND window. This sends a WM_SETFOCUS message directly to another 
window, without going through the message queue. This other window, processing 
the focus message, eventually calls a JS event handler and mayhem ensues.

Ick. The moral is, don't be processing events that could have JS event handlers 
while the GC is running. Easier preached than stopped. It seems like this could 
be a more widespread problem than it appears to be. It may be happening because 
closing the sidebar leaves an unusual focus state in the browser window. (It's 
closed by setting frames' "hidden" attribute.) But there does seem to be a more 
general worry here.
Brendan wanted me to add jband and himself to the cc: list on this bug, because 
I'm planning on exercising nothing but my butt on this one for now. John: here's 
a possible argument for teaching the JS runtime to allocate new objects while in 
the garbage collector.
->mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
adding qawanted keyword: is this still reproducible?  Are there any symptoms in
optimized builds?
Keywords: qawanted
Severity: major → critical
I get this on 0.8, 0.8.1 and current nightlies (Linux, Win NT and 2000), but
only with my own sidebar code, if I havn't used the code then the browser will
stay up until I close a window, but I get
"Error loading URL <url>: 2152398850"
every time I click on a link, and no pages or images will display.

If I have been using the sidebar code then the browser segfaults instantly.

My code is similar to the "What's related" code, but is much bigger.

I am happy to answer any questions and can provide a copy of the code if it will
help.
Forgot to add, closing a window with my sidebar visible will put it into the
same state.
Sorry, for the quantity of messages.

I have narrowed the source of the problem down to my use of:

@mozilla.org/scriptableinputstream;1 ,
@mozilla.org/network/standard-url;1 or
@mozilla.org/network/io-service;1 

Full source is visible at:
http://inanna.ecs.soton.ac.uk/~swh/net.txt

If I don't call the newDownload() function then there is no crash.
The bug as originally described no longer happens. There have been a lot of 
bizarre changes to the behaviour of WM_SETFOCUS lately. Maybe one of those killed 
the inopportune focus message or its handler. Yeah sure. Anyway, it no longer 
crashes. Not much I can do with it then but close it.

Stephen: for starters, you'll have to grab a more recent build. I'd suggest 
tomorrow morning's nightly (or morningly). If it's not too unstable for other 
reasons. This bug has disappeared and it was some time much later than 0.8.1. 
With any luck, your problem will have been fixed, too. If not, please open a new 
bug, supply your sidebar source in the bug and give step-by-steps for dummies 
(I've never written a sidebar, so I'm a dummy). We'll take a look. I have to say 
that it'll be low priority for us, though, since while it's no doubt a bug in our 
code, it's not exercised by code in the release we're currently running ourselves 
ragged over.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
If its low priority then, please, don't worry. I'm using XMLExtras now, which is
stable and much better.

Thanks,
   Steve
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.