Closed Bug 383369 Opened 13 years ago Closed 12 years ago

Secure (encrypted, https) sites loading as being partially encrypted. Broken lock is present as is the white address bar

Categories

(Core :: Security, defect, critical)

x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: jon, Assigned: KaiE)

References

(Blocks 1 open bug, )

Details

(Keywords: regression, Whiteboard: STR in comment 26)

Attachments

(4 files, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Seems that this is sporadic, and I've only managed to replicate it once in the past few days. I noticed this first when visiting a secure site (that started with https); the address bar remained white, and the lock was showing up 'broke' (with a line through it). I proceeded to visit a few more https sites during the same browser session and all were the same as the first.

On restarting Firefox and revisiting the sites again, the problem seems to have rectified itself and all sites are loading with the yellow address bar and a 'good lock'.

Reproducible: Sometimes

Steps to Reproduce:
1.
2.
3.
I'm on Mac 10.4.9 using FF 2.0.0.4.

FF 2.0.0.4 seems to have an intermittent issue in this area. I went to four different secure login pages and got the "broken" lock. NOTE: I also logged all the html headers and ALL WERE HTTPS.

I then quit FF and relaunched. Went back to the pages and got the yellow background with the "good" lock.

I'm seeing this, too.
I've been testing my own website, and trying to figure out why it shows up with white address bar and crossed out lock icon.
The logs on the webserver show nothing served by http today, it's all https. I even used wireshark to capture the traffic between the browser and the site, and there's no sign of any http packets.
"Page Info" says "Connection Partially Encrypted" (it would be really nice if it said *which parts* weren't encrypted there, BTW).
I get this even for pages where there is only the one page, no links, included media or anything (e.g. "robots.txt"). The "media" page of "Page Info" lists nothing at all.
Within the one firefox tab, nothing seems to make it change (e.g. reloading the same page, clearing the cache, reload other pages from the same site - also show as insecure, etc), but copy the address bar, open a new tab, paste the address and voila! a yellow address bar. So I'm finally convinced that it isn't my site but is firefox - there's no way the site should show as secure in one tab and the same site insecure in another after both have been reloaded.

Oh, IE says the pages are secure, too, for what that's worth.

I'm running firefox 2.0.0.4 on windows XP.
Just happened to me again on my Mac. Believe the importance of this should be raised since it creates the wrong impression.
Done. I was actually planning to up the importance on this as it happened again today, and also on a couple of occasions late last night.

Another XP box in the household also saw the same thing happen today, too. Though in this instance the page went from being HTTPS to just HTTP after the user had logged into X site.

Seeing that so far has effected both Win and Mac, I'm trying to see if the same happens running 2.0.0.4 on Linux - I'll obviously post when/if I do.
Severity: normal → critical
I've been having that 100% of the time since... since I don 't know when. I also have a debug build ready if that helps.

Using windows XP, trunk build.
Adding keyword 'regression' because I'm told it is. Requesting blocking to get it on the radar to get investigated. Apparently happens on the trunk too. And in the trunk's safemode.
Flags: blocking1.8.1.6?
Flags: blocking-firefox3?
Keywords: regression
Version: unspecified → 2.0 Branch
On trunk, this happens when browser.cache.disk_cache_ssl = true
I'm suffering from the same problem since upgrading to 2.0.0.4 running on XP SP2. It seems to randomly choose to display the first SSL secure site I visit as either partially or fully encrypted and then every site after that gets reported the same. I've checked all the HTML and the sites are definitely fully secure. 

Like Chris, no amount of cache clearing or refreshing will fix it, but should I copy the address into another tab or start another instance of the client, it will show the sites proper fully encrypted status.
Gary, type about:config in the URL bar, hit enter and filter for disk_cache_ssl. What is this value set to for you?
ah, I checked that before I even posted the original message and neglected to include it. It's set to FALSE.
From what I see we have two confirmed scenarios now:

1. 2.0.0.4 and disk_cache_ssl=false -> sometimes happens
2. Trunk and disk_cache_ssl=true -> always happens

All other combinations unconfirmed so far. I think the next logical step would be checking 2.0.0.4 with "true" setting.
I changed my disk_cache_ssl setting to true on 2.0.0.4 earlier and it's just given me my first incorrect partially encrypted. I was using paypal at the time and the page is totally secure. It isn't doing it every time though because opening the exact same adress in another tag gave me the full encryption gold padlock.
Steve, did you mean to CONFIRM this as well? We've got a no-block-on-UNCO policy ...
No, I did not intent to CONFIRM this. I did intend to try and get reliable reproduction steps, but I've not seen this buy myself. I just thought it was important enough to warrant more investigation. I'll remove the blocking flags and take note of the policy.
Flags: blocking1.8.1.6?
Flags: blocking-firefox3?
I have had this happen about once a week. I usually visit five secure sites per day and spend about six hours per day using FF. I spent three hours today after it happened trying to find a reproducible sequence with no luck.
I'm seeing it with 1.5.0.12 on OSX 10.4.10 against a new server I'm setting up (https://auth.rdrop.com/) which just has a very basic html page.

<auth.rdrop.com> [17] # cat /var/log/httpd/ssl_request_log
[26/Jun/2007:21:45:44 -0700] 69.59.200.15 TLSv1 DHE-RSA-AES256-SHA "GET / HTTP/1.1" 186
[26/Jun/2007:21:45:44 -0700] 69.59.200.15 TLSv1 DHE-RSA-AES256-SHA "GET /favicon.ico HTTP/1.1" 290
[26/Jun/2007:21:47:24 -0700] 69.59.200.15 TLSv1 DHE-RSA-AES256-SHA "GET / HTTP/1.1" 186
[26/Jun/2007:21:52:51 -0700] 69.59.200.15 TLSv1 DHE-RSA-AES256-SHA "GET / HTTP/1.1" 235
[26/Jun/2007:21:52:51 -0700] 69.59.200.15 TLSv1 DHE-RSA-AES256-SHA "GET /rdrop-web.ico HTTP/1.1" 318
<auth.rdrop.com> [18] # cat /var/log/httpd/ssl_access_log
69.59.200.15 - - [26/Jun/2007:21:45:44 -0700] "GET / HTTP/1.1" 200 186
69.59.200.15 - - [26/Jun/2007:21:45:44 -0700] "GET /favicon.ico HTTP/1.1" 404 290
69.59.200.15 - - [26/Jun/2007:21:47:24 -0700] "GET / HTTP/1.1" 200 186
69.59.200.15 - - [26/Jun/2007:21:52:51 -0700] "GET / HTTP/1.1" 200 235
69.59.200.15 - - [26/Jun/2007:21:52:51 -0700] "GET /rdrop-web.ico HTTP/1.1" 200 318
OK, this is weird.  I put up the page I'm actually trying to setup here, and it came up properly secured in a separate window, and then I go back to the default placeholder page, and it shows properly secured...in *that* window.  I go back over to the other window and navigate to the new page, a new test page, back to the top page, all broken locks.  One window works, the other doesn't.
This shows two simultaneous windows having loaded the same page at essentially the same time, one says it's secure, the other says some of it isn't.
As I said in comment #2, I've had the same page open in two tabs in the same window with one showing as secure and one as insecure - refresh both tabs and they both still show teh same state as they did before.
 
Just had this occur on 2.0.0.5 (Win XP).

Anyone else?
I can reproduce this; however, it involves going to and logging into my bank sites. Process to reproduce:

1 - Go to bank A, log in and do some business then log out.
2 - Go to bank B, log in and do some business then log out.
3 - Go to secure fund site C home page and click the log in icon. Result is a broken lock on log in page.
4 - Open a new tab and go to secure fund site C home page and click the log in icon. Result is a "good" lock on log in page.

If I vary the process in any way I don't get the broken lock.

FF 2.0.0.5 on OSX 10.4.10
This occurs about every other time I go to a secure site -- I don't see any pattern.  I have been seeing the bug since 2.0.0.5 early nightly versions.

Currently running FF 2.0.0.6pre ID:2007072904 on Windows XP Pro

Does anyone know if this is just a cosmetic issue or is security at risk!
I've filed bug 390168 on a trunk manifestation of this that isn't reproducible on branch.
Summary: Secure (encrypted, https) sites loading as being partially encrypted. Broken lock is present as is the white address bar → [Branch 2.0] Secure (encrypted, https) sites loading as being partially encrypted. Broken lock is present as is the white address bar
Been getting this more frequently on the latest version (2.0.0.6), more so than I did in 2.0.0.5.

Like before, I haven't noticed any patterns, thus not able to try and reproduce.
Could the problem be related to the type and amount of data received by Firefox?

We are able to consistently cause this bug to occur on one of our websites. We also know how to consistently prevent it (on our website).

To demonstrate the problem, do the following:
  - Go to www.shortkeys.com.
  - Click the download link on the left side of the screen.
  - Click on one of the download links.
  - Wait for the download to complete.
  - Click on the 'Buy Now' link on the left side of the screen.
  - Click on the 1. Shopping Cart header link.
  - Click one of the 'Add to Cart' options.
  - The shopping cart comes up but is not locked.

This happens every time on all of our websites. We have tested it on 5 separate computers in two separate locations.

To avoid the problem:

  - Close all instances of Firefox.
  - Launch Firefox.
  - Go to www.shortkeys.com.
  - Click on the 'Buy Now' link on the left side of the screen.
  - Click one of the 'Add to Cart' options.
  - Click on the 1. Shopping Cart header link.
  - The shopping cart comes up and is locked correctly.

This leads me to wonder if the problem is caused by the amount of data received by Firefox before going to the secure page.
Kevin, fantastic! I can reproduce the problem using your steps in:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.7pre) Gecko/20070812 BonEcho/2.0.0.7pre
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007081614 Minefield/3.0a8pre ID:2007081614
If no one's beaten me to it, tomorrow I will do further testing to hopefully confirm this is indeed the regression people are seeing, and also get a regression range nailed down.
OK, found regression ranges

For Trunk
=========

Works:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007022316 Minefield/3.0a3pre

Broken:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/2007022407 Minefield/3.0a3pre

Checkins to module PhoenixTinderbox between 2007-02-23 15:00 and 2007-02-24 08:00 : 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-23+15&maxdate=2007-02-24+08&cvsroot=%2Fcvsroot


For Branch
==========

Works:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/2007033005 BonEcho/2.0.0.4pre

Broken:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/2007033103 BonEcho/2.0.0.4pre

Checkins to module PhoenixTinderbox on branch MOZILLA_1_8_BRANCH between 2007-03-30 04:00 and 2007-03-31 04:00 : 

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-03-30+04&maxdate=2007-03-31+04&cvsroot=%2Fcvsroot

--> Due to bug 335801

Kevin, thanks again for steps to reproduce!
Blocks: 335801
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1.7?
Flags: blocking-firefox3?
Summary: [Branch 2.0] Secure (encrypted, https) sites loading as being partially encrypted. Broken lock is present as is the white address bar → Secure (encrypted, https) sites loading as being partially encrypted. Broken lock is present as is the white address bar
Version: 2.0 Branch → Trunk
Whiteboard: STR in comment 26
I apologize for the following 'off topic' post.

You're welcome (for the steps). I would like to thank our QA tester, Mr. Jason Lunt, who documented these steps. (Give credit where credit is due.)

I would especially like to thank all developers who contribute to this fine program.
Kaie, this is all you.
Assignee: nobody → kengert
Target Milestone: --- → Firefox 3 M8
(In reply to comment #23)
> Does anyone know if this is just a cosmetic issue or is security at risk!

Firefox is incorrectly complaining that a secure site may not be secure. You are not actually at risk at that point (though annoys the developer of the secure site to no end, of course), but it is a security risk if it trains you to ignore the "broken security" warning on a truly broken site.
Flags: blocking1.8.1.7? → blocking1.8.1.7+
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: Firefox 3 M8 → Firefox 3 M9
Just to add a sighting of this bug on Iceweasel 2.0.0.6 on Linux. Symptoms exactly as described: opening the allegedly partially-encrypted site in a new tab or window it works fine.

Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6) Gecko/20070723 Iceweasel/2.0.0.6 (Debian-2.0.0.6-1)

Kai: what is your progress on this bug?
I have not yet worked on this bug, I agree this should get attention soon, help is welcome.
A miracle would be nice, but failing that this isn't going to make 1.8.1.8 (not holding other more serious fixes waiting for this). This is understating the site's security rather than overstating it, users aren't any less safe.
Flags: blocking1.8.1.8+ → blocking1.8.1.9+
Comment 26 reports two paths, two sequences of clicks on links, 
starting at the same page, that seem to take you to the same
result page, one way showing a locked icon and the other way showing
a "broken" lock (and the warning about partially encrypted).

I am able to reproduce those results using SeaMonkey trunk dated 20070527.
I have removed some unnecessary steps from the sequences.
There is no need to download anything.
I have found that the difference in behavior depends on the presence, 
or absence, of a cookie for the site https://www.wintools.com/

Both sequences start from the page http://www.shortkeys.com/

Sequence A:
1. Make sure you do NOT have a cookie for www.wintools.com.
Click on either of the page's two "Buy Now" links.  
This takes you to http://www.shortkeys.com/order.htm

2. Click on the link labeled "1. Shopping Cart", which is a link to 
https://www.wintools.com/cgi-bin/cart.pl?referrer=shk&url=http://www.wintools.com/order/ordershk.htm
You will be directed to http://www.wintools.com/order/ordershk.htm

3. Click on the first "Add to Cart" button.  
This is a form post to https://www.wintools.com/cgi-bin/cart.pl
The page displays with a locked lock icon
Now you have a cookie set from  www.wintools.com

Sequence B:
1. With the cookie set, go back to http://www.shortkeys.com/order.htm

2. Click on the link labeled "1. Shopping Cart", which is a link to 
https://www.wintools.com/cgi-bin/cart.pl?referrer=shk&url=http://www.wintools.com/order/ordershk.htm
First you will see a warning about "an encrypted page with some unencrypted 
information".  Then you are redirected to this page:
http://www.wintools.com/order/ordershk.htm

3. Click on the first "Add to Cart" button.  
This is a form post to https://www.wintools.com/cgi-bin/cart.pl
which displays the warning about "some unencrypted information" and then
displays the page with a broken lock.
Using:  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7

Same problem as others with the exception that I show NO padlock at all.  Closing and reopening Firefox multiple times corrects problem.
The nightly build works just fine with the test page and here.
This seems to be data that was received, in fact it's probably just corrupted data that got corrupted during transmission.
We'd really like this for M9, but we'll take it in M10 if there's bigger PSM/NSS fish to fry...
Target Milestone: Firefox 3 M9 → Firefox 3 M10
Priority: -- → P2
I'm experiencing this issue in Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 with no extensions. AFAICT, all SSL site are affected. I navigate to https://www.thawte.com and click a link on the page. I get the broken lock. If I reload the page with Cmd-R, the page appears to be secured properly. For me, resetting browser.cache.disk_cache_ssl to the default value of false eliminates the problem.
I agree with Comment #40. The sequence in Comment #36 creates no error if browser.cache.disk_cache_ssl=false.

Is it appropriate to considered cached resources to be secure? On the one hand, they were retrieved securely at one time, and the lock icon merely indicates that the transmission was encrypted. As the cache hit does not involve any re-transmission, the lock icon would be accurate. On the other hand, it may be undesirable to cache such content, or to rely on the sanctity of the cache for what often would be sensitive transactions. In that respect, a lock icon may be misunderstood to provide assurances of integrity and confidentiality which it never was meant to indicate. Maybe an icon with an exclamation point or warning sign would be better in these circumstances.
(In reply to comment #40)
> I'm experiencing this issue in Mozilla/5.0 (Macintosh; U; Intel Mac OS X;
> en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 with no extensions. AFAICT,
> all SSL site are affected. I navigate to https://www.thawte.com and click a
> link on the page. I get the broken lock. If I reload the page with Cmd-R, the
> page appears to be secured properly. For me, resetting
> browser.cache.disk_cache_ssl to the default value of false eliminates the
> problem.
> 

I'm on OSX with FF 2.0.0.9 with browser.cache.disk_cache_ssl set to the default value of false. I still see the problem.

I'm on Windows XP with FF 2.0.0.9 and have never changed the browser.cache.disk_cache_ssl setting (it remains false). Presumably it was false when comment #26 was posted.

I followed steps outlined in comment #26 and the page still comes unlocked.
(In reply to comment #43)
I also get the problem using the sequence in comment #26 (versus #36 as in my previous comment). Considering that the download is from a completely different host, it's rather inexplicable.

For what it's worth, if, after you download, you Ctrl+click or Shift+click the Buy Now link to launch the page in a new tab or new window, it works correctly from that point forward.
I am always getting that broken lock after restarting FF and pointing it first time to any xml file served as application/xml or text/xml. If that same file is served as text/plain, the lock is not broken. After refresh the lock is not broken. WinXP, FF both 2.0.0.10 and nightly 3.0.b2pre
I wonder if the patch from bug 262116 will influence this bug.
(In reply to comment #46)
> I wonder if the patch from bug 262116 will influence this bug.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007113013 Minefield/3.0b2pre ID:2007113013

It hasn't made a difference for me; STR's in comment 26 still lead to a partially encrypted state.
Steve, if you tested a downloaded nightly build, you tested too early.
The patch was checked in 2007-11-30, so nightly builds from 2007-12-01 will be the first ones that have it.
Kai I was on an hourly. Christian Biesinger checked bug 262116 in at 10:02:00 and the build I tested with was 3 hours past that time.
Flags: wanted1.8.1.x+
Blocks: lockicon
Hasn't landed on trunk yet so not making 1.8.1.12 -- hopefully a trunk P2 blocker will get fixed by the next branch release.
Flags: blocking1.8.1.12+ → blocking1.8.1.13+
Retargeting for Firefox 3 beta 4 so this bug doesn't get lost.
Target Milestone: Firefox 3 beta2 → Firefox 3 beta4
Assignee: kengert → dveditz
Flags: blocking-firefox3+
Product: Firefox → Core
QA Contact: firefox → toolkit
Target Milestone: Firefox 3 beta4 → mozilla1.9beta4
Assignee: dveditz → kengert
Flags: blocking1.9+
Moving bugs that aren't beta 4 blockers to target final release.
Target Milestone: mozilla1.9beta4 → mozilla1.9
Flags: wanted1.9.0.x?
Flags: wanted-next+
Flags: tracking1.9+
Flags: blocking1.9-
Priority: P2 → --
As much as we want it for a branch release, the removal of trunk-blocking means we have no expectation this will get fixed anytime soon. Will schedule this after the trunk fix.
Flags: blocking1.8.1.13+ → blocking1.8.1.13-
Using version 2.0.0.13 of Firefox... this happened to me this morning on a https site. The yellow bar disappeared and the padlock had a red line through it (both were fine moments beforehand... not sure how I got it to disappear, maybe by hitting the browser's back-button). Opening a new tab of the same page at the same time did not show the yellow bar or secure padlock either. The yellow bar and secure padlock reappeared only after closing both tabs, then creating a new tab and pasting the address.

Should on-line shoppers be concerned if the yellow bar disappears and the padlock has a red line through it when on a https site?
Steps from comment 26 allow me to reproduce the bug.

(Nelson's steps from comment 36 do NOT work for me.)

Yes, I agree this has been a regression from bug 335801, if I back it out, I don't see this one.

The issue is related to downloading.
I suspect we somehow remember that an insecure load has happend and it causes us to not switch to secure.
It's something on the insecure order page that causes us to fail.
Here is my most recent minimal testcase:

click http://kuix.de/misc/test383369/blob.php, press cancel
go to http://www.shortkeys.com/order.htm
go to https://kuix.de/misc/test383369/p2.php

expected: last page shown as secure
actual: last page shown as broken / mixed content

I will now analyze what happens when loading the order page.
I have a minimal test case.
I'm not yet sure if there are more scenarios that can trigger this bug, but it seems to be related to loading a text/css.
It does not matter whether the css file exists, in my example I use one that does not exist.

Go here and follow the instructions.
http://kuix.de/misc/test383369/
I understand what's going on.

The following events in a window are sufficient to cause the bug:
- you have downloaded something
- you have loaded any insecure page that contains at least one 
  trackable sub element (like a stylesheet or a script)
- you go to any secure page


Here's why:

As PSM receives many events that must be combined into an overall security state, it has many variables to keep track of the events seen. Part of the state is, whether insecure page elements have been seen (in order to detect mixed content).

One of the variables is mDocumentRequestsInProgress. We increment it whenever a load starts in the toplevel windows, and we decrement it when that load is done.

When starting to load a new page, it's required that we must clear our state.
We detect that even when we see a START/REQUEST/DOCUMENT_URI event for the toplevel window, but at the same time we require that mDocumentRequestsInProgress is zero.

And here is the problem that got introduced with bug 335801.

When we see the start event for a download, we do not yet have the LOAD_RETARGETED_DOCUMENT_URI flag, therefore we increment mDocumentRequestsInProgress.

However, when the stop even comes in, that flag is set. And the naive patch from bug 355801 causes us to ignore that event at all.

As a result:
- mDocumentRequestsInProgress does not get decremented
- we never again clear the state for this window
- all future state tracking still uses the old information
  about sub elements seen.

So, when you nagivate to a secure page, we detect that the toplevel document is now secure.
However, our state still has the knowledge "we have seen some insecure page element".
That's why we go to mixed content with a broken lock icon.
What's the fix?

The patch from bug 335801 causes us to ignore any web progress events that have the RETARGETED flag set.

As said before, this is wrong, because it causes our tracking of start/stop events and our counters to go out of synch.

While we must not update the state that we show in the UI, we must continue to process such events and update our counters of seen events.
This patch illustrates that the fix disables executing some code when we are processing an event for a retargeted load, but will still update the import variable --mDocumentRequestsInProgress.

This patch ignores whitespace changes.

(The real patch is ugly, because it changes a lot of indenting.)
Attached patch Patch v1 (obsolete) — Splinter Review
Attachment #315027 - Flags: review?(rrelyea)
Comment on attachment 315027 [details] [diff] [review]
Patch v1, not showing whitespace changes

The SinkEvent should also be 'ignored' on the allowSecurityStateChange.
Attachment #315027 - Flags: review?(rrelyea) → review-
Wrapping more activity into
  if (allowSecurityStateChange) {}
Attachment #315027 - Attachment is obsolete: true
Attachment #315208 - Attachment description: Patch v2 → Patch v2, not showing whitespace changes.
Attached patch Patch v2 (obsolete) — Splinter Review
Attachment #315208 - Flags: review?(rrelyea)
Comment on attachment 315208 [details] [diff] [review]
Patch v2, not showing whitespace changes.

r+
Attachment #315208 - Flags: review?(rrelyea) → review+
Attachment #315208 - Attachment is obsolete: true
Comment on attachment 315212 [details] [diff] [review]
Patch v3, not showing whitespace changes

carrying forward Bob's r+ from p2, the only change is really that I removed the double-check of allowSecurityStateChange
Attachment #315212 - Flags: review+
Attached patch Patch v3Splinter Review
Attachment #315028 - Attachment is obsolete: true
Attachment #315209 - Attachment is obsolete: true
I've checked in a merged version of the latest patch together with the fix for bug 420187.

Marking fixed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Are you sure this is checked in? I just did an autoupdate and it automatically restarted Firefox. I had Gmail open and Gmail still warned me that it was partially encrypted after I restarted.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041506 Minefield/3.0pre
(In reply to comment #70)
> Are you sure this is checked in? I just did an autoupdate and it automatically
> restarted Firefox. I had Gmail open and Gmail still warned me that it was
> partially encrypted after I restarted.

That's bug 424689?

Using the STR from comment 26

20080411_2015_firefox-3.0pre.en-US.win32 (pre-patch) shows the problem of the partially encrypted page.

20080411_2200_firefox-3.0pre.en-US.win32 (post-patch) shows no such problem

--> VERIFIED
Status: RESOLVED → VERIFIED
Flags: wanted1.9.0.x?
You need to log in before you can comment on or make changes to this bug.