- Go to http://www.wellsfargo.com - Click "Sign On" (in the top right corner) ==> You get a page saying " YOU MUST UPGRADE YOUR BROWSER" Their list of approved browsers is: http://www.wellsfargo.com/per/services/browser/chart/ Assigned to ekrock because that can't be fixed without some serious talking with them (and testing on their side too, I guess).

Same problem with 2000-10-20-09 trunk on Linux. According to their list of supported browsers, they simply don't support mozilla. Platform->All, OS->All.

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

As I indicated in Bug 57904, it happens with other sites as well. I gave another example in that bug. Mozilla should be capable of telling a site it is ns4 since it is the future version of ns. Perhaps an enhancement to be able to give a specified site a specified browser string.

> Mozilla should be capable of telling a site it is ns4 since it is the future > version of ns. No. This would be a disastrous mistake because it would mislead client sniffing code into delivering/executing code that is Nav4-specific. Even in pages that had been upgraded to support the W3C DOM, a misleading UA string would cause JavaScript code in web pages to think it was running on Nav4 and then try to execute Nav4-only code forks with things like document.layers[], leading to errors. Server-side sniffers would similarly dish out pages optimized for Nav4 rather than pages optimized for W3C standards supported in Gecko. You can go here to read more about client DOM differences and the implications for client sniffing: http://sites.netscape.net/ekrock/standards.html http://developer.netscape.com/viewsource/krock_v5.html http://developer.netscape.com/docs/examples/javascript/browser_type.html > Perhaps an enhancement to be able to give a specified site a specified > browser string. No, this would be an administrative albatross and a fatally doomed approach. Suppose we tweaked the product to spoof Wells Fargo and then they upgraded their content--then what? The simple, correct solution to this problem is for web sites to update their accepted UA lists to include Mozilla/N6. Isn't this a DUP of another bug in which this was already reported? --> Blake for evangelism.

It would not be so "disasterous" to send a browser string that tells the site moz is ns4 even if it doesn't support every littke ns4 feature. The worst that would happen is it wouldn't work and the user can't use moz/ns6. There is a chance it will work for some sites which would at least give moz/ns6 a fighting chance. I think it is a fatal mistake for moz/ns6 not to support ALL web sites supported by ns4. At least mozilla should have a "ns4 mode" which could be enabled on a per-site basis if there are some ns4 features that are not compatible with standards. In this mode, moz/ns6 would tell the site it is ns4 and then support all the extentions, behavior, etc supported by ns4. I think you under-estimate how many sites require ns4 and the huge undertaking to get all these sites to support pure moz/ns6. If my suggestions are not implemented, we will be stuck with ns4 for a very long time and moz/ns6 will rot on the shelves. In any case, it is obvious now that moz/ns6 is not ready for prime time, since implementing all ns4 features with a "ns4 mode" is probably not a small task. Unless I see something positive in this bug, I will erase mozilla from my system and give up. There are just too many web sites (most banks, I bet and possibly many other web sites conducting serious business) that require ns4, making moz/ns6 useless.

What? Your logic is nonsensicle here. >The worst that would happen is it wouldn't work and the user can't use moz/ns6. Hmm. Not being able to use the browser doesn't seem too good to me. How about you?

Exactly my point. That's why I stressed moz/ns6 must be able to support all ns4 functionality or it is useless (by default or with a setting on a per-site basis). That is what my second paragraph is all about. Some sites will work now with mozilla just fooling the site to believing it is ns4 because some (if not most) probably only care if you are running IE or ns in order to use MS specific features or not (like ActiveX controls, VB scripts, etc).

Moz should not present itself as Nav4, no browser ever did that. IE5 doesn't say "I'm IE4", IE4 doesn't say "I'm IE3" and IE3 doesn't say "I'm Netscape 1.0". There wouldn't have been any progress on the Web in the past 7 years. These sites will upgrade their code. They knew when they wrote it that it would become obsolete.

