[layers] WellsFargo on-line: recent login page regression



18 years ago
4 years ago


(Reporter: piskozub, Assigned: arun)






18 years ago
Wells-Fargo changed its login page. The present one is later dependant and takes
Mozilla for N4.*. It is impossible to login to "Main menu".

JavaScript console gives the following:
Error: this.document.layers has no properties
Source File: http://www.wellsfargo.com/dhtml_menu.js
Line: 41

I'm aware about the (connected) WellsFargo bugs: 
bug 57537 - log into WellsFargo (browser sniffing) 
bug 60891 - wellsfargo.com - [document.layers] Page not rendered properly 
bug 87351 [layers] wellsfargo.com - Tooltips on page obscure links
but I still believe this one is something new as WellsFargo is again impossible
to log in after a god month or two when everything worked. On the other hand,
you may make it a dup of bug 57537 if you want.

Comment 1

18 years ago
Actually, this is NOT a dup of bug 57537 .  This is a distinct bug only present
on the Mozilla Trunk builds (download a nightly trunk).  This weirdness isn't
present in N6.1 PR1 or any Mozilla 0.9.2 build.  I'm CC'ing Pollmann for any
words of wisdom on this matter. pollmann: suddenly, why is the browser choking
on layers issues without progressing further?  Sorry if you aren't the right
person to ping about this, since this isn't (directly) form related :-\

Comment 2

18 years ago
whoops, cc'ing pollmann for real, like i said above.

Comment 3

18 years ago
I should have added that I reported the bug based on Win32 trunk installer
2001080703 build (WindowsME).

Comment 4

18 years ago
> why is the browser choking on layers issues without progressing further?

I have to guess this is a server-side problem with their client detection
(perhaps they are doing user-agent sniffing that is too specific in assuming
that the Mozilla user agent string must look like a Netscape user agent string?)

On the bright side, I just tried with my tip CVS build, and am not having any
problems logging in at http://banking.wellsfargo.com.

As for the JS errors, the fix for this really should be doine on the server
side.  I noticed the same errors on the main page, http://www.wellsfargo.com:
  Error: this.document.layers has no properties
  Source File: http://www.wellsfargo.com/dhtml_menu.js

The code in this file will not work for Netscape 6, regardless if it is treated
as IE or Nav, as it requires either top.document.all or this.document.layers. 
Note that it is not far from being able to work in Netscape 6 (and, of course,
Mozilla).  First, we need to be treated largely as IE, second, IE's proprietary
document.all is not implemented in Moz/Netscape.  The work should probably start

 //IE Routing 
  if (ie4) {    
    var showRef="visible";
    var hideRef="hidden";
    var layerRef="top.document.all";
    var layerSwitch="";
    var styleSwitch=".style";
    var leftPos = 0;
  //Netscape Routing
    var showRef="show";
    var hideRef="hide";
    var hidepf="no";	
    var layerRef="this.document.layers";
    var layerSwitch="";
    var styleSwitch="";
    var leftPos = 0;

A few good resources (client detection and how to get rid of document.all/
document.layers are linked off of here:

Comment 5

18 years ago
My  CVS build (WindowsME) cannot even enter the page. That is nothing happens
both with clicking the link or with entering the URL directly. BTW, it is
https://banking.wellsfargo.com/ (not http://...)

Comment 6

18 years ago
Jacek, did you build with https enabled?


Comment 7

18 years ago
Yes, I build with PSM2. But I changed one security setting too much (certificate

WFM with fresh CVS build as well as Win32 installer buld 20010803. I'm for
changing this bug to FIXED/WORKSFORME. Not invalid, as it really had some layout
problems with recent builds.

BTW. the URL *is* https://banking.wellsfargo.com/

Comment 8

18 years ago
Eric, everything that you say is true, and I've diagnosed the LAYER problems. 
The question is, why is this causing recent trunk builds to choke in extremis
but not for example N6.1?  (or 0.9.2 branch builds)?

Comment 9

18 years ago
The recent trunk build I pulled from CVS worked - I'll pull one from
mozilla.org's ftp to see if I can reproduce the problem.  Are you seeing 'click
on button, nothing happens', as described above?

Comment 10

18 years ago
I reported WFM on 8/8 20:44 but now, on another computer I still see the orginal
behavior with 2001080904 trunk installer build. Both computers are WindowsME
with a very similar configuration. I do not know what creates the difference in
response (one sees the button, one does not). 

The "no response" problem was bad combination of pref settings. I stated already
so in my 8/8/ 20:44 comment.

Comment 11

18 years ago
OK. Mystery solved. The reason I could not see the buttons is the using of links
to the button images as follows:

Damn! The a248.e.akamai.net host was on my image deny list :-( Sorry for the
spam but using an advertising site for images on a banking page is so surprising
to me that I did not check that before.

If no one has seen the behavior (and I now doubt anyone could, unless (s)he fell
into the same trap) this is clearly an INVALID bug. Marking as such. If anyone
disagres, please reopen.
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 12

18 years ago
Just tried with a daily trunk build (commercial) and also could not reproduce
login problems at http://banking.wellsfargo.com  Arun, are you still seeing this
problem with the latest builds?

Comment 13

18 years ago
Also just tried a daily trunk build (mozilla) and could not reproduce login
problems at http://banking.wellsfargo.com/

Comment 14

18 years ago
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified

Comment 15

17 years ago
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.