Closed Bug 8310 Opened 21 years ago Closed 20 years ago

Severe Javascript errors using Netscape Messenger Express

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P1, critical)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: richmond, Assigned: joki)

References

()

Details

(Whiteboard: [nsbeta2-])

Messenger express is an e-mail client written completely in Javascript. It
works on IE >= 3 and Navigator >= 3.01, but fails to even login with any
version of mozilla over the past several months. This app probably stresses
Javascript functionality more than anything else on the net.

The login page has some simple Javascript to deal with form submission and
password clearing. Basic tab and return keys fail to work on this page but
mouse manipulation can execute a post to "login.msc". This is supposed to
return an HTTP redirect to "en/mail.html" that is a frameset with 4 invisible
frames for data and one for the UI. This does not work and I get a blank screen
instead. As the initial frameset loads, the screen should show "loading please
wait". Invisible frames should then be loaded with javascript objects from
Netscape's messaging server(via onLoad() handler) and the UI is then completely
constructed with client-side JS. No UI elements are designed on the server.

msg54.mcom.com is an internal Netscape server. One external site is
www.olemail.com(spanish), and let me know if you need another site for testing.
Assignee: leger → mccabe
Component: JavaScript → Javascript Engine
QA Contact: leger → cbegle
Moving to Javascript Engine component.
richmond...Javascript component is being retired shortly.  Please use Javascript
Engine for JS component bugs.

cbegle, is this for your folks?
QA Contact: cbegle → gerardok
this is event stuff.
Assignee: mccabe → joki
Component: Javascript Engine → Event Handling
QA Contact: gerardok → janc
Priority: P3 → P1
Setting priority(forgot to do it at first?). ME has sold several multi-million
seat deals to Europe and Canada that are now deploying so this will be a
popular problem. I will file separate bugs once basic login and startup works.
Severity: blocker → critical
Summary: Javascript non-functional in complex application → Javascript error
Whiteboard: TESTCASE
<SELECT NAME="language_select" SIZE="1"
ONCHANGE="window.open(this.options[this.selectedIndex].value,'_top');
language_select.options[0].selected=true">

shows
JavaScript error: language_select is not defined
Summary: Javascript error → Severe Javascript errors using Netscape Messenger Express
The comment from skliaroukp@geocities.com is nonsensical and must apply to some
other bug
Depends on: 9346
Depends on: 9347
Depends on: 4279
No longer depends on: 9346
Depends on: 9472, 9477
Making more progress. Location.search is not updated on HTTP redirects and
location.replace() is broken in viewer.exe
Still cannot log in.  rls@netscape.com is investigating.
Whiteboard: TESTCASE
Removing TESTCASE from Status as there is no test case attached. If none is
needed, mark [DONTTEST]. (please always use brackets--thanks!)
Login is now working with M12, but logout is broken:

JavaScript Error: TypeError: this.hdl.close is not a function

Folks within Netscape can try it out against vadar.mcom.com, userid "x" password
"x".
Also, the tab key is not working for moving the cursor from the "username" field
to the "Password" field, and the enter key is not working for submitting the
form.
marking beta1

Keywords: beta1
Whiteboard: [PDT-]
Marking 4xp.
Keywords: 4xp
Depends on: 27014
Whiteboard: [PDT-] → [PDT-] waiting for iPlanet to deploy fix to 384993
I can login with todays build.

The tab key now moving the cursor from the "username" field to the "Password" 
field, and the enter key is now working for submitting the form.

The page does not load however. After submitting the form the page goes blank, 
this sounds like it will be addressed by bug 9472 that this bug depends on.
Setting m17 milestone
Target Milestone: M17
Depends on: 27048
*** Bug 32631 has been marked as a duplicate of this bug. ***
adding beta2 keyword, and removing pdt status
Keywords: beta2
Whiteboard: [PDT-] waiting for iPlanet to deploy fix to 384993 → waiting for iPlanet to deploy fix to 384993
removing beta1 keyword so it doesn't show up on beta1 radar
Keywords: beta1
Keywords: nsbeta2
richmond, 384993 was fixed on 04/03.  Can you check to see if this is still an 
open bug for you?  Thanks!
Keywords: beta2
Whiteboard: waiting for iPlanet to deploy fix to 384993 → [NEED INFO]waiting for iPlanet to deploy fix to 384993
We can't retest until the lab move to Santa Clara is complete.  I should 
hopefully be able to test this by the end of next week.
Putting on [nsbeta2-] radar. Not critical to beta2, gagan expects a fix soon 
anyway.
Whiteboard: [NEED INFO]waiting for iPlanet to deploy fix to 384993 → [nsbeta2-]waiting for iPlanet to deploy fix to 384993
This seems to be working now, modulo the unqualified-domain issue covered by 
bug 39386

To test, try we-gotmail.red.iplanet.com:80 with userid mozilla1 password 
mozilla1. (only accessable from Netscape and Iplanet).
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Whiteboard: [nsbeta2-]waiting for iPlanet to deploy fix to 384993 → [nsbeta2-]
Can't test.
I went to the site we-gotmail.red.iplanet.com:80 and used the login/password of 
mozilla1 and get "Invalid username or password"

Is there some other way to test this?
Argh, they keep nuking the test accounts.  Will get them recreated.
Whiteboard: [nsbeta2-] → [nsbeta2-] Awaiting recreation of site...
Whiteboard: [nsbeta2-] Awaiting recreation of site... → [nsbeta2-]
Crashed Win98 
2000-06-28-21-M17
Talkback report:  13367340

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Can you please see if this is working properly now, what problems remain? I can
log in and a 20 sec fooling around did not crash the browser nor did I find
anything that does not work. Hmm, seems like there is still bug 27048 that this
depends on, but didn't check what this affects.
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Haven't tested myself, but per above comments, marking WORKSFORME. Adding
verifyme keyword--verifiers please pound on this and make sure the problem is
really, truly gone. Thanks!

Also nominating nsbeta3 for correctness because if the problem *isn't* fixed,
it's an nsbeta3 stopper as it blocks usage of Messenger Express.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
Updating QA Contact.
QA Contact: ckritzer → lorca
Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
QA contact updated
QA Contact: gerardok → madhur
verified on build 2001-07-11-trunk
Status: RESOLVED → VERIFIED
Keywords: verifyme
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.