Closed Bug 629227 Opened 12 years ago Closed 12 years ago
Logging into chase
.com requires an extra step since Firefox 3 .6
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.
blocking2.0: --- → ?
Lots of reports on input.mozilla.com, looks like this has been happening since at least beta 4
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.
Whiteboard: [dom? js? ua sniffing?]
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.
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)"
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?
Using foo/bar on my normal profile gives what you describe as the Firefox 3.6 behavior in comment 4.
(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
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.
Assignee: nobody → general
Product: Firefox → Core
QA Contact: general → general
Whiteboard: [dom? js? ua sniffing?]
Version: unspecified → Trunk
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.
Whiteboard: hardblocker → softblocker
I can confirm that this happens on both Mac and Windows nightlies. I tried clearing the cookies, but it reappeared.
(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.
Dave, does your regression range for the steps in comment 4 also point at compartments?
(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.
dmandelin, the steps in comment 4 don't need a chase account.
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.
Assignee: general → nobody
blocking2.0: betaN+ → final+
QA Contact: general → xpconnect
Whiteboard: softblocker → hardblocker
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...]
Edward: thanks! Working on a testcase for this now.
And yeah, their sniffing is all broken, but we still regressed things here with wrapper stuff.
If I make the innermost frame come from test1.example.org instead, the test passes
Can we have a TE bug on Chase to fix their totally broken sniffing? /be
It's not really worth spending time on, since the code on both codepaths should work in any reasonable browser.
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.
Assignee: nobody → mrbkap
blocking2.0: final+ → betaN+
Whiteboard: hardblocker → [hardblocker]
FWIW - I have been logging into chase every day using FF4b7 -> FF4b11. Never had a problem. OSX 10.6.6
I got rid of some of the outer -> inner forwarding in a hunt for realObj.
Attachment #512991 - Flags: review?(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
Attachment #512991 - Flags: review?(jst) → review+
I took the liberty of including bz's mochitest in this.
Attachment #512991 - Attachment is obsolete: true
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. :)
mrbkap: if you need this landed, I can watch the tree for you.
Shaver, I'm landing this right now, I'll be watching...
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified with 20110217 Built from http://hg.mozilla.org/mozilla-central/rev/4b9e814fe3ab
Status: RESOLVED → VERIFIED
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).
(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.
Target Milestone: --- → mozilla2.0b12
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
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?
Filed as a new bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=671526
You need to log in before you can comment on or make changes to this bug.