From parent bug: This is possibly the same cause as bug 601739, but it's a different error, so filing it separately. Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsICookieManager2.getCookiesFromHost]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: resource:///components/nsSessionStore.js :: <TOP_LEVEL> :: line 2205" data: no] Source File: resource:///components/nsSessionStore.js Line: 2205 STR: 1. Go to www..emacs (this happened to be how I repro'd) 2. Go anywhere 2 might not even be necessary. I guess www..emacs is in session history and somehow being used to get hosts. That's not a real host, so cookie svc says no. So I'm putting this up to 2 choices: 1. Fix our host regex 2. Just try-catch getCookiesFromHost, discarding bad hosts
Attachment #545873 - Flags: review?(neil)
Pushed, with some whitespace nits: http://hg.mozilla.org/comm-central/rev/e42ccacdc80a
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
The base bug landed on Beta (FF7) already. Please action accordingly.
Callek, you said 2.4b3 is due today and should be our last 2.4 beta. I already noted that this bug should land on Beta two weeks ago in the status meeting. Please consider respinning with this one included if you already started building.
(In reply to Jens Hatlak (:InvisibleSmiley) from comment #3) > Callek, you said 2.4b3 is due today and should be our last 2.4 beta. I > already noted that this bug should land on Beta two weeks ago in the status > meeting. Please consider respinning with this one included if you already > started building. Ugh, this should have had approval flag set, and I'm not sure the risk involved. Taking it would involve an extra ~48 hours of time before I can release b3, which means less than a week of testing of our final beta before we can release 2.4 final. Is this one bug worth delaying for that and decreasing our confidence in 2.4 final? Said another way, if this was our final build, would you consider this strong enough to respin and *delay* the final build for, or can this slip to be released in 6 weeks. Also to be clear, is this a *regression* for past behavior for us with session-store (if so, what version first exhibited this bug), or is it an issue we have had for many versions? Please flag this approval? when you answer these Q's, I'll look before I do our final release for 2.4b3 and go from there.
(In reply to Justin Wood (:Callek) from comment #4) > Ugh, this should have had approval flag set Obviously, but it's not my bug so I don't know whether it was overlooked or deliberately not requested. > and I'm not sure the risk involved. Me too. The original bug talks about "a potential error that causes session restore to stop saving state". Personally I didn't run into this [and won't, since I'm now on Aurora where it's already fixed], and I haven't seen any complaints on the newsgroups, so I cannot even given a good estimate of the impact probability. > Said another way, if this was our final build, would you consider this > strong enough to respin and *delay* the final build for, or can this slip to > be released in 6 weeks. Well, given that we don't know *for sure* that is has a measurable impact, I'd say we can let it slip. I was just hoping that it could still make it without too much hassle, but it seems that time has passed. In general I'd like to see us come up with an SOP (standard operating procedure) of how to make sure such bugs and issues are flagged accordingly *in time* without having someone like me (or you) have to keep an eye on everything all the time. Obviously the approach I took (noting it in the status meeting notes) didn't work out so well. Maybe the SeaMonkey Members mailing list better suits that goal. Ideally of course, everyone would keep an eye on their respective field, but ultimately it's more important for me that nothing gets lost than that certain people take responsibility. > Please flag this approval? when you answer these Q's I'll leave that decision to Misak and/or Neil.
You need to log in before you can comment on or make changes to this bug.