EV identifier is no longer displayed for addons.mozilla.org when restoring session and HTTP cache v2 enabled

VERIFIED FIXED in Firefox 32

Status

()

Core
Security: PSM
--
blocker
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: mihaelav, Assigned: mayhemer)

Tracking

(Depends on: 1 bug, {regression})

unspecified
mozilla34
regression
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox31 unaffected, firefox32 verified, firefox33 verified, firefox34 verified)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Bug 995801 is reproducing again with the latest Nightly build:
Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0, build id: 20140717030339,
Built from https://hg.mozilla.org/mozilla-central/rev/a74600665875

+++ This bug was initially created as a clone of Bug #995801 +++

Steps To Reproduce:
1. Open Web pages which have EV identifier
   i.e. https://addons.mozilla.org/en-US/firefox/
        https://bugzilla.mozilla.org/
  --- observe, youcan see green EV identifier
2. Exit Browser And Start Firefox again
3. Restore Previous Session

Actual Results:
  EV identifier is no longer displayed after doing "Restore Previous Session"
(Reporter)

Comment 1

3 years ago
The bug is only reproducible on addons.mozilla.org
Component: DOM: Security → Administration
Product: Core → addons.mozilla.org
Version: 29 Branch → unspecified
No longer depends on: 995801
Why is this bug part of addons.mozilla.org? Have you tested if that is the same behavior across all versions of Firefox? Also could this be a regression in Firefox? I don't see that those checks have been done. I don't think this is something related to AMO itself.
(Reporter)

Comment 3

3 years ago
Yes, I tested it on older versions of Nightly (16June, 1 July, 7 July) and Aurora which worked before and it's reproducible and ONLY with addons.mozilla.org.
It is not reproducible with Firefox 31 (tried beta 5 and RC)
I can confirm. 

I saw an additional problem:
Trying to expand the certificate (via clicking more information) to see what's up makes the dialog construct and immediately disappear. But this went away after a while.

That said, there's no reason to believe it's a bug with the *site*.
Component: Administration → DOM: Security
Product: addons.mozilla.org → Core
Version: unspecified → Trunk
Right, so please check for the regression range.
Keywords: regressionwindow-wanted
status-firefox31: --- → unaffected
status-firefox32: --- → ?
status-firefox33: --- → affected
tracking-firefox33: --- → ?
(Reporter)

Comment 6

3 years ago
As mentioned in comment #3 (and discussed with gcp on IRC), this is not a Firefox issue, but a site one.
The issue only reproduces on addons.mozilla.org, it is not reproducible with other EV certificate sites, like bugzilla.mozilla.org or op.fi.
The issue is now reproducible on builds which worked fine before (like the June 16 Nightly and Aurora, July 7 Nightly), after the fix for bug 995801 landed and was successfully verified by QA.
Still, it seems that it works fine on the Firefox 31 beta/RC builds.
Component: DOM: Security → Administration
Keywords: regressionwindow-wanted
Product: Core → addons.mozilla.org
Version: Trunk → unspecified
If you say it works with older versions of Firefox why wouldn't you want a regression window? It may be a site issue or a Firefox issue. Knowing what change in Firefox makes it no longer work is surely going to be very informative.
Keywords: regressionwindow-wanted
Hi Mihaela,

For example certificate pinning was enabled for addons.mozilla.org in FF 32. That would be a Firefox issue *and* a site issue if it broke recently. I don't think pinning is responsible for this particular breakage don't think we can eliminate the possibility that it is a Firefox issue quite yet. There have also been many changes to certificate verification and OSCP interaction with EV recently. Actually, I suspect one of those, needinfo'ing keeler.

Thanks,
Monica
Flags: needinfo?(dkeeler)
I also cannot reproduce the breakage on mac on 7/17's nightly.

Comment 10

3 years ago
Steps To Reproduce:
1. Make sure uncheck "Don't load tabs until selected". i.e, browser.sessionstore.restore_on_demand = false
2. Open any web page in [TAB A]
3. Open https://addons.mozilla.org/en-US/firefox/ in [TAB B]
4. Select [TAB A]
5. Exit Browser And Start Firefox again
6. Restore Previous Session
7. Select [TAB B] after completion to load all tabs

