149360 - Javascript submit() chases MAP link instead

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Brandon Hume]

I am able to produce this bug both on custom-built Solaris builds and recent
(2002/06/31) Win32 nightlies.

Steps to produce:

    1. Go to above PC Banking URL
(https://www.pcbanking.cibc.com/english/servlet/SignOn)
    2. Use 0000000000000000 as the card number
    3. Use anything for a password
    4. Hit "Sign In"

You will not log in whether you have a valid password or not.  What WILL happen
is that you will end up at a completely different webpage, specifically
https://www.cibc.com/solution/service/pers/home.jsp?BV_UseBVCookie=Yes&locale=en_CA&fullFrame=
Which, if you back up and hover over the "HOME" image in the top right bar, you
will note that this is the destination of that link, which is part of a MAP/AREA.

Expected behavior: A screen on the same server telling you you've entered an
invalid card/password combination.

Comment 1

[Brandon Hume]

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

Comment 2

[Brandon Hume]

Er... meant 2002/05/31 nightlies, obviously.

Comment 3

[Dave]

I think this might be an invalid bug, because I am just not sure it is possible
to confirm that Mozilla is not doing exactly what it is supposed to do.  Here's why:

1)  They've put a notice on the page saying they're still testing with Netscape
6.2.X, and not to use it until they say it's kosher.  So it could be that the
form _does_ actually submit (Mozilla does what it's supposed to), but that the
server redirects users using Netscape 6.2.X (and any user agent calling itself
Mozilla 5 or above) to that "completely different webpage".  It seems like a
definite possibility that this is happening since they took the time to warn
users "not [to] upgrade your browser at this time" but to stay with Netscape 4.

2)  Here is the source where that linked image is:
<a href="javascript:if(validateForm()) document.SignOn.submit();">
   <img tabindex="3" alt="Sign On" src="/english/images/sign_on.gif" width="65"
height="16" border="0"></a>
It's an anchored link.  I do not see any reason to think that Mozilla is
confusing a click on this anchor-linked image with a click on an imagemap-linked
area in a completely different place in the document.  It is a likely
coincidence that the same URL to which Netscape 6.2.x (and Mozilla) users are
redirected would be the same as the URL that the "Home" link points to, don't
you think?

Someone correct me if this doesn't seem like a reasonable assessment.

Comment 4

[Brandon Hume]

When I use UABar with Mozilla, and spoof IE, it still behaves the same.  When I
employ konqueror, spoofing Mozilla, it DOES let me in.  Not that there aren't
other ways of browser sniffing, but if any is going on, its not doing it based
on the User-Agent string.

I should probably also mention that CIBC DID allow Mozilla users into the 
PC Banking service, up until about a month and a half ago.

It is quite reasonable to think that an "unacceptable" browser would be sent to
the Home link, though the site does present a warning if you do so using
unspoofed Konqueror, and one would HOPE that CIBC webmonkeys would know better
than to use silent failures... (far be it for me to attempt to fathom their
thought processes...)

I'm still looking into this myself to see if I can figure out what's going on.

Comment 5

[Brandon Hume]

OK, I finally managed to find a very old (November) build of Moz, and it behaves 
the same way.  I can't find further reason to think this is Moz's fault, sorry
about that.

Hopefully CIBC will take a less schitzo approach after the release of NS7.