You are nit picking. OK then, mozilla should say it is ns6 and it should support everything ns4 did. Most (if not all) sites only care that the browser is ns and >= 4 and they (correctly) expect ns6 to work. If mozilla doesn't do that, then I cannot use mozilla for any serious work. If ns6 does this and moz doesn't, then they will be different browsers and mozilla is useless.

With all due respect, I think you are basing your position on misinformed ideas. Mozilla will not and will never deliberately disguise itself as Netscape 6, because Mozilla is an open-source browser, whereas Netscape is a vendor based off Mozilla source code. Mozilla is Mozilla, not Netscape, and to say otherwise would be to undo years of struggling to get that point across to the public. We already have a quirks mode to help ease the transition between the current, non-standard and largely propietary state of the web and the strict, standard web that Gecko will hopefully someday bring about. The point, as Pierre says, is that if we are so lenient in parsing that we accept and support everything, there will be no incentive for webmasters to update their sites to W3C specs. Considering standards are at the heart of Mozilla and its parsing and layout engines, I don't quite think this is `nit-picking' as you put it. You say that `If ns6 does this and moz doesn't, then they will be different browsers and mozilla is useless.' That's great! Mozilla and Netscape ARE different browsers. They might look similar now, but Mozilla will continue to be driven by the open-source community, while Netscape will continue to be diverge as necessary to comply with Netscape's interests as a company. I fail to understand your point that `mozilla is useless' if it isn't Netscape, but since you provide no explanation or anything to back that up, I won't bother responding to it. In reality, if every browser complied to the standards to the extent that Mozilla 1.0 and Netscape 6.0 will, these Javascript browser-sniffing hacks would no longer be necessary, because everyone would support the same thing. That is, of course, in an ideal world. Someone needs to take a risk and let themselves fail these browser-sniffing hacks in the name of standards. That's what we're doing. I am sorry you feel that Mozilla cannot be used your serious work unless it identifies itself as Netscape. Feel free to use Internet Explorer, the browser which, after NS 6.0 and MZ 1.0 are on the market, will basically be the browser still forcing the JavaScript-sniffing hacks which are causing you problems.

(Of course, the Javascript-sniffing hacks will probably be around for awhile for backwards compatibility. But the point remains.)

and this is still a problem with Netscape6 [candidate] bits: 1000.30.09/8-n6 commercial branch bits.

59593 is a simple dup of this bug, bug owners should decide which to keep.

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

mcaffe: I marked the new bug as a dup of this one because this one has more comments.

-> evangelism@telocity.com for my evangelism bugs. removing the now-depreciated evangelism-related keywords. setting platform to All.

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

This if from wellsfargo.com's faq: Q: How soon can I use a new browser to bank online? A: Under normal circumstances, Wells Fargo will support the final version of a new browser approximately two weeks after the final release date So how is it that Netscape 6.0 which has been out for a couple months now isn't supported?

The problem here is wellsfargo doesn't want to support Netscape 6/Mozilla because they don't like that the password manager can not be turned off. They don't believe that is secure enough for them.

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

Just tried to log in and got this wonderful message: Attention Netscape 6.0 users: At this time we do not support Netscape 6.0 because it does not meet our strict security guidelines. We are working hard to change this situation and hope to support it soon. Until a solution is found we suggest using an earlier version of Netscape or Internet Explorer. Are they really working hard on this? Has anyone recieved any communication from them trying to resolve the problem? re: jelwell's comment on the wallet/password manager... IE has the same thing right? They just let you turn it off? To me "Never remember passwords for this site" seems like an acceptable policy. Especially when you consider that most people's pins for the online banking were set on the phone and are completely numeric.

See bug 63961 for an update on this. The necessary modification was recently made to the password manager and that was the crux of that bug report. The crux of this bug report is that Wells Fargo is still rejecting the browser (in spite of the fact that it now has the modification they wanted) and that has to be addressed as an evangelism issue.

Adding Arun Ranganathan, who is handling Wells Fargo on the Evangelism side.

I've assigned this one to me: I've got correspondence going with Wells Fargo and in general have this one under control. Updates soon to follow.

