The Basics: if you open your webmail account with Netscape and you hit the "Get Mail" link in the navbar all of your open Mozilla windows will become unresponsive, completely locked up. steps to reproduce: 1. log into Netscape webmail (or load the simplified testcase attached below). 2. click on the "Get Mail" link in the navigation panel on the left of the page. (or click the "Get Mozillazine" link in the testcase) Actual Results: any Mozilla windows that are open will lcok up and become unresponsive. Expected Results: New mail (or Mozillazine.org in the testcase) should be loaded. Builds tested on: win32 build 2000042109 under NT and 98 additional information. This bug has been around for a while but I couldn't distinguish it from bug 34217 until that was fixed yesterday. This testcase works fine in Navigator 4.x under win98

Reproducable on Linux 2000-04-21-08 via test case. Changing OS to "All". The following message appears on the console right before the browser freezes: Error loading URL http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7822

This is freezing up my build. I'm running winNT build 2000042416.

OK, webmail.netscape.com works now but the testcase still fails (locks the browser) webmail must have updated their link. Keeping this open until the testcase works. Updating summary to reflect that it no longer happens at netscape webmail.

OK, somehow it worked a few times and now it's not working again. netwcape has not changed the link and it again locks me up. adding URL again and updating summary field.

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

from bug 37432 ruslan@netscape.com writes: Steps to reproduce: log into webmail.netscape.com Click on "Get Mail" (left frame) the browser will hang, reporting an assertion: ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(aURL->GetHost(getter_Copies(host)) )) failed: '(!((aURL->GetHost(getter_Copies(host))) & 0x80000000))', file c:\bui lds\mozilla\mozilla\webshell\src\nsWebShell.cpp, line 1206 Today's builds on both: NT and Linux

leger, I'd like to nominate this for dogfood. I do all my bugzilla email in netscape webmail and this effectively puts a stop to my using mozilla to do work.

This bug seems to affect lots of javascript: urls.

OK, the link at webmail works intermittantly but the testcase still fails consistently. Not sure what's up there but it is a real showstopper for me since I manage all of my bugs through webmail.

There's no way I'll get to this before the the M16 tree closure, if this needs to be resolved before that we'll need to get someone else to look into it, I'm to busy with adding new DOM features for the feature freeze on 5/16.

OK, it seems like I'm the only one that cares anyways. Maybe I can convince the Netcenter or Usa.net folks to make a change. If not I'll wait.

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

When mozilla, is locked, you can interrupt it with Ctrl-C. If you are running in gdb, you can switch to thread 2 and get a backtrace. It's the same as the one in bug 37463 (and its duplicates), and the assertion mentioned here is mentioned there, too.

Marking nsbeta2.

This is needed for beta2, given the lockup; giving PDT approval.

The following patch fixes a crash I saw associated with javascript: URLs and the fact that javascript: URLs are sometimes invoked multiple times. The remaining problems are addressed by bug 31818. Index: nsJSProtocolHandler.cpp =================================================================== RCS file: /cvsroot/mozilla/dom/src/jsurl/nsJSProtocolHandler.cpp,v retrieving revision 1.46 diff -r1.46 nsJSProtocolHandler.cpp 288c288,294 < *aInputStream = str; --- > if (NS_SUCCEEDED(rv)) { > mResult = nsnull; // XXX Whackiness. The input stream takes owners hip > *aInputStream = str; > } > else { > *aInputStream = nsnull; > } 411a418,422 > // If the resultant script evaluation actually does return a > // value, we treat it as html. > if (NS_SUCCEEDED(rv)) { > rv = channel->SetContentType("text/html"); >

I just checked in Vidurs patch that fixes part of this problem, the rest of this bug should be coverd by bug 31818 so I'm marking this as a dup of that bug. *** This bug has been marked as a duplicate of 31818 ***

Dup. Verified.

This is happening again. adding dogfood and regression keyword. the testcase locks mozilla.

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

How does this differ from bug 37463 (which has become the general catch-all for javascript: freeze problems)?

This is most likely due to the same problem as reported in bug 37463 but I'm unable to even get far enough with mozilla to see the lock since I can't load webmail.netscape.com at all on linux, I only get a blank page, if I grab the url for the login page from 4.x I get the login page but pressing login just says error loading url: http://ureg.netscape.com/iiop/UReg2/login/login?U2_LA=en&U2_BACK_FROM_CJ=true&U2_CS=iso-8859-1&U2_ENDURL=http://mailredirect.netscape.com/&U2_NEW_ENDURL=http://mailredirect.netscape.com/?nu=1&U2_EXITURL=http://home.netscape.com/&U2_SOURCE=Webmail I can successfully load the above url in 4.x but not in mozilla. Over to gagan for investigation, looks like this could be a necko problem. Gagan, please pass this back to me if this is not a network problem or once the network problem is fixed...

Putting on [dogfood-] radar. Mauria, can we get webmail engineers to fix this on the server side?

Taking this back since the network problem was fixed (bug 43958).

I'm closing this as fixed since netscape webmail is now useable and the lockup that happens when loading the attached testcase is coverd by bug 37463 (nsbeta2+). I was able to lock up mozilla when using the address book in netscape mail but that's due to the same problem (bug 37463). If someone still sees lockups on webmail.netscape.com after bug 37463 is fixed then please reopen this bug.

Thanks jst. Actually, I guess this would really be just a dup of 37463 now...that's what it was originally, it was just temporarily overshadowed by 43958, which has been fixed (and is marked as such). going to reopen and mark dup of 37463, and removing some people from the cc list who I assume no longer care to hear about this (sorry if my assumption is incorrect)...

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

Verified Duplicate.