Actual Results:
  EV identifier is no longer displayed after doing "Restore Previous Session"


Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/e8df6826a571
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140703202504
Bad:
https://hg.mozilla.org/mozilla-central/rev/0bcf1102e943
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140704044517
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e8df6826a571&tochange=0bcf1102e943


Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7231daefbb28
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140703232503
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/240a0b085725
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140703234337
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7231daefbb28&tochange=240a0b085725

Regressed by:
240a0b085725	Harsh Pathak — Bug 643041 - Merge nsIX509Cert2 and nsIX509Cert3 into nsIX509Cert, and merge nsIX509CertDB2 into nsIX509CertDB. r=keeler
Blocks: 643041

Updated

3 years ago
status-firefox32: ? → unaffected
Thanks a lot Alice for this ultra-fast regression analysis! Moving bug back into Core.
Component: Administration → Security: PSM
Keywords: regressionwindow-wanted
Product: addons.mozilla.org → Core
I can reproduce the problem in aurora (32), which means that bug 643041 isn't the culprit (it landed in 33 and hasn't been uplifted). I will investigate further tomorrow.
No longer blocks: 643041
Flags: needinfo?(dkeeler)

Comment 13

3 years ago
Not able to reproduce the issue for 7/17's nightly on Mac.
(Reporter)

Comment 14

