Closed Bug 666095 Opened 13 years ago Closed 13 years ago

suntrust.com - Cannot log in with Firefox > 6.0

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 666587

People

(Reporter: thetinsmith, Unassigned)

References

()

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110621 Firefox/6.0a2
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110621 Firefox/6.0a2

My bank site will no longer let me log in. I can login with the just released FF 5.0 but not with today's FF 6.0 Aurora.

My bank site is Suntrust

Reproducible: Always

Steps to Reproduce:
1.Load site
2.Enter user name
3.Enter password


Actual Results:  
login never completes

Expected Results:  
login completes

Also does not work with today's 7.0 Nightly.
Does the issue still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode

When you say never completes, what do you mean? Any errors displayed? Any errors in the error console?
Summary: Login does not complete → Suntrust bank login does not complete
Version: unspecified → Trunk
Using the User-Agert-Switcher extension:

<https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher/>

Spoofing the UA string as Fx 5 while using 6.0 the login completes.

Spoofing the UA string as Fx 5 while using 7.0 the login still fails.
Summary: Suntrust bank login does not complete → Login does not complete
Version: Trunk → unspecified
Summary: Login does not complete → suntrust.com - Cannot log in with Firefox > 6.0
(In reply to comment #1)
> Does the issue still occur if you start Firefox in Safe Mode?
> http://support.mozilla.com/en-US/kb/Safe+Mode


This issue still occurs when using Safe Mode.


> When you say never completes, what do you mean? Any errors displayed? Any
> errors in the error console?


At the Login Screen the user (me) enters a user name and a password. The page changes to a page that says "Please wait while we validate your sign-on information" and this displays 'dots' to indicate activity. Normally this 'completes' and the page changes to the an account access page.

It never gets past the 'validating' page.

One of the many repeating lines in the "Messages" section:

bugzilla.mozilla.org : server does not support RFC 5746, see CVE-2009-3555
David, are you willing to use http://harthur.github.com/mozregression/ to try to narrow down when this problem appeared?
(In reply to comment #4)
> David, are you willing to use http://harthur.github.com/mozregression/ to
> try to narrow down when this problem appeared?


Certainly. I will begin shortly.
(In reply to comment #4)
> David, are you willing to use http://harthur.github.com/mozregression/ to
> try to narrow down when this problem appeared?

Done and report set automatically by the program.
Sent automatically to where?

If you can just paste the regression range URI it came up with here, that would be really helpful!
(In reply to comment #7)
> Sent automatically to where?
> 
> If you can just paste the regression range URI it came up with here, that
> would be really helpful!

Sorry.

Last good nightly: 2011-06-20 First bad nightly: 2011-06-21

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=058a584ea7d3&tochange=a285146675dc
Hmm.  Nothing out there jumps out at me... and more importantly, it's not clear to me that any of those changes are on Aurora.

Can you try that again on the tracemonkey branch and see what the script comes up with?
(In reply to comment #9)
> Hmm.  Nothing out there jumps out at me... and more importantly, it's not
> clear to me that any of those changes are on Aurora.
> 
> Can you try that again on the tracemonkey branch and see what the script
> comes up with?

I should explain you have a non Geek here.

How do I do that. The non Geek version please.  :-)
When you run it, use the --repo=tracemonkey argument.
(In reply to comment #11)
> When you run it, use the --repo=tracemonkey argument.

Two pieces of new information.

No matter what I tried the   --repo=tracemonkey  argument did not change the test from looking for the Nightly of (7.0). Sorry.

However the 2011-06-22 release of Fx 6.0 completes the login and proceeds to the account access page as it should.


And the 2011-06-22 release of Fx 7.0 still fails to complete.
But the 2011-06-21 6.0 build fails to login?
(In reply to comment #13)
> But the 2011-06-21 6.0 build fails to login?

Tonight (2011-06-22) the Fx 6.0 that identifies itself like this:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110621 Firefox/6.0a2

works.

It is the Nightly (7.0a1) that still fails.
Ok, thanks.

Given the regression range from comment 8, I'm betting this came in with the tracemonkey merge....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
The regression range here includes:

  http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=e59b1d2a2f79&tochange=9ced98ee3aa9

i.e., the thing from bug 666587. Could someone please check whether that's it?
David (reporter of the bug), would you be willing to run a pair of test builds to test David Mandelin's hypothesis?  If so, I can kick off some try server runs...
(In reply to comment #17)
> David (reporter of the bug), would you be willing to run a pair of test
> builds to test David Mandelin's hypothesis?  If so, I can kick off some try
> server runs...

Of course. Anything to help.
(In reply to comment #19)
> OK.  Here are the builds:

Both of these are full installs using the .exe package. One installed and tested then removed followed by the second installed. Both where installed to the default path.

 
> Build that still has arity:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbarsky@mozilla.
> com-0995752722e6/try-win32/


Tested in normal mode:

Login succeeds with no pause while validating user and it then proceeds to the accounts page as expected.


Tested in safe mode

Login succeeds with slight pause while validating user it and then proceeds to the accounts page as expected.


_______________________________


> Build with arity removed:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbarsky@mozilla.
> com-16a49138e934/try-win32/


Tested in normal mode

Login fails and does not proceed to accounts page as expected. It stops at 'Validating user'.


Tested in safe mode

Login fails and does not proceed to accounts page as expected. It stops at 'Validating user'.
(In reply to comment #20)
> (In reply to comment #19)
> > OK.  Here are the builds:
> 
> Both of these are full installs using the .exe package. One installed and
> tested then removed followed by the second installed. Both where installed
> to the default path.
> 
>  
> > Build that still has arity:
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbarsky@mozilla.
> > com-0995752722e6/try-win32/
> 
> 
> Tested in normal mode:
> 
> Login succeeds with no pause while validating user and it then proceeds to
> the accounts page as expected.
> 
> 
> Tested in safe mode
> 
> Login succeeds with slight pause while validating user it and then proceeds
> to the accounts page as expected.
> 
> 
> _______________________________
> 
> 
> > Build with arity removed:
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bzbarsky@mozilla.
> > com-16a49138e934/try-win32/
> 
> 
> Tested in normal mode
> 
> Login fails and does not proceed to accounts page as expected. It stops at
> 'Validating user'.
> 
> 
> Tested in safe mode
> 
> Login fails and does not proceed to accounts page as expected. It stops at
> 'Validating user'.

Excellent.  Looks like Bug 640593 is the culprit.  Thanks for testing!
Blocks: 640593
(In reply to comment #21)

> Excellent.  Looks like Bug 640593 is the culprit.  Thanks for testing!

I wasn't clear from a brief reading of that bug whether what we're left with is actually a TE issue (i.e., we need to get Suntrust to stop using code involving the removed functionality) or a regression (it seemed like the removal was done intentionally, and "fixing" the regression would involve putting the code back, which is contrary to the original purpose of that bug).

Can someone please clarify?
> Can someone please clarify?

It depends.  Bug 640593 made various changes other than removing .arity; we need to understand what those changes were and maybe try a build with those changes undone but the .arity removal still in and see whether that works.
Once we have a build with a fix for bug 666587 we should retest here...
Depends on: 666587
(In reply to comment #24)
> Once we have a build with a fix for bug 666587 we should retest here...

Knock. Knock. Non Tech guy here.

If I can help with this I would be more than happy to help.

:-)
David, you can help with it, but we need a build with that fix first.  Once we have it, I'll point you to it!
Ah, looks like dmandlin landed that on TM.


David, can you try the build at http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/tracemonkey-win32/1308950967/ ?
David, tomorrow's mozilla-central nightly should also have the fix for that bug.  Would you be willing to try that on suntrust?
(In reply to comment #27)
> Ah, looks like dmandlin landed that on TM.
> 
> 
> David, can you try the build at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/tracemonkey-
> win32/1308950967/ ?


This build does login at Suntrust.
(In reply to comment #28)
> David, tomorrow's mozilla-central nightly should also have the fix for that
> bug.  Would you be willing to try that on suntrust?


Of course. This will be in the regular Nightly tree?

<http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/>
(In reply to comment #29)
> (In reply to comment #27)
> > Ah, looks like dmandlin landed that on TM.
> > 
> > 
> > David, can you try the build at
> > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/tracemonkey-
> > win32/1308950967/ ?
> 
> 
> This build does login at Suntrust.

Thanks! That's all we need to know. I'll follow up on Aurora.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
(In reply to comment #31)
> (In reply to comment #29)
> > (In reply to comment #27)
> > > Ah, looks like dmandlin landed that on TM.
> > > 
> > > 
> > > David, can you try the build at
> > > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/tracemonkey-
> > > win32/1308950967/ ?
> > 
> > 
> > This build does login at Suntrust.
> 
> Thanks! That's all we need to know. I'll follow up on Aurora.
> 
> *** This bug has been marked as a duplicate of bug 666587 ***

My pleasure.
No longer depends on: 666587
(In reply to comment #30)
> (In reply to comment #28)
> > David, tomorrow's mozilla-central nightly should also have the fix for that
> > bug.  Would you be willing to try that on suntrust?
> 
> 
> Of course. This will be in the regular Nightly tree?
> 
> <http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/>


The latest Nighty from 2011-06-28 mentioned above also works.
You need to log in before you can comment on or make changes to this bug.