629227 - Logging into chase.com requires an extra step since Firefox 3.6

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Dave Townsend [:mossop]]

In Firefox 3.6 logging into online banking on chase.com only required entering username and password on the main page. On trunk if you do that it pauses for a bit then loads a page with the message:

Unable to Log On (Error Code LO013)

We're unable to complete your request. Please reenter your User ID and Password or click "Forgot your User ID/Password?". You also may want to make sure your computer's Date and Time setting is correct. 

The login form on this page works to get you in.

There seem to be no errors in the error console that aren't there on 3.6 so I'm not sure where the problem is here at the moment.

Comment 1

[Dave Townsend [:mossop]]

Lots of reports on input.mozilla.com, looks like this has been happening since at least beta 4

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

This is almost assuredly not a front-end problem, but leaving it here for now.

Boris, Sicking: any ideas of changes in DOM code that could have this affect? Jonas, I bet if you walked over to Dave's desk, he'd show you the problem directly.

Comment 3

[Dave Townsend [:mossop]]

Tried spoofing my UA to Firefox 3.6 and it still fails. It looks like some JS on the page is running and the problem occurs there, the very first network request after entering the login details is to load the error page.

Comment 4

[Dave Townsend [:mossop]]

I think you can reproduce this without a chase login. Just try logging in with "foo" "bar". On 3.6 it takes you to:

https://chaseonline.chase.com/Logon.aspx?LOB=RBGLogon

with the message "Unable to Log On"

On 4.0 it takes you to:

https://chaseonline.chase.com/Logon.aspx?error=L009&LOB=RBGLogon&src=https%3A%2F%2Fwww.chase.com%2FChase.html

with the message "Unable to Log On (Error Code LO013)"

Comment 5

[Boris Zbarsky [:bzbarsky]]

So...  I tried to do the "foo"/"bar" thing.  That gave me a regression range.  Then I tried logging in with my actual account... that works for all builds up through two days ago.  At least sometimes.  My usual profile I get the error in this bug.  A clean profile I get the "we don't recognize your computer" thing.

I can _definitely_ log in with my actual account in a clean profile in a build in which foo/bar give me the LO013 error.

My regression range for foo/bar is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d1da1005b6d6&tochange=4f03895d544b

Dave, can you check what the regression range is for you?  Ideally with your actual credentials?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Using foo/bar on my normal profile gives what you describe as the Firefox 3.6 behavior in comment 4.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Dave: So does FF4 and FF3.6 create requests for different URLs when you're testing?

I looked at the javascript that's run during the submission, but didn't see anything sticking out. Unfortunately Firebug's javascript panel appears to be broken on mozilla-central tip.

Comment 8

[Dave Townsend [:mossop]]

