Closed Bug 562198 Opened 14 years ago Closed 14 years ago

Firefox 3.6.4 doesn't obey HTTP Set-Cookie in this case, while Firefox 3.6.3 does (Fx 3.6.4 on Linux produces Year 2038 problem)

Categories

(Core :: Networking: Cookies, defect)

1.9.2 Branch
x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking1.9.2 --- .4+
status1.9.2 --- .4-fixed

People

(Reporter: jeronimo, Assigned: dwitte)

Details

(Keywords: regression, verified1.9.2)

Attachments

(7 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4\r\n

I mantain a private system with a login page. The steps to the login are basically 4:
1. It is made a POST to a page called "login.html" with the login data (no SSL used, plain text);
2. If the login is correct, the server answers a page with a javascript code inside it, which redirects to "index.html", with a simple: "top.window.location='/index.html';".
3. It is made then a GET to index.html
4. The server gives the page index.html.

Everything is working fine with Firefox 3.6.3 or earlier.
Firefox 3.6.4 beta (build 1) receives a different response from the server in the step 4, which redirects to the login page again. 
To the server does not matter what browser sends the requests. It does not make any difference between one or another. It seems Firefox 3.6.4 beta (build 1) is sending something different in its reqs. in comparison to Firefox 3.6.3.
The problem happens every time.
I have 2 logs from wireshark showing these interactions between browsers and the server, to analysis. 

Reproducible: Always




OS: Ubuntu 8.04 LTS 32 bits
So both versions send
    POST /login.html HTTP/1.1\r\n
receive almost the same response (the value of cookie is different):
    HTTP/1.1 200 OK\r\n
        Request Version: HTTP/1.1
        Response Code: 200
    Server: mini_httpd/1.19 19dec2003\r\n
    Date: Wed, 04 Feb 2009 08:42:02 GMT\r\n
    Cache-Control: no-cache,no-store\r\n
    Set-Cookie: admin1016398=811170416; path=/; expires=Sun, 01-Oct-2040 23:00:00 GMT\r\n
    Content-Type: text/html; charset=%s\r\n
    Content-Length: 251
    Cache-Control: max-age=0\r\n
    Expires: Thu, 01 Jan 1970 00:00:00 GMT\r\n
    X-UA-Compatible: IE=EmulateIE7\r\n
    Connection: close\r\n
with HTML containing
    <script type="text/javascript">top.window.location='/index.html';\n
..but then 3.6.3 sends
    GET /index.html HTTP/1.1\r\n
    Cookie: admin582008=278976414; admin708662=276113059; admin1016398=811170416\r\n
..and 3.6.4 only sends
    Cookie: admin582008=278976414; admin708662=276113059\r\n
(the other two cookies were already sent at the time of POSTing)

I don't see anything obviously wrong here, putting on 1.9.2 radar just in case.

Jeronimo: do you see this on the same profile? Can you reproduce this with a new profile? Does it work on trunk (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/) and the latest 1.9.2 builds (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/)?

Could you track down the build where it regressed using the mozilla-1.9.2 builds here http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ ?

(I'm not up to trying to simulate this HTTP conversation to see if I can reproduce.)

Putting on the 1.9.2 radar in case this is real.
blocking1.9.2: --- → ?
status1.9.2: --- → ?
Component: General → Networking: Cookies
Keywords: regression
Product: Firefox → Core
QA Contact: general → networking.cookies
Summary: Firefox 3.6.4 gets different response from server in comparison to Firefox 3.6.3 in the same page → Firefox 3.6.4 doesn't obey HTTP Set-Cookie in this case, while Firefox 3.6.3 does
Version: unspecified → 1.9.2 Branch
Is cookie of admin1016398=811170416, which was sent by next header and next script code, saved by Fx 3.6.4?
> Set-Cookie: admin1016398=811170416; path=/; expires=Sun, 01-Oct-2040
23:00:00 GMT
> <script type="text/javascript">top.window.location='/index.html'
Check via Tools/Options/Privacy/link of "remove individual cookies"->Cookies, please.
We didn't make any changes to cookie code in Firefox 3.6.4, so I find this regression hard to believe.

Leaving the nominations for now, but I suspect this isn't valid. Adding qawanted to see if we can get someone to reproduce with Wireshark.
Keywords: qawanted
(In reply to comment #5)

Following is bugs found by search for "bug summary contains cookie && sync" AND "status=open||fixed||dup" AND "changed within 3 months".
> 449990 2010-04-08 NEW  Networki move cookies to async sqlite api
> 536978 2010-04-15 RESO Networki Cookies should write asynchronously 
> 547031 2010-03-21 NEW  Networki Improve async error handling in cookies
> 562587 Thu 04:41  NEW  Networki e10s HTTP: need to duplicate AddCookiesToRequest, etc, in HttpChannelChild::AsyncOpen

No change around issues like above in other bugs?

If no change, can race condition happen between processing of "Set-Cookie: admin1016398=811170416; ..." and execution of <script>top.window.location='/index.html'</script>?
I'm going to test with a previous condition cookie-free, I mean, no cookies set before that test.
Not blocking until it's confirmed. Please feel free to renominate if that happens.
blocking1.9.2: ? → -
Now, I tested with no cookies previously set. 
Following to this comment I'm attaching the two files.
By the way, I used same profile on both, using Firefox 3.6.4 build 1.
I'm going to try with the trunk metioned above, and after with the 1.9.2 (mentioned above too).
Interaction with Trunk (03-May-2010 03:01).
The problem is reproducible.
Interaction with Latest(1.9.2) (03-May-2010 03:30).
The problem is reproducible.
Thanks for your efforts so far. I don't know why this could happen and I couldn't reproduce on Mac by feeding the response with Set-Cookie to Firefox via this tool: http://muizelaar.blogspot.com/2010/01/reproducing-bugs-on-complicated.html (the subsequent GET request sent the correct Cookie header).

It would help to be able to reproduce this. The server isn't accessible publicly, right?

It would probably be helpful if you obtained an HTTP log and a cookie log: https://developer.mozilla.org/en/HTTP_Logging http://www.mozilla.org/projects/netlib/cookies/cookie-log.html

Also if we knew the specific build this regressed in, we would be able to see what changes might have affected this behavior.
(In reply to comment #15)
> It would help to be able to reproduce this. The server isn't accessible
> publicly, right?
Right.

> It would probably be helpful if you obtained an HTTP log and a cookie log:
> https://developer.mozilla.org/en/HTTP_Logging
> http://www.mozilla.org/projects/netlib/cookies/cookie-log.html
I will read this docs, and post here the results.
One question: do I can run both logs (HTTP and Cookie) at the same time, or I need to run one of them, and then run another?
I think getting both logs in one run (in a single log file) would be OK.
(In reply to comment #17)
> do I can run both logs (HTTP and Cookie) at the same time, (snip) ?

As written in HTTP_Logging document,
> export NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,nsHostResolver:5
you cann use export NSPR_LOG_MODULES=nsHttp:5,nsSocketTransport:5,cookie:X
(X is 4 in pointed document. I don't know difference between 4 and 5)
To help your work to remove irrelevant log lines, you can put timestamp in NSPR log by next parameter.
> http://www.mozilla.org/projects/nspr/reference/html/prlog.html#25328
> export NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5,cookie:X
You can use NSPR_LOG_MODULES=timestamp,all:5, if you can remove irrelevant log lines before your test steps and irrelevant log lines atter your test steps.
These HTTP and Cookie Logs were generated by Firefox 3.6.4 build 3, where the problem persists.
Note mainly the following lines: 
18911, where the cookie is set;
18966 to 18970, where it said cookie was rejected because it is already expired, but the expiration date is in the future. Very strange.
May be FF "get confused" with Page Expiration date (Expires: Thu, 01 Jan 1970 00:00:00 GMT) versus Cookie Expiration date (Set-Cookie: admin1016398=1157832383; path=/; expires=Sun, 01-Oct-2040 23:00:00 GMT).

Is it possible? Just a thought...
> ===== COOKIE ACCEPTED =====
> request URL: http://www.mozilla.com/en-US/firefox/3.6.4/whatsnew/
> cookie string: WT_FPC=id=201.22.212.181-27298928.30076257:lv=1273162719831:ss=1273162719831; expires=Sun, 03 May 2020 16:18:39 GMT; path=/; domain=mozilla.com

> ===== COOKIE NOT ACCEPTED =====
> request URL: http://176.16.40.126/login.html
> cookie string: admin1016398=1157832383; path=/; expires=Sun, 01-Oct-2040 23:00:00 GMT
> current time: Thu May 06 21:18:46 2010 GMT
> rejected because cookie has already expired

Confirming per log.

Year 2038 problem?
> http://en.wikipedia.org/wiki/Year_2038_problem
Can you check with time just before "03:14:07 UTC on Tuesday, 19 January 2038"?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Checked with 
expires=Tue, 19-Jan-2038 03:14:06 GMT
and worked fine.

However, checked with
expires=Tue, 19-Jan-2038 03:14:08 GMT
and worked fine too.
I am going to test with UTC instead of GMT.
Strange too:

Both 
expires=Tue, 19-Jan-2038 03:14:06 UTC
and 
expires=Tue, 19-Jan-2038 03:14:08 UTC
worked...
(BTW, if you're a developer with a free time on your hands, here's the source in question: http://mxr.mozilla.org/mozilla1.9.2/source/netwerk/cookie/src/nsCookieService.cpp#1550
Here's how you get and build it: https://developer.mozilla.org/en/Build_Documentation )
Unfortunately, I've no free time :-(

I think is very strange it worked with "expires=Tue, 19-Jan-2038 03:14:08 UTC", but not with 2040. Can the timezone have any influence?
(In reply to comment #27)
> I think is very strange it worked with "expires=Tue, 19-Jan-2038 03:14:08 UTC",
> but not with 2040. Can the timezone have any influence?

"UTC" may be invalid in HTTP and is possibly interpreted as local time. (valid one is UT or GMT only as equivalence to +0000 in RFC2822 for mail headers. UTC is not defined in RFC2822). Can you check with next?
> expires=Sun, 01-Oct-2036 23:00:00 GMT
> expires=Sun, 01-Oct-2037 23:00:00 GMT
> expires=Sun, 01-Oct-2038 23:00:00 GMT
> expires=Sun, 01-Oct-2039 23:00:00 GMT
> (I think valid but incorrect week day string is irrelevant, but check with correct one if possible, please)
This (most likely) isn't a problem with parsing expiry time: if the parsing fails, we downgrade the cookie to session, which will not result in the "cookie has already expired" log message.

(Of course, it's possible that PR_ParseTimeString is returning PR_SUCCESS but a bogus date, but that's pretty unlikely. And the tests above confirm that.)

Is the time on your machine set correctly? How are you testing those other dates? What are your cookie preferences? (Search for 'network.cookie' in about:config.)
Also, we shouldn't have a year 2038 problem; I think we support (almost?) all the way out to year 9999.

Going to look at the logs shortly.
(In reply to comment #30)
> Also, we shouldn't have a year 2038 problem; I think we support (almost?) all
> the way out to year 9999.

I think so. I creat test page for test case I wrote comment #28.

I coun't observe year 2038 problem. All cookies were saved by Firefox.
Woops.
My tet page: http://f15.aaa.livedoor.jp/~soarex/moz-test/bug-562198.php 

Jeronimo Fagundes(bug opener):

Can you see problem with my test page?

> with HTML containing
>    <script type="text/javascript">top.window.location='/index.html';\n

Can you check with self.window.location instead of top.window.location?
>    <script type="text/javascript">self.window.location='/index.html';\n
I can see the same with a the current Namoroka and Minefield nightly builds on Linux.
I see a request to create a01 to a05, but only a01 and a02 are created.

http://f15.aaa.livedoor.jp/~soarex/moz-test/bug-562198.php



Output from Live HTTP Headers:

GET /~soarex/moz-test/bug-562198.php HTTP/1.1

Host: f15.aaa.livedoor.jp

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.6pre) Gecko/20100608 Namoroka/3.6.6pre

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 115

Connection: keep-alive

Cookie: __utma=209482629.971522760.1276050080.1276050080.1276050080.1; __utmb=209482629.1.10.1276050080; __utmc=209482629; __utmz=209482629.1276050080.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)



HTTP/1.1 200 OK

Date: Wed, 09 Jun 2010 02:20:54 GMT

Server: Apache/1.3.34 (Unix) PHP/4.3.11 mod_gzip/1.3.26.1a mod_layout/3.2.1

X-Powered-By: ModLayout/3.2.1

Set-Cookie: a01=811170416; path=/; expires=Sun, 01-Oct-2036 23:00:00 GMT

Set-Cookie: a02=811170416; path=/; expires=Sun, 01-Oct-2037 23:00:00 GMT

Set-Cookie: a03=811170416; path=/; expires=Sun, 01-Oct-2038 23:00:00 GMT

Set-Cookie: a04=811170416; path=/; expires=Sun, 01-Oct-2039 23:00:00 GMT

Set-Cookie: a05=811170416; path=/; expires=Sun, 01-Oct-2040 23:00:00 GMT

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html


Looks like a similar issue as reported here:
http://forums.mozillazine.org/viewtopic.php?p=9468569#p9468569
There the CBSlogin doesn't get created.

It looks that it only happens on Linux.
I do not see it in a Windows version that runs under Wine.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.6pre) Gecko/20100608 Namoroka/3.6.6pre
(In reply to comment #33)
> I see a request to create a01 to a05, but only a01 and a02 are created.

What is your Linux ditoro? Is required patches for "Year 2038 problem" installed?
I observe this problem and I made the original report in this link:

http://forums.mozillazine.org/viewtopic.php?p=9468569#p9468569

It is certainly something do do with cookie creation, but I am not knowledgeable enough in the right area to investigate further:

I have not found the exact regression that caused this but here is the summary of when it occurs:

Firefox 3.6.2          --  No Problem
Firefox 3.6.3          --  No problem
Firefox 3.6.4 build1   --  PROBLEM OCCURS
Firefox 3.6.4 build2   --  PROBLEM OCCURS
Firefox 3.6.4 build3   --  PROBLEM OCCURS
Firefox 3.6.4 build4   --  PROBLEM OCCURS
Firefox 3.6.4 build5   --  PROBLEM OCCURS
Firefox 3.6.4 build6   --  PROBLEM OCCURS

NOTE:

I only see this on LINUX and never on WINDOWS

I hope this can be given some priority as there are many LINUX users who are going to experience this when Firefox 3.6.4 is released.
Nominating for blocking. I'll try to repro today or tomorrow to determine whether this should block.
blocking1.9.2: - → ?
status1.9.2: ? → ---
I can't reproduce on Linux x86-64 or Mac. I don't have access to Linux x86 right now...
Reproduced on Linux/x86. Bisecting...
Good somebody else could reproduce it too. I'm a lot busy here, without the time needed to do that.
Only to give some emphasis, the bug was really detected by me on linux x86 too.
(In reply to comment #39)
> Hmm, that's e10s initial landing, it seems...
> 
> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-12-14+03&enddate=2009-12-15+03

I understand this is an issue related to how Unix-based software stores 'time' in 32-bit form, but I would really like to see what actual piece of code submission resulted in Firefox suddenly 'seeing' this issue on Linux 32-bit.

It would be so useful if someone could identify that actual Bug code that led to this 'regression'.  I really don't think I have the skill to do this myself.
Gah, this would have to be the release that the Linux distros are targetting to move all their users to, as well.
Never fear!! I'm on it today. Hopefully I'll have it figured out by end of day.

In the meantime, I think this should block.
blocking2.0: --- → ?
tracking-fennec: --- → ?
No need to block fennec & 1.9.3 -- they're not in imminent release mode and this has been on trunk a while now.
blocking2.0: ? → ---
tracking-fennec: ? → ---
The Cookie Manager can't show those cookies either correctly.
If I create the cookies with a working version and open that profile with a not working version then the cookies that do not work all show as: 
Tue 19 Jan 2038 04:14:07 AM CET

So they seem to get defaulted to 31 bit: 0x7FFFFFFF
They still show correctly if I reopen that profile with the working version.

No problem with displaying such a date with this bookmarklet in the not working version:
javascript:(function(){var D='0',d;while(D){d=new Date();d.setTime(parseInt(D,16)*1000);D=prompt('EPOCH (Stop: Cancel)\n\n'+d,d.toGMTString());}})();

FFFFFFFF  gives Sun, 07 Feb 2106 06:28:15 GMT
FFFFFFFFF gives Sun, 20 Aug 4147 07:32:15 GMT
blocking1.9.2: ? → .4+
Please file a separate bug on the cookiemanager -- that thing's a mess.

Confirmed that the e10s merge is the culprit. No significant changes to cookieservice or nspr in that time. Continuing to bisect...
Got it.

http://hg.mozilla.org/mozilla-central/rev/53e6bb4f487f

bsmedberg, I'm guessing the PR_BEGIN_EXTERN_C change broke this. Investigating...
Aha. The problem is simple: the NSPR symbols (in this case, PR_ParseTimeString) are present in both ipc/chromium and NSPR proper. Since we statically link in ipc/chromium, those symbols get used in Mozilla code instead of the dynamic ones present in NSPR.

Before the PR_BEGIN_EXTERN_C change, those symbols actually had C++ linkage, and didn't conflict. Now they do.

The solution, I think, is to prefix the ipc/chromium NSPR symbols. This will be the most obvious and foolproof. We do this, for example, for modules/zlib.

As a side note, this probably means ipc/chromium's prtime.cc implementation is buggy. We should check that out too...
Summary: Firefox 3.6.4 doesn't obey HTTP Set-Cookie in this case, while Firefox 3.6.3 does → Firefox 3.6.4 doesn't obey HTTP Set-Cookie in this case, while Firefox 3.6.3 does (Fx 3.6.4 on Linux produces Year 2038 problem)
Thanks for the quick investigation Dan!
Attached patch use namespacesSplinter Review
Sticking with C++ linkage seems fine to me, in which case, namespaces are our friend!

I'm not sure what the PR_BEGIN_EXTERN_C was needed for on Windows, but I left the type decls wrapped in it.

In other news, Chromium's implementation of PR_ImplodeTime is obviously hacked up, leading to 2038 fail on Linux: http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/third_party/nspr/prtime.cc#170

Easy to fix, but I don't think we need to do anything about that for 3.6.4.
Assignee: nobody → dwitte
Status: NEW → ASSIGNED
Attachment #450606 - Flags: review?(benjamin)
Comment on attachment 450606 [details] [diff] [review]
use namespaces

As long as it passes tryserver, this is fine. I believe I made the change because there was build-bustage of the form "PR_PaserTimeString: redefinition using different linkage" or something like that.
Attachment #450606 - Flags: review?(benjamin) → review+
Do we think that we need to fix this for 3.6.4? That's still not clear to me; what's the impact of leaving this for 3.6.5?
(In reply to comment #54)
> Do we think that we need to fix this for 3.6.4? That's still not clear to me;
> what's the impact of leaving this for 3.6.5?

Reading the history of this above, it is clear to me that the impact of leaving for 3.6.5 is that 32-bit Linux users would not be able to install and use 3.6.4 without encountering this issue which incidentally I encountered myself on a personal banking page when browsing with 3.6.4 build 6.
Comment on attachment 450606 [details] [diff] [review]
use namespaces

a=LegNeato for 1.9.2.4. Please land it on mozilla-1.9.2 default and GECKO1924_20100413_RELBRANCH
Attachment #450606 - Flags: approval1.9.2.4+
(In reply to comment #54)
> Do we think that we need to fix this for 3.6.4? That's still not clear to me;
> what's the impact of leaving this for 3.6.5?

I think we should take it for 3.6.4. The impact of leaving it is that all the other places in our codebase that use these NSPR time functions will get subtly different behavior -- not just limited to this Linux 2038 problem; they've made other changes too. We've caught it in this case, but there will be others. Hard to know the impact of that without looking at each one, and testing what exact divergences exist, but it's scary.
Tip: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c1a3f5f266fa
Relbranch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/37f5a4a97d26

Try looked OK, but the combination of new m-c tests + try fail yesterday means it's a bit hard to tell. We'll see.

I'll RESO/FIX this to get it off 1.9.2 radar but I still need to land it on m-c.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Keywords: qawanted
Resolution: --- → FIXED
(In reply to comment #58)
> I'll RESO/FIX this to get it off 1.9.2 radar but I still need to land it on
> m-c.

That's not how we track things. Bug resolution is *always* tied to trunk. The status fields are used for branch tracking.

Why didn't this land on m-c first?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Because we're trying to ship a 3.6.4, yo.
Aaaand landed. http://hg.mozilla.org/mozilla-central/rev/2d0857d84e98
Status: ASSIGNED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
After discussion on IRC, here are the STR:


1. Open terminal
2. export NSPR_LOG_FILE=~/cookie-log.txt && export NSPR_LOG_MODULES=cookie:4
3. Start Firefox and load http://f15.aaa.livedoor.jp/~soarex/moz-test/bug-562198.php
4. Close Firefox
5. Look at the logfile

RESULT: There should be three COOKIE NOT ACCEPTED with reason "cookie has already expired" for the a0x and b0x cookies
Three for the a0x and five for the b0x, yeah.
Attached file Good Cookie Log
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.6pre) Gecko/20100611 Namoroka/3.6.6pre

I've done a preliminary verification of this bug fix using a tryserver build provided by Dwitte:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/dwitte@mozilla.com-35481c309f34/

The attached log file shows all cookies being accepted.
NOTE: QA will not mark this bug as verified until we have a chance to check this against builds off the rel-branch.
I've tested it with the latest hourly builds of both Namoroka and Minefield and can confirm that the cookies are created as expected in those builds.
The patch also fixed the issue with the Cookie Manager that I mentioned in bug 562198#c47
All expire dates show as specified in the Cookie Manager.

Tested with:
http://f15.aaa.livedoor.jp/~soarex/moz-test/bug-562198.php
https://www.coventrybuildingsociety.co.uk/onlineservices/login/ols_login.aspx

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-1.9.2-linux/1276290053/
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux/1276286582/
(In reply to comment #52)
> ---
> In other news, Chromium's implementation of PR_ImplodeTime is obviously hacked
> up, leading to 2038 fail on Linux:
> http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/third_party/nspr/prtime.cc#170
> 
> Easy to fix, but I don't think we need to do anything about that for 3.6.4.

Is there another Bug filed to pick this issue up and track it?.
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4

Verified fixed on 3.6.4build7.
Keywords: verified1.9.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: