183138 - JavaScript URIs when used with <form>s don't execute as expected

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[u4664]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2.1) Gecko/20021130

In my bank's Web site (www.uwcu.org), after entering my account number and
password, I'm presented with a page where I can manage my account. All of the
links there use "javascript:" type URIs. In Mozilla 1.2b, the links worked as
expected, but in 1.2 and 1.2.1, they don't work, instead I get JavaScript errors
(as shown in the JavaScript Console) such as "document.History has no
properties" or "document.menu_link has no properties" (see attached file for
what these document.XXX are).

I've looked through the source code and it seems that the JavaScripts work in
conjunction with <form>s (look for "<!-- General Form - Menu Links -->" in the
attached file), so something may be broken in the communication there.

I've attached the (HTML?) file for the main page (obtained through View Source)
that I see after entering my account number and password (personal/sensitive
information have been changed to something between "<<" and ">>"). I can't
access an .js and .css files that are used by this file.

Reproducible: Always

Steps to Reproduce:
1. Log on to https://webbranch.uwcu.org
2. Try clicking on any link.
3.
Actual Results:  
Nothing happens.

Expected Results:  
Each link should take me to a different section to manage my bank account.

Comment 1

[u4664]

Attachment: The (HTML?) file of the main accounts page.

Personal/sensitive information has been changed to something enclosed by "<<"
and ">>".

Comment 2

[Phil Schwartau]

This sounds similar to bug 183199
"Rollover pop-up menus fail, but only on MacOS X platform (AFAIK)"

That was also filed on OSX, and on the 1.2 and 1.2.1 branches.
Note we had to release 1.2.1 to correct a bad problem in 1.2
that affected every platform. See bug 182500.

Reassigning to Browser-General until we can get more information.                                                                                            

[e-mail]:

1. Does the site fail on OSX with TRUNK Mozilla builds, also?
2. Does the site fail on Windows or Linux, too? Or just OSX?

Comment 3

[u4664]

I don't have access to a Linux box. I use OS X (Jaguar) at home and Win2K at
work. At work, I tried going to the Web site with Mozilla 1.2.1 and encountered
the same problem. But I wanted to try a Jaguar trunk build before adding this
comment, so I waited till I returned home.

I got today's (12/3/02) trunk build and went to the Web site. That's when I
discovered a pattern. The first time I accessed it, the JavaScripts didn't work.
So I used the Back button to go back to the login page and re-logged in. This
time, the JavaScripts worked.

I reverted back to 1.2.1 and tried the same thing: login, go back, login again.
As before, the JavaScripts worked. I thought the trunk build had modified my
preferences or something, so I started Mozilla with a new profile and accessed
the Web site. Same thing: after going back and logging in again, the JavaScripts
worked.

Using my old profile, I used the trunk build to access the Web site and now the
JavaScripts worked at the first login. I switched back to 1.2.1 and the same
thing happened: the JavaScripts worked at the first login.

I'm pretty sure I tried the "go back and re-login" technique before I filed my
first bug report, so this new development baffles me. At first, I thought it was
because of the trunk build, but if so, then how was 1.2.1 able to work with a
new profile too? I'm puzzled by this.

Anyway, I seem to be able to use my bank's Web site with no problem now.

I've noticed at other Web sites, e.g. Amazon.com, that JavaScripts wouldn't work
if the page wasn't fully loaded before the user activated a JavaScript. It
doesn't seem to be the case here since I left the page idle for a long time to
ensure that it was fully loaded. But it might be a clue.