(In reply to comment #7)
> Dave: So does FF4 and FF3.6 create requests for different URLs when you're
> testing?

Yes, the two urls in comment 4 are the first requests made by 3.6 and 4.0

Going to try to run the regression range now

Comment 9

[Dave Townsend [:mossop]]

Certainly profile specific and I may not have noticied it if I was using the same profile for 3.6 and trunk. It seems if I copy my profile and run it under 3.6 I can log in and after that I can log in on trunk. I can also log in on trunk if I delete my cookies.

But there is still definitely something we changed that is causing a difference. I bisected amongst nightlies by cloning my trunk profile for each test and ended up with quite a different regression range to bz but it points squarely at the compartments merge (http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c762301b719&tochange=29c228a4d7eb)

I built and bisected it further down to the range from fc7d5d721ed8 to 02d2d18d17f9. The mid-point that hg tried to use from there is 53c20ebc3c52 and crashes on startup. I may try getting a narrower range later but for now looks likely to be JS related.

Comment 10

[David Mandelin [:dmandelin]]

Actually, I think I want to call this a softblocker for now because it seems we don't entirely have STR. A narrower regression range would probably help--there is more than just compartments stuff in that merge.

Comment 11

[Michael Romero]

I can confirm that this happens on both Mac and Windows nightlies. I tried clearing the cookies, but it reappeared.

Comment 12

[David Mandelin [:dmandelin]]

(In reply to comment #9)
> I built and bisected it further down to the range from fc7d5d721ed8 to
> 02d2d18d17f9. The mid-point that hg tried to use from there is 53c20ebc3c52 and
> crashes on startup. I may try getting a narrower range later but for now looks
> likely to be JS related.

Any luck getting a narrower range? Not holding a Chase account, I don't see how I can debug this.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Dave, does your regression range for the steps in comment 4 also point at compartments?

Comment 14

[Dave Townsend [:mossop]]

(In reply to comment #13)
> Dave, does your regression range for the steps in comment 4 also point at
> compartments?

Yes it does. I tried narrowing the range a couple of times but every build I made was segfaulting on startup. Don't know if that was a feature of that branch or I'm doing something wrong.

Going to try wiping out cookies to see if I can narrow down what in the profile is causing it.

Comment 15

[Boris Zbarsky [:bzbarsky]]

dmandelin, the steps in comment 4 don't need a chase account.

Comment 16

[David Mandelin [:dmandelin]]

I narrowed the range a bit: 

http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=55188&tochange=55228

It's hard to go further because the builds tend to be broken or else we assert on startup within there. But it pretty much looks like brain transplants.

Feel free to retriage but for now I will call this a hardblocker because it seems crappy and annoying, at least.

Comment 17

[Ed Lee :Mardak]

Attachment: login_home.js

I noticed that there were no POSTs sent in Firefox 4, and turns out it's some javascript redirecting to the L009 error url.

catch(e) { if(reTryCount >= _maxReTryCount) errorUrl+"/Logon.aspx?error=L009& ...

javascript:void(eval(uneval(validateAndSubmitFrame).replace("catch (e) {", "$&alert(e);")))

The exception is:

TypeError: iframeForm is undefined

iframe = window.frames['loginframe'];
iframeDoc = iframe.document;
iframeForm = iframeDoc.login;

In 3.6, iframeForm is [object HTMLFormElement]

javascript:void(validateAndSubmitFrame = function() { document.domain = _cookieDomain.substring(1, _cookieDomain.length); alert(window.frames['loginframe'].document.login); })

Comment 18

[Ed Lee :Mardak]

Fyi, in 4, document.getElementById(id) works:

javascript:void(validateAndSubmitFrame = function() { document.domain = _cookieDomain.substring(1, _cookieDomain.length); alert(window.frames['loginframe'].document.getElementById("login")); })

[object HTMLFormElement]

(I've been testing with foo/bar user/pass.)

Comment 19

[Ed Lee :Mardak]

Comment on attachment 512504 [details]
login_home.js

[Which is kinda amusing in that the "if (document.all)" block uses getElementById for both "loginframe" and "login" while the else block uses these property aliases...]

Comment 20

[Boris Zbarsky [:bzbarsky]]

Edward: thanks!

Working on a testcase for this now.

Comment 21

[Boris Zbarsky [:bzbarsky]]

And yeah, their sniffing is all broken, but we still regressed things here with wrapper stuff.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Attachment: Mochitest that shows the problem

If I make the innermost frame come from test1.example.org instead, the test passes

Comment 23

[Brendan Eich [:brendan]]

Can we have a TE bug on Chase to fix their totally broken sniffing?

/be

Comment 24

[Boris Zbarsky [:bzbarsky]]

It's not really worth spending time on, since the code on both codepaths should work in any reasonable browser.

Comment 25

[Johnny Stenback (:jst)]

Blake, bz knows what's going on here, sounds like DOM 0 stuff (document.forms.foo etc) doesn't work through transparent xray wrappers when document.domain is involved.

I'm pulling this into betaN+, but if need be we can argue over that, but I'd love to see this go into a beta, which means we need a fix today or tomorrow.

Comment 26

[RobertJ]

FWIW - I have been logging into chase every day using FF4b7 -> FF4b11. Never had a problem.

OSX 10.6.6

Comment 27

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix

I got rid of some of the outer -> inner forwarding in a hunt for realObj.

Comment 28

[Johnny Stenback (:jst)]

Comment on attachment 512991 [details] [diff] [review]
Proposed fix

- In dom/base/nsDOMClassInfo.h:

+   * helper with a wrapper, even though we should be treating the lookup asa

"as a".

+  static PRBool ObjectIsTransparentWrapper(JSContext* cx, JSObject* obj);

As you pointed out on irc, this function is unused, remove it until it's needed.

r=jst

Comment 29

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Updated fix

I took the liberty of including bz's mochitest in this.

Comment 30

[Ed Lee :Mardak]

Comment on attachment 513009 [details] [diff] [review]
Updated fix

>+++ b/dom/base/nsDOMClassInfo.h
>+   * The following two functions...
>   static PRBool ObjectIsNativeWrapper(JSContext* cx, JSObject* obj);
There's only one without ObjectIsTransparentWrapper. :)

Comment 31

[Mike Shaver (:shaver emeritus)]

mrbkap: if you need this landed, I can watch the tree for you.

Comment 32

[Johnny Stenback (:jst)]

Shaver, I'm landing this right now, I'll be watching...

Comment 33

[Mike Shaver (:shaver emeritus)]

<3

Comment 34

[Johnny Stenback (:jst)]

Landed:

http://hg.mozilla.org/mozilla-central/rev/19731df33d98

Comment 35

[Ed Lee :Mardak]

Verified with 20110217 Built from http://hg.mozilla.org/mozilla-central/rev/4b9e814fe3ab

Comment 36

[Dave Townsend [:mossop]]

Yes, awesome!

Comment 37

[Ayush]

Does this mean it has been added as a fix in Beta 11? I can still duplicate the problem with Chase using Beta 11 (Win 7).

Comment 38

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to comment #37)
> Does this mean it has been added as a fix in Beta 11? I can still duplicate the
> problem with Chase using Beta 11 (Win 7).

No, this will be in beta 12.

Comment 39

[Jason]

I'm encountering this bug in Firefox 5.0.1 using OSX 10.6.8.  Similar behavior to what Dave described in the first post. When attempting to log in from Chase.com, there's no response from Firefox for 3-5 seconds after hitting Enter, then the "Unable to Log On (Error Code LO013)" error page loads. From the error  page, there's no delay when attempting to log in... the same error page reloads immediately. 

Outside of that, I don't have much technical data to provide, but am willing to with instructions on what to do. I just upgraded to FF 5 a few days ago and can't recall if login worked anytime since the upgrade. Safari works. Assuming Chase.com requires a reset after 3 failed login attempts, then the failed attempts in FF are not registering as failed attempts on Chase's end. 

Thanks!
Jason

Comment 40

[Boris Zbarsky [:bzbarsky]]

Jason, it sounds like you're seeing a somewhat different issue (if nothing else because the bug that was here _was_ actually fixed for Firefox 4).  Could you please file a new bug on it and mention the bug number here?

Comment 41

[Jason]

Filed as a new bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=671526