450973 - Login for Wells Fargo Bank fails (date portion of user agent string needs to be limited to 8 characters)

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Stephen Moehle]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080816182118 Firefox/3.1a2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080816182118 Firefox/3.1a2pre

Login to Wells Fargo fails using the form at the given URL. There are no error messages or anything from Wells Fargo. The page just reloads with the username and password fields cleared out. Nothing in the Error Console.

This works with Firefox 3.0.1.


Reproducible: Always

Steps to Reproduce:
1. Go to URL
2. Enter username and password
3. Press Enter or click Sign On.
Actual Results:  
Page reloads with username and password fields cleared out.

Expected Results:  
Login to succeed.

NSPR logging (sync:5) gives the following when I submit the form:

-1208113328[b7c11060]: WARNING: NS_ENSURE_TRUE(mSaveLayoutState || !aState) failed: file /home/stephe/mozilla/hg/src/docshell/shistory/src/nsSHEntry.cpp, line 353
-1208113328[b7c11060]: WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 988
-1208113328[b7c11060]: WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 988
-1208113328[b7c11060]: WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 988
-1208113328[b7c11060]: WARNING: NS_ENSURE_TRUE(sgo || !hasHadScriptObject) failed: file /home/stephe/mozilla/hg/src/content/base/src/nsContentUtils.cpp, line 4336
-1208113328[b7c11060]: WARNING: NS_ENSURE_SUCCESS(rv, 0) failed with result 0x8000FFFF: file /home/stephe/mozilla/hg/src/content/base/src/nsContentUtils.cpp, line 2688
-1208113328[b7c11060]: WARNING: NS_ENSURE_TRUE(sgo || !hasHadScriptObject) failed: file /home/stephe/mozilla/hg/src/content/base/src/nsContentUtils.cpp, line 4336
-1208113328[b7c11060]: WARNING: NS_ENSURE_SUCCESS(rv, 0) failed with result 0x8000FFFF: file /home/stephe/mozilla/hg/src/content/base/src/nsContentUtils.cpp, line 2688

Comment 1

[Stephen Moehle]

works: 2008-08-07-02-mozilla-central

fails: 2008-08-08-02-mozilla-central

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

regression range pushlog based on comment #1 and duped bug 451003:
http://hg.mozilla.org/mozilla-central/index.cgi/pushloghtml?startdate=2008-08-07+03%3A00%3A00&enddate=2008-08-08+02%3A00%3A00

Comment 4

[Brian Crowder]

This is a bad regression, which should be worked on.  I don't see anything obvious in the regression-range provided in comment #1, however.

Comment 5

[Brian Crowder]

Sorry, I lied.  A lot of potential candidates for mayhem in that range.  Still looking.

Comment 6

[Brian Crowder]

Copying bz, in case he's got a guess (likely to be a far better one than I would have).

Here's a better regression-range link:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=08%2F07%2F2008+00%3A00%3A00&enddate=08%2F08%2F2008+00%3A00%3A00

Comment 7

[Boris Zbarsky [:bzbarsky]]

So... in a current trunk build, we make the request to the server, they respond with a 302 to the same page we used to be on.

Someone want to get an HTTP log in a build this works in and attach it to the bug?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Nevermind.  I got a log in fx2.  We send the same request headers (except User-Agent, and I tried tweaking that), but get back a different response.

I guess it's hg bisect time...

Comment 9

[Boris Zbarsky [:bzbarsky]]

hg bisect sez it's bug 431270.  And indeed, if I change my UA string from 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080825074258 Minefield/3.1a2pre

to

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080825 Minefield/3.1a2pre

the site starts working (at least gives me the page I should be getting for a login error).  I tested, and any time the part after "Gecko/" is longer than 10 digits, this bug appears.  I have no idea what failed with my earlier UA-tweaking attempt...

We probably need to undo the changes to the HTTP-visible and script-visible UA string and go back to following our spec at http://www.mozilla.org/build/revised-user-agent-strings.html (once the website folks untrash it, at least).

Comment 10

[Brian Crowder]

cc:ing people from bug 431270 to get eyes on this.

