User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.19) Gecko/20081212 Camino/1.6.6 (like Firefox/2.0.0.19) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.19) Gecko/20081212 Camino/1.6.6 (like Firefox/2.0.0.19) Since upgrading to Camino Version 1.6.6 (1.8.1.19 2008121219), The password field on the Wells Fargo Website does not appear. All was fine with the previous version. Reproducible: Always Steps to Reproduce: 1.Log on to WWW.Wellsfargo.com 2. 3. Actual Results: See details above Expected Results: See details above

That shows up for me in a 2.0 nightly, in 1.6.6 on an Intel Mac, and in 1.6.5 on a PPC Mac. (I haven't tested 1.6.6 on PPC yet.) Given that there were not any changes to widgets from 1.6.5 to 1.6.6, that's not really a surprise, though. What did you upgrade *from*, and what happens if you use Troubleshoot Camino to try it with a fresh profile? http://pimpmycamino.com/parts/troubleshoot-camino cl

I see this; it's broken in Camino 1.6.6 and Firefox 2.0.0.19, and works in 2.0.0.18. I'd like to keep this here for a bit until we can figure out what might have broken it and where in Core it needs to move (it may be Layout and therefore may want a testcase), unless someone smarter than me figures it out first....

Ah, here we go (sorta): 4:04 PM: Security Error: Content at https://www.wellsfargo.com/ may not load data from https://a248.e.akamai.net/f/248/1856/90m/www.wellsfargo.com/IdentityMap.xbl#mozcloak. The password <input> is inside <span class="mozcloak">.

I tried Camino 1.6.6 and Firefox 2.0.0.19, and it doesn't work. The error console in Fx displayed: Security Error: Content at https://www.wellsfargo.com/ may not load data from https://a248.e.akamai.net/f/248/1856/90m/www.wellsfargo.com/IdentityMap.xbl#mozcloak. My latest fx2 nightly has the same problem, but if I have NoScript installed, whether or not I allow wellsfargo or akamai, then the password field is displayed.

This looks like bug 387971 all over again. Blake says bug 379959 is at fault.

Does that mean we need bug 204140 on the 1.8 branch?

Taking 204140 on the 1.8 branch is a potentially scary proposition, as it has a lot of dependencies and stuff, so although it's a long shot, we might try to go after Wells Fargo / Akamai and see if we can get them to stop building their pages this way.

Jonas: you said in bug 379959 that there might be an alternate fix for this regression on the 1.8 branch. Spill details, pronto.

The alternative is rolling out a simpler, but different, fix for 1.8. If we simply ignored any XBL that failed to load then I think we'd be golden. What happens currently is that if we fail to load an XBL we refuse to render anything, even the normal content.

I looked into what's involved with doing that, and I think it should be fairly low-risk. The main risk is that content start appearing in chrome that used to be hidden by non-existing bindings. We could address this by only showing content for failed-to-load web XBL

Oh, actually, even simpler would be to only show the normal content if we refuse to load the XBL out the security restrictions added in bug 379959

E Shatara (and any other end-users here), there's a simple work-around you can apply to get the password field back until Wells Fargo fixes their website or we can include a fix for this bug in a new release. In the "chrome" folder inside your profile folder (~/Library/Application Support/Camino for Camino), create a new plain-text file called userContent.css and paste the following lines of text and save: @-moz-document url(https://www.wellsfargo.com/) { .mozcloak { -moz-binding: none !important; } } When you restart Camino/Firefox/SeaMonkey, the password field will appear again, so you can continue using the latest release with all its other security fixes *and* still access your bank. If you need additional help getting this work-around working, please post in the appropriate support forum (for Camino that's http://forums.mozillazine.org/viewforum.php?f=12 ), not in this bug report.

You can also get to a login and password prompt in the site after two clicks, for example clicking on "Online Banking" in the Banking column, then "Sign On" at the very top on the resulting page. Not ideal, but you can navigate to a working login prompt.

Seems kind of pointless to nominate for 1.8.1.19 since we've already shipped that release.

When a Web site works fine for IE but not for a Gecko browser, the answer is very often that the site should not use IE-specific proprietary capabilities. The same should be true for Gecko-specific capabilities. This should be a Tech Evangelism bug. Someone officially representing the Mozilla organization should contact Wells Fargo and inform them that they should not use Gecko-specific CSS. See my comment in Bug 470050.

(In reply to comment #14) > You can also get to a login and password prompt in the site after two clicks, > for example clicking on "Online Banking" in the Banking column, then "Sign On" > at the very top on the resulting page. Not ideal, but you can navigate to a > working login prompt. That's even better, and far easier than a userContent.css hack.

I'm working with Wells Fargo to get this fixed.

Getting bug 204140 would be a good bit of code. I'm not sure we should do that. I think the solution in comment 10 is a good one. I'll try to get a 1.8-branch patch up based on that tomorrow morning.

Boris, when you do that, can you please file a new bug for it? I'm hijacking this bug for TE purposes and working with Wells Fargo to get it fixed on there end since we can hopefully get that done faster than a 1.8.1.x release can go out (of which, we're not planning any more Firefox ones).

cc'ing some SUMO folk so they can be aware of both the issue and the workaround in comment 14

Thanks, beltzner, adding zzxc.

OK, I filed bug 470461.

I'm a humble end user and tried comment #13 and it didn't work as far as i can tell. here's a super-simple end user work around for the non-techies out there: just bookmark the password error page and start there: https://online.wellsfargo.com/login?ERROR_CODE=ZXJyb3Iubm9QYXNzd29yZA%3D%3D

I'm seeing the password field on wellsfargo.com in Camino 1.6.6 (same version as in comment 0) and Firefox 2.0.0.20, so it looks like Wells Fargo has indeed fixed their website. I think I recall discussing with Sam that it was fixed on WF's end some time ago, actually, but if so, neither of us remembered to mark this TE bug FIXED ;)

Indeed fixed, no longer reported on sumo either.