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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: jeronimo, Assigned: dwitte)
Details
(Keywords: regression, verified1.9.2)
Attachments
(7 files, 2 obsolete files)
26.22 KB,
text/plain
|
Details | |
15.23 KB,
text/plain
|
Details | |
Interaction browser-server with Trunk (03-May-2010 03:01), from Wireshark, no-cookies previously set
15.20 KB,
text/plain
|
Details | |
15.20 KB,
text/plain
|
Details | |
1.96 MB,
text/plain
|
Details | |
8.47 KB,
patch
|
benjamin
:
review+
christian
:
approval1.9.2.4+
|
Details | Diff | Splinter Review |
10.56 KB,
text/plain
|
Details |
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
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
Comment 3•14 years ago
|
||
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
Comment 4•14 years ago
|
||
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.
Comment 5•14 years ago
|
||
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
Comment 6•14 years ago
|
||
(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>?
Reporter | ||
Comment 7•14 years ago
|
||
I'm going to test with a previous condition cookie-free, I mean, no cookies set before that test.
Comment 8•14 years ago
|
||
Not blocking until it's confirmed. Please feel free to renominate if that happens.
blocking1.9.2: ? → -
Reporter | ||
Comment 9•14 years ago
|
||
Now, I tested with no cookies previously set. Following to this comment I'm attaching the two files.
Reporter | ||
Comment 10•14 years ago
|
||
Attachment #441961 -
Attachment is obsolete: true
Reporter | ||
Comment 11•14 years ago
|
||
Attachment #441962 -
Attachment is obsolete: true
Reporter | ||
Comment 12•14 years ago
|
||
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).
Reporter | ||
Comment 13•14 years ago
|
||
Interaction with Trunk (03-May-2010 03:01). The problem is reproducible.
Reporter | ||
Comment 14•14 years ago
|
||
Interaction with Latest(1.9.2) (03-May-2010 03:30). The problem is reproducible.
Comment 15•14 years ago
|
||
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.
Reporter | ||
Comment 16•14 years ago
|
||
(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.
Reporter | ||
Comment 17•14 years ago
|
||
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?
Comment 18•14 years ago
|
||
I think getting both logs in one run (in a single log file) would be OK.
Comment 19•14 years ago
|
||
(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.
Reporter | ||
Comment 20•14 years ago
|
||
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.
Reporter | ||
Comment 21•14 years ago
|
||
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...
Comment 22•14 years ago
|
||
> ===== 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
Reporter | ||
Comment 23•14 years ago
|
||
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.
Reporter | ||
Comment 24•14 years ago
|
||
I am going to test with UTC instead of GMT.
Reporter | ||
Comment 25•14 years ago
|
||
Strange too: Both expires=Tue, 19-Jan-2038 03:14:06 UTC and expires=Tue, 19-Jan-2038 03:14:08 UTC worked...
Comment 26•14 years ago
|
||
(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 )
Reporter | ||
Comment 27•14 years ago
|
||
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?
Comment 28•14 years ago
|
||
(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)
Assignee | ||
Comment 29•14 years ago
|
||
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.)
Assignee | ||
Comment 30•14 years ago
|
||
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.
Comment 31•14 years ago
|
||
(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.
Comment 32•14 years ago
|
||
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
Comment 33•14 years ago
|
||
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
Comment 34•14 years ago
|
||
(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?
Comment 35•14 years ago
|
||
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.
Comment 36•14 years ago
|
||
Last 3.6.3pre build. > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/04/2010-04-01-03-mozilla-1.9.2/firefox-3.6.3pre.en-US.linux-i686.tar.bz2 First 3.6.4pre build. > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/04/2010-04-02-03-mozilla-1.9.2/firefox-3.6.4pre.en-US.linux-i686.tests.tar.bz2 Firefox 3.6.4 candidate build1. > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.6.4-candidates/build1/linux-i686/en-US/firefox-3.6.4.tar.bz2 > 13-Apr-2010 16:33 10M
Assignee | ||
Comment 37•14 years ago
|
||
Nominating for blocking. I'll try to repro today or tomorrow to determine whether this should block.
blocking1.9.2: - → ?
status1.9.2:
? → ---
Comment 38•14 years ago
|
||
If it is the Year 2038 problem then it is a cookie problem 32 bit dates in Firefox on Linux. Found a regression range on trunk (mozilla-central). Works: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/12/2009-12-14-03-mozilla-central/firefox-3.7a1pre.en-US.linux-i686.tar.bz2 Doesn't work: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/12/2009-12-15-03-mozilla-central/firefox-3.7a1pre.en-US.linux-i686.tar.bz2
Comment 39•14 years ago
|
||
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
Assignee | ||
Comment 40•14 years ago
|
||
I can't reproduce on Linux x86-64 or Mac. I don't have access to Linux x86 right now...
Assignee | ||
Comment 41•14 years ago
|
||
Reproduced on Linux/x86. Bisecting...
Reporter | ||
Comment 42•14 years ago
|
||
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.
Comment 43•14 years ago
|
||
(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.
Comment 44•14 years ago
|
||
Gah, this would have to be the release that the Linux distros are targetting to move all their users to, as well.
Assignee | ||
Comment 45•14 years ago
|
||
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.
Updated•14 years ago
|
blocking2.0: --- → ?
tracking-fennec: --- → ?
Assignee | ||
Comment 46•14 years ago
|
||
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: ? → ---
Comment 47•14 years ago
|
||
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
Assignee | ||
Comment 48•14 years ago
|
||
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...
Assignee | ||
Comment 49•14 years ago
|
||
Got it. http://hg.mozilla.org/mozilla-central/rev/53e6bb4f487f bsmedberg, I'm guessing the PR_BEGIN_EXTERN_C change broke this. Investigating...
Assignee | ||
Comment 50•14 years ago
|
||
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...
Updated•14 years ago
|
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)
Comment 51•14 years ago
|
||
Thanks for the quick investigation Dan!
Assignee | ||
Comment 52•14 years ago
|
||
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.
Comment 53•14 years ago
|
||
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+
Comment 54•14 years ago
|
||
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?
Comment 55•14 years ago
|
||
(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 56•14 years ago
|
||
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+
Assignee | ||
Comment 57•14 years ago
|
||
(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.
Assignee | ||
Comment 58•14 years ago
|
||
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
status1.9.2:
--- → .4-fixed
Keywords: qawanted
Resolution: --- → FIXED
Comment 59•14 years ago
|
||
(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 → ---
Updated•14 years ago
|
Status: REOPENED → ASSIGNED
Assignee | ||
Comment 60•14 years ago
|
||
Because we're trying to ship a 3.6.4, yo.
Assignee | ||
Comment 61•14 years ago
|
||
Aaaand landed. http://hg.mozilla.org/mozilla-central/rev/2d0857d84e98
Status: ASSIGNED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 62•14 years ago
|
||
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
Assignee | ||
Comment 63•14 years ago
|
||
Three for the a0x and five for the b0x, yeah.
Comment 64•14 years ago
|
||
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.
Comment 65•14 years ago
|
||
NOTE: QA will not mark this bug as verified until we have a chance to check this against builds off the rel-branch.
Comment 66•14 years ago
|
||
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/
Comment 67•14 years ago
|
||
(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?.
Comment 68•14 years ago
|
||
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.
Description
•