3 years ago
(In reply to Alice0775 White from comment #10)
> Steps To Reproduce:
> 1. Make sure uncheck "Don't load tabs until selected". i.e,
> browser.sessionstore.restore_on_demand = false
> 2. Open any web page in [TAB A]
> 3. Open https://addons.mozilla.org/en-US/firefox/ in [TAB B]
> 4. Select [TAB A]
> 5. Exit Browser And Start Firefox again
> 6. Restore Previous Session
> 7. Select [TAB B] after completion to load all tabs
> 
> Actual Results:
>   EV identifier is no longer displayed after doing "Restore Previous Session"

I reproduce the issue with more simple steps:
1. Launch Firefox with new profile
2. Go to addons.mozilla.org -> so far, this is the only website I reproduced the issue with
3. Close Firefox
4. Start Firefox again, with the same profile as in step 1
5. Restore previous session

Result: EV identifier is not displayed for addons.mozilla.org

> Regression window(m-c)
> Good:
> https://hg.mozilla.org/mozilla-central/rev/e8df6826a571
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
> ID:20140703202504
> Bad:
> https://hg.mozilla.org/mozilla-central/rev/0bcf1102e943
> Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
> ID:20140704044517
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=e8df6826a571&tochange=0bcf1102e943

As mentioned in comment #3, I can reproduce the issue even on older builds, like July 1 Nightly and June 16 Aurora, with the steps I provided in this comment.

(In reply to hpathak from comment #13)
> Not able to reproduce the issue for 7/17's nightly on Mac.

I can still reproduce on Ubuntu with latest Nightly build (20140718030202) and steps I mentioned in this comment

(In reply to David Keeler (:keeler) [use needinfo?] from comment #12)
> I can reproduce the problem in aurora (32), which means that bug 643041
> isn't the culprit (it landed in 33 and hasn't been uplifted). I will
> investigate further tomorrow.

I also reproduced the issue with a June 16 Aurora. Bug 995801, which has the same STR, was verified on June 13 Aurora build and it worked fine then (on addons.mozilla.org and other pages).
Summary: EV identifier is no longer displayed in Location Bar/Arrow Panel after a restart of Firefox → EV identifier is no longer displayed for addons.mozilla.org after a restart of Firefox

Comment 15

3 years ago
:mihaelav
So, regression range?
status-firefox32: unaffected → ?
Flags: needinfo?(mihaela.velimiroviciu)
Keywords: regressionwindow-wanted
(Reporter)

Comment 16

3 years ago
OS: Ubuntu 14.04, x86

I cannot determine the "exact" regression range here because of bug 995801.
Here is what I found while trying to get a regression range:
* 18Jan2014 Nightly - all works fine (EV certificate identifier is displayed for all sites after restart and session restore - with steps from comment 14)
* 19Jan2014 Nightly - first build on which I reproduced bug 995801 (EV certificate identifier is not displayed in the location bar for ALL sites - with AMO and bugzilla.mozilla.org and steps from comment 14)
* 29May2014 Nightly - first build on which bug 995801 was fixed (and later verified as fixed by QA); this is also the first build on which NOW I reproduce the issue but ONLY with addons.mozilla.org (I cannot reproduce it with bugzilla.mozilla.org, with the same steps as in comment 14)

I usually use latest Nightly builds and didn't see the issue while using those builds in June 17 - July 11 timeframe (although I tested around this area).
Flags: needinfo?(mihaela.velimiroviciu)
Have you been able to reproduce on Nightly? Would like to see some reproduction on Nightly to help make the tracking decision.
Flags: needinfo?(anthony.s.hughes)
(In reply to Benjamin Kerensa [:bkerensa] from comment #17)
> Have you been able to reproduce on Nightly? Would like to see some
> reproduction on Nightly to help make the tracking decision.

I'm not able to reproduce this bug with the steps provided. Perhaps someone who is able to reproduce this would be better to make that judgement call. However, if this is truly isolated to just addons.mozilla.org, I'd be inclined not to track it.
Flags: needinfo?(anthony.s.hughes)
(Reporter)

Comment 19

3 years ago
I can still reproduce the issue with latest Nightly build (Build identifier: Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0, build id 20140720030203) with my steps from comment #14
100% reproducible with a clean profile on win7 x64 with latest m-c Nightly build.  

I cannot repo with my 2 year old 'dirty' profile.  Cleaning History and Cookies for AMO makes no difference, here it still shows the EV on the dirty profile.

This on AMO only, Bugzilla & Paypal both display EV in both clean/dirty profiles.
Harsh, does it a bell?

Anyway, tracking because EV matters.
status-firefox32: ? → affected
tracking-firefox32: --- → +
tracking-firefox33: ? → +
tracking-firefox34: --- → +
Flags: needinfo?(hpathak)
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #20)
> I cannot repo with my 2 year old 'dirty' profile.  Cleaning History and
> Cookies for AMO makes no difference, here it still shows the EV on the dirty
> profile.

Jim, what happens when you clean the cache first? Or any other setting through "Clear Recent History"? Something has to cause this, even if it is a user preference.
(In reply to Henrik Skupin (:whimboo) from comment #22)
> (In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #20)
> > I cannot repo with my 2 year old 'dirty' profile.  Cleaning History and
> > Cookies for AMO makes no difference, here it still shows the EV on the dirty
> > profile.
> 
> Jim, what happens when you clean the cache first? Or any other setting
> through "Clear Recent History"? Something has to cause this, even if it is a
> user preference.

Sorry for delay, required a bunch of testing.

I have found for me at least that the new Cache2 is the causing the problem.
My 'dirty' profile I have the new Cache2 disabled and still using the old cache.

Turning off the new cache2 in about:config, 
Open the Options panel - Custom Setting -> Privacy -> Settings, clear everything
Close Browser
Delete the cache folders manually in Windows Explorer
Restart the browser - Options panel uncheck 'clear history' on close
visit AMO 
open/close several times with the 'old cache' after clearing everying and cache2 'off' and AMO will show EV everytime.
comment 23
Flags: needinfo?(michal.novotny)
Great catch Jim! I can perfectly replicate this behavior on my box. So it's clearly the HTTP cache v2, which is causing this problem.
Blocks: 913806
Summary: EV identifier is no longer displayed for addons.mozilla.org after a restart of Firefox → EV identifier is no longer displayed for addons.mozilla.org when restoring session and HTTP cache v2 enabled

Comment 26

3 years ago
(In reply to Sylvestre Ledru [:sylvestre] from comment #21)
> Harsh, does it a bell?

As Jim/Henrik have mentioned, its probably due to caching v2. Also, as per comment 12, this was present in aurora before the uplift.
Flags: needinfo?(hpathak)
It's almost impossible to reproduce this bug on my linux machine. I hit it just twice in many tries. AFAICS this is definitely not a cache2 bug. This is just a coincidence that it can be reproduced with cache2 and not with the old cache. What happens is that the security info is stored to the cache entry sooner than the certificate is validated, so the certificate is stored with mCachedEVStatus == ev_status_unknown. After restart, the security info is read from the cache entry and it is not re-validated, instead the mCachedEVStatus is set to ev_status_invalid in nsNSSCertificate::getValidEVOidTag().

I don't know the security code, so I don't know whether the problem is that we store the certificate with unknown EV state or that the certificate is not re-validated when we read such certificate from the cache.
Flags: needinfo?(michal.novotny)
David, any idea who could look at this?  Sounds like it's a matter of making sure the cert has been validated by the time we store security info in the cache.  Michal is under the impression that's where the bug is here, and not in the cache itself.
Flags: needinfo?(dkeeler)
Right now we don't re-validate certificates from the cache (see bug 660749). My guess is the entry is being stored in the cache when mCachedEVStatus = ev_status_unknown and isn't getting replaced when mCachedEVStatus is set to ev_status_valid. Since Honza knows both PSM and Necko, I think he would be a good candidate for figuring this out.
Flags: needinfo?(dkeeler)
Flags: needinfo?(honzab.moz)
I agree Honza would be a good person for this, but he's out on PTO for an unknown amount of time.  And this bug is presumably on beta (firefox 32) because that's when cache2 landed.  So if this is important enough to not land on release we'll need to find someone else.  

From my very quick parsing of bug 660749 it sounds like we want to teach the HTTP cache to revalidate anyway for other reasons (at least if the symptoms in bug 660749 comment 0 are still true, i.e. "accept this cert only for this session" is broken when cached).  But that also sounds like it would involve storing new fields in the cache (bug 660749 comment 50), which is a large-ish change for late in the beta cycle.  How bad do we consider this bug?
Valentin's going to try to fix this (probably by fixing bug 660749).
Assignee: nobody → valentin.gosu
I think I may have figured out how to do the revalidation. However, I'm confused about when we should be doing it. If we dispatch the task to revalidate when we load the cache entry from disk and it has a ev_status_unknown, would the revalidation fix this issue? Or do we need to refresh the page somehow to get the green EV identifier to display?
Flags: needinfo?(jduell.mcbugs)
Keep in mind that verifying a certificate for EV requires revocation information, which means fetching OCSP (until we have OCSP GET, this information isn't cached on disk). Doing this on the main thread is undesirable. Doing it at all is a bummer because in this case we're loading a site from the cache but we're still taking the performance hit by waiting on the network.
Michal indicated CacheEntry::GetSecurityInfo() as a good place to start, so I'm going to look at that.
This revalidation shouldn't be too costly, as it would only happen for cache entries that are saved before the validation is finished. It would be great if we could delay saving the entry to disk for a while, but revalidating it seems a good compromise in the mean time.
Flags: needinfo?(jduell.mcbugs)
It does seem like waiting for validation before saving the entry to disk would be ideal here.  Is that more complicated than adding revalidation?  Perhaps we could add some "wait for notification to write cache entry to disk" flag on channels?
Depends on: 660749
Upon investigation I managed to figure out the issue. Bug 660749 comment 52. I'm moving the discussion to that bug, in hope that we can figure out a fix.
(In reply to Valentin Gosu [:valentin] from comment #36)
> Upon investigation I managed to figure out the issue. Bug 660749 comment 52.
> I'm moving the discussion to that bug, in hope that we can figure out a fix.

Does this mean that this bug should be marked as a dup of bug 660749?
Flags: needinfo?(valentin.gosu)
Yes, this is the same bug. Feel free to mark it as a duplicate unless you want it to be tracked separately.
Flags: needinfo?(valentin.gosu)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 660749
tracking-firefox32: + → ---
tracking-firefox33: + → ---
tracking-firefox34: + → ---
(Assignee)

Comment 40

3 years ago
Discussion moved to a different bug.
Flags: needinfo?(honzab.moz)
(Assignee)

Comment 41

3 years ago
Hmm.. that bug is a bit about a different issue, reopening as a standalone issue.  This has nothing to do with cert revalidation, this is probably an unrelated regression.


Mihaela, Alice0775, can you please provide content of a file located at:

  <profile>/cache2/entries/6D58A80BA1A95408C85CE28E9AE05FC839FA7AE2 

for the case you can reproduce the missing EV status?  That is the file bound to the https://addons.mozilla.org/en-US/firefox/ URL, I want to make sure it's cache that stores the status wrong.

Thanks.
Status: RESOLVED → REOPENED
Flags: needinfo?(mihaela.velimiroviciu)
Flags: needinfo?(alice0775)
Resolution: DUPLICATE → ---

Comment 42

3 years ago
I cannot reproduce the problem on latest Nightly34.0a1 and Aurora33.a2 as well.

I cannot reproduce the problem on bad build of Comment 10 too....
Flags: needinfo?(alice0775)
Created attachment 8475306 [details]
logs and cache entries

(In reply to Honza Bambas (:mayhemer) from comment #41)
> for the case you can reproduce the missing EV status?  That is the file
> bound to the https://addons.mozilla.org/en-US/firefox/ URL, I want to make
> sure it's cache that stores the status wrong.

I think it's clear from my comment #27. Attached are logs from my linux box where I was able to reproduce it just twice. The cache entries are from my windows notebook, where I was able to reproduce it much more often, but I don't have development environment there.
Flags: needinfo?(mihaela.velimiroviciu)
(Assignee)

Comment 44

3 years ago
(In reply to Michal Novotny (:michal) from comment #43)
> Created attachment 8475306 [details]
> logs and cache entries
> 
> (In reply to Honza Bambas (:mayhemer) from comment #41)
> > for the case you can reproduce the missing EV status?  That is the file
> > bound to the https://addons.mozilla.org/en-US/firefox/ URL, I want to make
> > sure it's cache that stores the status wrong.
> 
> I think it's clear from my comment #27. 

I wasn't sure you really have seen the badly stored value.

> Attached are logs from my linux box
> where I was able to reproduce it just twice. The cache entries are from my
> windows notebook, where I was able to reproduce it much more often, but I
> don't have development environment there.

Thanks!
Still 100% reproducable here on the latest m-c hourly build on win7 x64.

cset: https://hg.mozilla.org/mozilla-central/rev/4d94eeca89f3

Using my steps above it was easily re-created using AMO and having the cache2 enabled.
(Assignee)

Comment 46

3 years ago
I think I know why this demonstrates so more often with cache v2.  The same bug is in cache v1 - the same race condition!

Difference is that cache v1 serializes the security info simply later, in nsDiskCacheMap::CreateDiskCacheEntry.  Cache v2 does it immediately when the object is set on the entry in nsHttpChannel::AddCacheEntryHeaders which is mostly called very soon from nsHttpChannel::OnStartRequest.  I don't follow why there is this race, the EV state cache should be up-to-date at that moment.  However chasing that bug - if that is a bug - is an overkill.

I can think of storing the sec-info again in e.g. OnStopRequest as a short-therm workaround.  Other way (more correct IMO) could be to just set the object down at the CacheFileMetadata that are persisted way later.  Serialization of the object can happen there.  It's mid-complex work to do.
Assignee: valentin.gosu → honzab.moz
Status: REOPENED → ASSIGNED
(Assignee)

Comment 47

3 years ago
Plan failed - when we serialize sec info at the time we want to write the metadata there is a race with NSS shutdown (happening at profile-before-change): nsNSSCertificate has already dropped the reference to mCert, hence it cannot be serialized anymore...  Our final pending metadata serialization happens in xpcom-shutdown.

I'll try the OnStopRequest:SetSecurityInfo approach and submit a try to check with.
(Assignee)

Comment 48

3 years ago
Created attachment 8476338 [details] [diff] [review]
v1

https://tbpl.mozilla.org/?tree=Try&rev=864f565ec187

Anyone able to reproduce, please check with these try builds (at this time in progress of build).  Hopefully we will at least minimize the number of occasions to insignificant percents.
(In reply to Honza Bambas (:mayhemer) from comment #48)
> Created attachment 8476338 [details] [diff] [review]
> v1
> 
> https://tbpl.mozilla.org/?tree=Try&rev=864f565ec187
> 
> Anyone able to reproduce, please check with these try builds (at this time
> in progress of build).  Hopefully we will at least minimize the number of
> occasions to insignificant percents.

Tested with 2 different vanilla profiles just to be sure, cleared cache and cache2.  

After visiting AMO, and doing several restarts of the browser in both profiles I can confirm that I'm NOT able to reproduce the issue, where before it was very easy to do, so this looks from my end.
(Assignee)

Comment 50

3 years ago
Comment on attachment 8476338 [details] [diff] [review]
v1

Seems like a good workaround, thanks for the test Jim!

https://tbpl.mozilla.org/?tree=Try&rev=857e7aaeefb8
Attachment #8476338 - Flags: review?(michal.novotny)
Attachment #8476338 - Flags: review?(michal.novotny) → review+
Comment on attachment 8476338 [details] [diff] [review]
v1

Review of attachment 8476338 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/http/nsHttpChannel.cpp
@@ +3655,5 @@
>      if (doom) {
>          LOG(("  dooming cache entry!!"));
>          mCacheEntry->AsyncDoom(nullptr);
> +    } else {
> +      // Store updated security info, makes the cached EV status race less likely

might be worth putting bug # in comment, in case this ever gets cut-and-pasted, etc.  Not a big deal.
Comment on attachment 8476338 [details] [diff] [review]
v1

Approval Request Comment
[Feature/regressing bug #]: long standing but aggravated by cache2
[User impact if declined]: see bug: no EV shown when session restored from cache
[Describe test coverage new/current, TBPL]: no, but we have STR
[Risks and why]: low risk.  One liner, just writes data to disk later.
[String/UUID change made/needed]: none
Attachment #8476338 - Flags: approval-mozilla-beta?
Attachment #8476338 - Flags: approval-mozilla-aurora?
 https://hg.mozilla.org/integration/mozilla-inbound/rev/543af9cd7448
Due to scheduling reasons, this isn't likely to make it over to m-c tonight, but it's sufficiently green on inbound that I'm confident saying that it's not getting backed out at this point.
Comment on attachment 8476338 [details] [diff] [review]
v1

Approved for aurora and beta based on the patch being green on inbound.
Attachment #8476338 - Flags: approval-mozilla-beta?
Attachment #8476338 - Flags: approval-mozilla-beta+
Attachment #8476338 - Flags: approval-mozilla-aurora?
Attachment #8476338 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/a10c80107907
https://hg.mozilla.org/releases/mozilla-beta/rev/33ea2d7e342e
status-firefox32: affected → fixed
status-firefox33: affected → fixed
status-firefox34: --- → fixed
Flags: qe-verify+
(Reporter)

Comment 57

3 years ago
I tested with Firefox 32.0 beta 9, latest Aurora (Aug 22) and latest Nightly(Aug 22) on the following environments:
* Ubuntu 14.04, 32 bit
* Mac OS 10.8.5

I wasn't able to reproduce the issue anymore with Firefox 32 beta 9 and latest Aurora, BUT latest Nightly seems to still have some issues. After several tries/restarts, having multiple pages with EV certificate open (a few addons.mozilla.org/... pages and a few bugzilla.mozilla.org/... ones) I noticed that one (randomly) of the tabs doesn't show the EV identifier (instead, it shows the DV one). I tried on several clean profiles on Mac and Ubuntu, and I was able to reproduce this (with different page each time, once it was one of the AMO pages - on Ubuntu, some times it was one of the Bugzilla pages - search page, a bug page, etc - on Mac).

I couldn't reproduce this on Aurora nor on Beta, yet, and haven't tested on Windows because the builds are not available.
Flags: needinfo?(honzab.moz)
(Assignee)

Comment 58

3 years ago
Mihaela, Thanks.  As I said, there still is a possibility for the root race condition.  The patch mostly just makes is much less likely to happen.

I believe you will be able to (less likely, but still likely) reproduce it even with cache v1.

Let's file a new bug like "rarely missing EV on session restore" if you are confident this really happens rarely.
Flags: needinfo?(honzab.moz)
Tested this on Win7 using Fx32b9(build1) and I haven't been able to reproduce the problem. I won't mark it as verified on beta until Mihaela has a chance to double check.
https://hg.mozilla.org/mozilla-central/rev/543af9cd7448
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
(Reporter)

Comment 61

3 years ago
I tested on Win 7 x64 with Firefox 32 beta 9, latest Aurora and latest Nightly and didn't reproduce the issue. 
Marking verified across all branches.
Status: RESOLVED → VERIFIED
status-firefox32: fixed → verified
status-firefox33: fixed → verified
status-firefox34: fixed → verified
(Reporter)

Updated

3 years ago
Blocks: 1058009
(Reporter)

Comment 62

3 years ago
(In reply to Honza Bambas (:mayhemer) from comment #58)
> Let's file a new bug like "rarely missing EV on session restore" if you are
> confident this really happens rarely.

Logged bug 1058009
(In reply to Honza Bambas (:mayhemer) from comment #58)
> Mihaela, Thanks.  As I said, there still is a possibility for the root race
> condition.  The patch mostly just makes is much less likely to happen.

I think the problem here was simply that Mihaela tested Nightly before it actually had the fix. As stated in comment 54 there were scheduling issues for the inbound -> m-c merge. So the patch landed about 8h after Mihaela tested Nightly.
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.