Comment 11

[(not currently active) Ted Mielczarek]

Yeah, we clearly need to change the UA part back to what it was.

Comment 12

[Armen [:armenzg]]

GeckoDate 	
Date in the format YYYYMMDD. For official Mozilla builds, this will correspond to the date portion of the BuildID. For branded versions of Mozilla, the GeckoDate should correspond to the date the code was pulled from mozilla.org, and may not necessarily correspond to the date portion of the generated BuildID.  Note that the date does not identify the Gecko version if multiple branches are releasing in parallel.

Just for the purpose of having it at hand and see if we have to rewrite that paragraph
http://www.mozilla.org/build/revised-user-agent-strings.html

Comment 13

[Boris Zbarsky [:bzbarsky]]

Armen, we don't want to change that paragraph, or the web-facing UA string.

Comment 14

[Brian Crowder]

Attachment: like so?

Do I need sr? for this?

Comment 15

[Boris Zbarsky [:bzbarsky]]

I can sr, but shouldn't that be 8 rather than 10?

Comment 16

[Brian Crowder]

I tested it with wellsfargo, 10 worked....  I'll do 8, though...  coming right up.

Comment 17

[(not currently active) Ted Mielczarek]

I think we shipped Firefox 3 with a web-visible 10 digit build ID in the user-agent, FWIW.

Comment 18

[Boris Zbarsky [:bzbarsky]]

We did, which is presumably why it works on this site (they changed their code to make it work).  But we really shouldn't have done that, imo.

Comment 19

[(not currently active) Ted Mielczarek]

I'm not arguing either way, just noting that.

Comment 20

[Brian Crowder]

Attachment: 8 characters

Comment 21

[Dão Gottwald [:dao]]

Any reason not to land this before the beta freeze?

Comment 22

[Brian Crowder]

No, and I'd love help landing it, since every time I look the tree is either closed or burning (as it happens to be now).

Comment 23

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/2070d2f3a957

Comment 24

[Marcia Knous [:marcia]]

verified fixed using Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre as well Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre.

Comment 25

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 340616 [details] [diff] [review]
8 characters

fwiw this should've used .Truncate instead of .SetLength

Comment 26

[Brian Crowder]

What is the distinction, please?

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, guess there is none. I thought I remembered a comment in nsTAString.h about not using SetLength to shorten a string.

Comment 28

[Tony Chung [:tchung]]

Why does this fix only affect the trunk releases?   The branch releases (eg. fx3.0.3), still show the 10 digit characters.  We need to be consistent here, else it'll confuse websites that want to use UA string detection to support both trunk and branch.

Comment 29

[Brian Crowder]

10 doesn't seem to cause trouble for Wellsfargo, it was the 16 or whatever that we'd been sending since the update to extended build IDs.

Comment 30

[Samuel Sidler (old account; do not CC)]

fwiw, this changes behavior from what I think it probably should be.

In Firefox 2, the UA was 8 characters, which is fine. You can check this by typing javascript:navigator.userAgent into the location bar.

However, also in Firefox 2, the "Build" printed on the about: page was 10 characters, which happened to be the size of the build ID back then. That build ID is used for other things as well.

I think we should print 8 characters in the UA but still print the full build ID on the about: page.

Comment 31

[Boris Zbarsky [:bzbarsky]]

about: just outputs navigator.userAgent.  If you want it to list something else, that needs to be changed in the about: page....

Fx2's about: page did something smarter here, but someone saw fit to change it in bug 387163 (basically working around the fact that navigator.userAgent now included the hour).  That patch should probably be backed out.

Comment 32

[Boris Zbarsky [:bzbarsky]]

ccing bsmedberg, since in bug 387163 he says he lengthened the on-the-wire buildid intentionally.

Comment 33

[Benjamin Smedberg]

This landed prior to 1.9.1 branching.

Comment 34

[Stephen Donner [:stephend] Not actively reading bugmail]

I have a Wells Fargo account and this is verified fixed for me using 1.9.1:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20090128 Shiretoko/3.1b3pre

Replacing fixed1.9.1 keyword with verified1.9.1.