Note that there are two issues here. One of them is the sniffing of the user-agent string. The other is the wallet/password manager issue. The user-agent string affair seems to have been taken care of. The latter issue remains. The good news: The bank in question approves of an IE like feature to suppress Password Manager. This looks like this: <INPUT TYPE="PASSWORD" AUTOCOMPLETE="OFF"> The 'AUTOCOMPLETE' attribute goes with either the FORM element or any element contained within the FORM element like the INPUT element. Password Manager was the chief bugaboo -- certain banks did not like the implications of using it in a shared environment. So, morse landed code that now works with AUTOCOMPLETE="OFF" -- a feature that matches what online banking institutions are used to in terms of suppressing autocompletion. The bad news: This fix has made it into the latest Moz' builds, but older Moz' based browsers such as N6 still have this problem. The chief consolation: There are workaround for N6 and older Moz' browsers (before Morse landed his code) that suppress Password Manager. Though these are hacks, they've been suggested, and we await the response.

Banks can detect different versions of Mozilla and Mozilla-based product by sniffing the Gecko date token. If the bank in question used one-time pad authentication like Finnish banks, this would be a non-issue.

I'm hoping to have this resolved by the 0.9.2 time frame, if not sooner. I'm in correspondence with folks at Wells Fargo, and I'm hoping that this will be taken care of.

http://www.wellsfargo.com/dhtml_menu.js doesn't properly detect Mozilla/uses layers.

OK, get this: Using 0615 Mozilla build, you can get into Wells Fargo. No problems. Using the commercial build, Netscape 6.1 PR1, you can NOT get into online banking at Wells Fargo. Here's the rub: Netscape 6.1 b identifies itself to the world as follows -- Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 Wells Fargo detects Netscape 6.1 beta as "Netscape 0.9.2". Some highly erroneous user-agent sniffing at work.

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

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

I can log into Wellsie fine with ns6.1/w2k at this url: https://banking.wellsfargo.com/

Someone please test with the following: nscp comm nightly: mac/linux/win nscp 6.1: mac/linux/win mozilla nightly: mac/linux/win I want ot make sure that this works on all of the above before we close this out. Zach

WFM Win32 trunk 2001081003 on Win32 (in other words "Mozilla nightly: win")

Please test with http://www.wellsfargo.com, not with 'banking.wellsfargo'. Going directly to 'banking.wellsfargo' bypasses the browser sniffing code. Users don't do that.

The above WFM was tested from www.wellsfargo.com all the way to my account history. Everything worked fine.

Linux Mozilla 2001080921 (nightly): 1. load www.wellsfargo.com 2. click on "Wells Fargo Online|Sign On" 3. type in ssn and password 4. click account summary works for me.

I just tried with Mozilla 2001091203. Went to wellsfargo.com clicked on Online banking. I entered my username and password and it came back with an error: "Your browser is set to refuse cookies. In order to sign on, you will need to reset the option in your browser to accept cookies. Then, refresh your screen, re-enter your SSN and password and select a button to begin banking." I checked and double checked the cookies setting in Preferences and it is set to "Enable all Cookies"

Arun's latest symptoms are probably being caused by bug 99286. Get a later build and try that again.

Oops, I meant ejohnson, not arun, in my comment above.

Arun wrote yesterday: ---- Many of you bank with Wells Fargo. The good news is they've updated their site, and they even validate their CSS :-) . Can anyone spot the workaround using CSS to thwart the form fill problem? :-) You can bank with Wells Fargo without going through any "back door" mechanism. I'm considering us unblocked from Wells Fargo. If there's any further weirdness with Wells Fargo, send mail to me and I'll worry some more... They made fairly large use of proprietary DOM so there may be left-overs. ----

Marking FIXED. Reopen if anything strange happens.

Bug 102888 is another Wellsfargo.com bug. Dupe of this bug?

mass-reassign of all bank bugs to the banks component. You may filter for this change by searching for the string 'ilovetriagebecauseitisfun'

Verified 2002030208/WinXP

Added to the mozilla financial shames page, http://blue-labs.org/financial-shames.php

SPAM: New Components

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