58101 - can't use MessengerExpress with NS6

Status: VERIFIED WONTFIX

(Tech Evangelism Graveyard :: English US, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

try logging into http://nsmail-2 or http://nsmail-1.mcom.com. after entering
your username and password, the screen changes to "Loading, please wait" then
stalls.

Win32 shows a JS error dialog, mac doesn't. Neither ever progress pass this screen.

Comment 1

[selmer (gone)]

What's the JS error?  Can this be reproduced on any other site?

Comment 2

[Phil Peterson]

PDT marking [rtm-]. Messenger Express won't be frequently encountered by end users.

Comment 3

[Gagan]

I don't think this is networking. Here is the JS error that I get-- 

JavaScript Error
undefined, Line undefined. 
[object KeyEvent]

off to JS land... 

Comment 4

[Phil Schwartau]

Confirming with Mozilla builds on WinNT, Linux 2001-03-12, 2001-03-13.
I try to log on to http://nsmail-1.mcom.com, but it just hangs...



Here is the stacktrace I got by interrupting on Linux: 

(gdb) bt
#0  0x40410320 in __poll (fds=0x87a09c0, nfds=3, timeout=9) at
../sysdeps/unix/sysv/linux/poll.c:45
#1  0x409c35d1 in g_main_poll () from /usr/lib/libglib-1.2.so.0
#2  0x409c2fce in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#3  0x409c3341 in g_main_run () from /usr/lib/libglib-1.2.so.0
#4  0x408ed209 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#5  0x407f86da in nsAppShell::Run (this=0x80b8258) at nsAppShell.cpp:350
#6  0x405ce2b4 in nsAppShellService::Run (this=0x80b5b68) at                    
nsAppShellService.cpp:407
#7  0x8056fcb in main1 (argc=1, argv=0xbffffb54, nativeApp=0x0) at 
nsAppRunner.cpp:1004
#8  0x8057cba in main (argc=1, argv=0xbffffb54) at nsAppRunner.cpp:1298




This does not appear to be an issue for the JS Engine. Reassigning 
to Embedding: Docshell for further triage. This may have something 
to do with Security as well. On WinNT, I'm actually getting a memory
exception from Personal Security Manager when I try this...

Comment 5

[Adam Lock]

I don't think this has anything to do with embedding. More likely it's a problem 
with the complicated Javascript that this page seems to contain.

I'm bouncing back the JS group and attaching the JS files for examination.

Comment 6

[Adam Lock]

Attachment: Browser sniffer code

Comment 7

[Adam Lock]

Attachment: Internationalization code

Comment 8

[Adam Lock]

Attachment: Utility code

Comment 9

[Adam Lock]

Attachment: The "Please loading" main frame HTML

Comment 10

[Phil Schwartau]

Still happening with Linux, WinNT debug builds 2001-03-22.
Here is the stacktrace I get by interrupting on WinNT: 


NTDLL! 77f6829b()
KERNEL32! 77f04f41()
_PR_WaitCondVar(PRThread * 0x068121b0, PRCondVar * 0x01645a70, PRLock * 
                      0x01645b20, unsigned int 4294967295) line 185 + 23 bytes
PR_WaitCondVar(PRCondVar * 0x01645a70, unsigned int 4294967295) line 532 + 23 
                                                                         bytes
nsThreadPool::GetRequest(nsIThread * 0x068123d0) line 586 + 15 bytes
nsThreadPoolRunnable::Run(nsThreadPoolRunnable * const 0x06812420) line 814 + 27 
                                                                         bytes
nsThread::Main(void * 0x068123d0) line 106 + 26 bytes
_PR_NativeRunThread(void * 0x068121b0) line 399 + 13 bytes
_threadstartex(void * 0x068120b0) line 212 + 13 bytes
KERNEL32! 77f04ee8()

Comment 11

[Phil Schwartau]

OOPS! IGNORE THAT LAST WINNT STACKTRACE!

There is another problem infecting the trace above: for some reason, 
with my WinNT 2001-03-22 debug build, every time I try to access 


                    http://nsmail-1.mcom.com
or                  http://nsmail-2.mcom.com,


Mozilla causes NN4.7 to launch! I don't know why this is happening. 
If I hit "Cancel" in NN4.7 and return to Mozilla, and then interrupt
Mozilla via Visual C++ to get the trace, I get the stuff I pasted above.
But it probably has more to do with the mysterious call to NN4.7 than
with this bug. So I've tried something different: 


                    http://nsmail-3.mcom.com


I get to this site successfully in Mozilla! There, I click on
"Netscape Messenger Express". I then get the Messenger Express login
page (in Mozilla instead of NN4.7). When I try to log in, Mozilla 
hangs, as reported. When I interrupt it via Visual C++, I get this trace:



USER32! 77e72ada()
nsAppShellService::Run(nsAppShellService * const 0x00ae7950) line 408
main1(int 1, char * * 0x00a25fc0, nsISupports * 0x00000000) line 1004 + 32 bytes
main(int 1, char * * 0x00a25fc0) line 1298 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77f1ba06()

Comment 12

[Phil Schwartau]

Further notes: using same steps on WinNT as at 2001-03-23 11:10 above.
That is, I'm going to  http://nsmail-3.mcom.com and logging in to 
Messenger Express from my debug WinNT build.


There are no useful messages in the debug console when Mozilla starts
to hang. Just "Enabling Quirk Stylesheet", etc. 


At this point, we just see "Loading: Please wait..." against a white 
background, with the browser hanging. The following is now in the URL bar:

http://yoda.mcom.com:81/en/mail.html?sid=n3bv9bx98xn3r62o&lang=en&host=http://yo
da.mcom.com:81/&cert=false


If I click the "X" button to stop the load, and hit the Reload button,
I do not hang immediately as above. I get the alertbox Gagan reported above: 


                    JavaScript Error
                    undefined, Line undefined. 
                    [object KeyEvent]


Once I dismiss this, Mozilla hangs as before. Only now, there are some
interesting messages in the debug console: 


JavaScript error:
line 0: uncaught exception: 
Exception..."Too few parameters to method'
code:  1008
nsresult: NS_ERROR_DOM_TOO_FEW_PARAMETERS_ERR
location: http://yoda.mcom.com:81/main.js
Line 1376

Error was suppressed by event handler

Document http://yoda.mcom.com;81/en/mail.html?sid=  etc. etc.  
loaded succesfully

Comment 13

[Phil Schwartau]

Note http://yoda.mcom.com:81/main.js is the utility file that Adam
attached above (id=27813). Below is line 1376, where the error occurs: 



function start() {
  if (self.cfgFrame == null || self.mboxFrame == null || self.msgFrame == null) 
{
    window.setTimeout('start()', 100)
  } else if (state == 'init') {
    setFrames()
    if (NN >= 3)
      clearTimeout()    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Line 1376
    state = 'load'
    refreshing = false
    refreshCfg()
  }
}

Comment 14

[Phil Schwartau]

For bugs involving a similar mistake, see: 

                        bug 59605
                        bug 56799


These are slightly different in that they involved calling                    
clearTimeout(TimeoutID) where TimeoutID was uninitialized.
In this bug, the mistake is calling clearTimeout() with no
parameter provided whatsoever.

In NN4.7 both of these behaviors were tolerated, as you can 
see by typing these examples in the URL bar: 


          javascript: var TimeoutID; clearTimeout(TimeoutID);
          javascript: clearTimeout();


In NN4.7 you will see no errors in the JavaScript Console;
in Mozilla you will.

Comment 15

[Phil Schwartau]

I do not know if the clearTimeout() error above would cause Mozilla
to hang; I don't think so. What might be possible is this: since the
start() function calls itself recursively (see 2001-03-23 11:55 above),
it may be getting itself into an infinite loop. 


Before anyone spends any more time on this, we need to have someone 
debug the HTML/JavaScript at this site. The most likely explanation
for the behavior we are experiencing are mistakes in the code. 


I see no indication of any bug in JavaScript Engine. Reassigning to 
Browser-General for advice. I would reassign to Evangelism, except
that the site in question is our own! So what do we do in this case? 

Comment 16

[Conor Lennon]

The issue of calling clearTimeout with no arguments is covered by Bug 76603

Comment 17

[Conor Lennon]

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

Comment 18

[Asa Dotzler [:asa]]

evangelism

Comment 19

[Bob Clary [:bc] (inactive)]

nscp internal -> bugscape
see http://bugscape.mcom.com/show_bug.cgi?id=7188
-> wontfix

Comment 20

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.

Comment 21

[Phil Schwartau]

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

Comment 22

[Phil Schwartau]

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

Comment 23

[Phil Schwartau]

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

Comment 24

[Phil Schwartau]

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

Comment 25

[Brant Gurganus]

Verified per instructions at http://mozilla-evangelism.bclary.com/evangelism.html

Comment 26

[Phil Schwartau]

Note: in bug 144197, "Error upon loading Netscape internal mail web site",
filed against http://nsmail-1.netscape.com/, a user is getting an alertbox
containing: 

   Not enough arguments [nsIDOMWindowInternal.clearTimeout]
   nsresult: "0x80570001 [NS_ERROR_XPC_NOT_ENOUGH_ARGS]"
   location: "JS Frame :: https://judge.mcom.com/main.js :: start :: line 1376"
   data: no


Note calling clearTimeout() without providing an argument used to
cause an exception in Mozilla. But in bug 132904, "Clearing timeout
without setting one & without passing timeoutID throws exception",
we changed our behavior so that no exception would be thrown on this.

Why this is appearing in a popup is as yet undetermined.