Last Comment Bug 477118 - https webpage with data: images trigger a "Page contains unencrypted information" mixed content warning
: https webpage with data: images trigger a "Page contains unencrypted informat...
Status: RESOLVED FIXED
[sg:want] regression from FF3.0
: regression, verified1.9.1
Product: Core
Classification: Components
Component: Security: PSM (show other bugs)
: Trunk
: All All
: -- normal with 13 votes (vote)
: ---
Assigned To: Honza Bambas (:mayhemer)
:
Mentors:
: 482245 486994 489093 501458 502008 518280 520464 (view as bug list)
Depends on:
Blocks: 135007
  Show dependency treegraph
 
Reported: 2009-02-05 13:56 PST by theglu
Modified: 2010-12-17 07:06 PST (History)
34 users (show)
benjamin: blocking1.9.2-
benjamin: wanted1.9.2+
mbeltzner: blocking1.9.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
beta1-fixed
.4+
.4-fixed


Attachments
testcase of base64 encoded image (973 bytes, text/html)
2009-02-05 14:14 PST, Mardeg
no flags Details
hohoh v1 (3.55 KB, patch)
2009-03-06 11:30 PST, Honza Bambas (:mayhemer)
bzbarsky: review-
Details | Diff | Splinter Review
v2 (1.33 KB, patch)
2009-03-06 14:24 PST, Honza Bambas (:mayhemer)
no flags Details | Diff | Splinter Review
v3 (1.33 KB, patch)
2009-03-11 15:44 PDT, Honza Bambas (:mayhemer)
no flags Details | Diff | Splinter Review
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64] (4.25 KB, patch)
2009-08-17 07:39 PDT, Honza Bambas (:mayhemer)
bzbarsky: review+
benjamin: approval1.9.2+
dveditz: approval1.9.1.4+
Details | Diff | Splinter Review

Description theglu 2009-02-05 13:56:05 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008123017 GranParadiso/3.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090125 Shiretoko/3.1b3pre

Https webpage with base64 encoded images trigger a "Page contains unencrypted information" with Firefox 3.1. This dosen't happend in Firefox 3.0.

Reproducible: Always

Steps to Reproduce:
Insert this into a https webpage :

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAAN1wAADdcBQiibeAAAAAd0SU1FB9kBDxIAOdxBIbcAAAI+SURBVDjLxZO7TxRhFMV/M/PN7EPYhS02yytggo+ERAgxERsNhYnGzsQojaHT3r9F0cTaUjs6NUQLBRKDi4I8FEwkLMgO+5rdeX3XAoVYiZWnP797cu69Bv8gqZ+0QTqIdRpl1VHGvnV884CJwQgwicVtoB/ku/H4ycOnURgP/Q1g21Fw4+r0RjbbNmaq4ayO35UkXp9S2UzHxK2bE4QNl82FVwD0D49jn+hERBCRgwTiIX7pvGUGYF/BlO327d3ENfV7wuL0AyjPICIsfPvAmev3qdVqlMtlCoUCGxurDPT1kEnPomQKkRTFpXOjh4DN4kvGLuSJ/JC38y/ouXyXYrGIiBDHMVtbu1SrvXTlbfp6HcQcoVwp5hRAaWedPXFYfL+E1lAKswSRy+joKEEQICLkcjm01hiGgRcksW0b4SMKYHb+OSt6ma+VffxWRF3S5OeeMX7pHkqpwy5EBK31H90ogFODF1lbm8OtlEhloDORpbdnhDAMaTabhwbbtkkkEkRRhGVZR4BCfojJO4+o1VwQAItEIolpmliWRVtbG7s/dlDKotGo47U8CvkuAEwA3/eJoxhE0WyGuO4+nucRBAHVahXDMKg3agRhQBAGVKsVtNZHCRzHwTAMcrnc0eX9it3e3g7A6cGzhx0AKHWwQOV5jdXXb2ZOaa3BOP5ffF5ZptVqflG+3xpbWv5kh2FolEo7dnmv7Lium6zXG0nf95MiguM4QTqd9jPZTCvX2eF393QHqVRKZ7KZkP+unzPGLX8Jr7F8AAAAAElFTkSuQmCC" />

Actual Results:  
trigger a "Page contains unencrypted information" warning.

Expected Results:  
Does not complain as the information is secure..

Works in Fx3.0
Comment 1 Mardeg 2009-02-05 14:14:29 PST
Created attachment 360802 [details]
testcase of base64 encoded image
Comment 2 Eddy Nigg (StartCom) 2009-02-05 14:20:32 PST
It works with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090201 Shiretoko/3.1b3pre
Comment 3 Eddy Nigg (StartCom) 2009-02-05 14:23:18 PST
Sorry, please disregard the comment above. The page has insecure content.
Comment 4 theglu 2009-02-05 14:26:09 PST
Don't forget to set option in preferences to show this kind of warning btw ;)
Comment 5 Matthias Versen [:Matti] 2009-02-05 15:27:21 PST
could be related to bug 455367
Comment 6 Mike Beltzner [:beltzner, not reading bugmail] 2009-02-10 12:11:28 PST
Not a blocker; would take a patch.
Comment 7 Kai Engert (:kaie) 2009-02-19 09:48:07 PST
cc'ing Honza who worked on insecure image detection
Comment 8 Honza Bambas (:mayhemer) 2009-03-02 11:04:46 PST
-> me
going to take a look at this
Comment 9 Honza Bambas (:mayhemer) 2009-03-02 15:50:35 PST
We cannot detect from securityUI that image proxy request is using data channel to load the image - the underlying request is inaccessible - and image proxy itself cares no security info. I had an idea to let the data channel take security info from document channel of it's doc shell accessed through notification callbacks, but it is no-no because we cannot use nsIDocShell from netwerk code. We could add a new data-channel-specific code to NewImageChannel in imgLoader.cpp to add a security info there but neither libimg has access to doc shell.

So, we can add some new interface to say securityUI to ignore the content in this specific case.

However, it seems to me that we have to do some more work to fix this issue.
Comment 10 Honza Bambas (:mayhemer) 2009-03-06 11:24:26 PST
Any changes landed here should be covered by mixed content tests from bug 452401.
Comment 11 Honza Bambas (:mayhemer) 2009-03-06 11:30:31 PST
Created attachment 365950 [details] [diff] [review]
hohoh v1

This is a bit hacky workaround. When URI scheme is data: say we didn't transfer any data from network (what is actually true). That makes the security UI ignore this image request. This is based on bz's fix for one of mixed content image bugs.
Comment 12 Boris Zbarsky [:bz] 2009-03-06 12:23:23 PST
Wait.  Why is this the right change?  What about an image from a javascript: URI?  Isn't checking for the URI_INHERITS_SECURITY_CONTEXT flag what you really want?  And even given that, wouldn't you care about _where_ it's inheriting from?
Comment 13 quantumpacket 2009-03-06 14:01:14 PST
This issue is also occurring with resource: and chrome: image file requests. It is causing partially encrypted errors to occur with NoScript, LinkAlert, and RequestPolicy extensions by causing their icons which are resource: and chrome:
Comment 14 Boris Zbarsky [:bz] 2009-03-06 14:09:08 PST
Alternately, should we be checking for LOCAL_RESOURCE, if that's really the criterion we care about?
Comment 15 Honza Bambas (:mayhemer) 2009-03-06 14:09:55 PST
CrYpTiC MauleR: This has been fixed on trunk and 1.9.1 in bug 450912, please turn your comment there, this is a different bug.
Comment 16 Honza Bambas (:mayhemer) 2009-03-06 14:24:28 PST
Created attachment 366002 [details] [diff] [review]
v2

(In reply to comment #12)
> Wait.  Why is this the right change?  What about an image from a javascript:
> URI?  Isn't checking for the URI_INHERITS_SECURITY_CONTEXT flag what you really
> want?  And even given that, wouldn't you care about _where_ it's inheriting
> from?

javascript is ignored by security UI.

something like this?
Comment 17 Boris Zbarsky [:bz] 2009-03-06 14:26:04 PST
> javascript is ignored by security UI.

Yes, I'm just saying the mechanism for ignoring these should be the the same, and use properties of the protocol, not be hack upon hack of scheme special-casing.
Comment 18 Boris Zbarsky [:bz] 2009-03-06 14:27:21 PST
I like "wip" more.

Is there a reason we let file:// URIs affect security UI but don't let resource:// URIs do it?
Comment 19 Boris Zbarsky [:bz] 2009-03-06 14:27:59 PST
Comment on attachment 365950 [details] [diff] [review]
hohoh v1

This is certainly not what we want, imo.
Comment 20 Honza Bambas (:mayhemer) 2009-03-06 16:07:08 PST
(In reply to comment #18)
> Is there a reason we let file:// URIs affect security UI but don't let
> resource:// URIs do it?

Files are also ignored, but not by checking a flag or a uri scheme but by QI of the request to nsIFileChannel.
Comment 21 Honza Bambas (:mayhemer) 2009-03-06 16:15:18 PST
Comment on attachment 366002 [details] [diff] [review]
v2

This fixes the problem and doesn't break regression tests we have so far. As defined, URI_INHERITS_SECURITY_CONTEXT says that requests with this kind of uri has the same security level as the document, so we may presume there is no need to consider such requests as potentially breaking security ui state. Bz, good idea.

Asking also Kai for review to let him check this.
Comment 22 Honza Bambas (:mayhemer) 2009-03-06 16:16:00 PST
Comment on attachment 365950 [details] [diff] [review]
hohoh v1

bz found a better approach in a different code.
Comment 23 Boris Zbarsky [:bz] 2009-03-06 18:28:12 PST
How about we just check for the LOCAL_RESOURCE flag then?  That would cover resource, chrome, data, file, moz-icon, and anno protocols, and any extension protocol that's correctly written.  So you won't have to keep adding special-cases and _still_ break the moment an extension is in use...
Comment 24 Honza Bambas (:mayhemer) 2009-03-11 15:44:36 PDT
Created attachment 366929 [details] [diff] [review]
v3

(In reply to comment #23)
> How about we just check for the LOCAL_RESOURCE flag then?  That would cover
> resource, chrome, data, file, moz-icon, and anno protocols, and any extension
> protocol that's correctly written.  So you won't have to keep adding
> special-cases and _still_ break the moment an extension is in use...

It works for me. I don't include the URI_INHERITS_SECURITY_CONTEXT check because it's related only to wyciwyg requests that are handled specifically by the security UI code.
Comment 25 Honza Bambas (:mayhemer) 2009-03-11 15:48:53 PDT
And, I will add a test for this bug after bug 480713 gets fixed and mixed content tests are re-enabled.
Comment 26 Boris Zbarsky [:bz] 2009-03-11 18:36:18 PDT
URI_INHERITS_SECURITY_CONTEXT has nothing to do with wyciwyg.  wyciwyg is document.write().  URI_INHERITS_SECURITY_CONTEXT is javascript: and data:.

As long as we sanely handle javascript: through some other method, patch looks good go me.
Comment 27 Honza Bambas (:mayhemer) 2009-03-11 18:38:12 PDT
Javascript is also handled separately, so it should be ok.
Comment 28 Boris Zbarsky [:bz] 2009-03-11 18:47:38 PDT
So wait.  With this patch, can we remove all that QI special-casing of channels we have?  As a followup bug or something?
Comment 29 Honza Bambas (:mayhemer) 2009-03-11 18:52:44 PDT
We could consider it, but what I wanted to say is that the isSubDocumentRelevant flag we set false for local resources is not relevant for wysiwyg because it is handled separately. So is javascript.

(In reply to comment #26)
> URI_INHERITS_SECURITY_CONTEXT has nothing to do with wyciwyg.

http://mxr.mozilla.org/mozilla-central/source/content/html/document/src/nsWyciwygProtocolHandler.cpp#128
Comment 30 Boris Zbarsky [:bz] 2009-03-11 19:00:02 PDT
Oh, huh.  I'd forgotten this part.  Those URIs never really inherit a security context, so...
Comment 31 :Gavin Sharp [email: gavin@gavinsharp.com] 2009-04-20 07:57:49 PDT
*** Bug 489093 has been marked as a duplicate of this bug. ***
Comment 32 Mike Beltzner [:beltzner, not reading bugmail] 2009-06-15 16:42:14 PDT
*** Bug 486994 has been marked as a duplicate of this bug. ***
Comment 33 pillii@gmx.de 2009-06-16 09:14:13 PDT
Hello, i have a similar problem, and i think that maybe its related to this bug. Heres my bugreport: https://bugzilla.mozilla.org/show_bug.cgi?id=498376
Comment 34 Denny Crane 2009-06-24 17:37:39 PDT
Bug still exists in 3.5RC2. The following in a linked CSS file triggers the bug:
background-image: url(data:image/gif;base64,AAAA);
Comment 35 Kevin Brosnan 2009-06-30 13:44:18 PDT
*** Bug 501458 has been marked as a duplicate of this bug. ***
Comment 36 Kevin Brosnan 2009-06-30 13:58:56 PDT
*** Bug 501438 has been marked as a duplicate of this bug. ***
Comment 37 Kevin Brosnan 2009-06-30 14:01:49 PDT
*** Bug 475450 has been marked as a duplicate of this bug. ***
Comment 38 Ted Mielczarek [:ted.mielczarek] 2009-07-08 10:50:26 PDT
*** Bug 502008 has been marked as a duplicate of this bug. ***
Comment 39 Benjamin Smedberg [:bsmedberg] 2009-07-08 10:58:28 PDT
*** Bug 502008 has been marked as a duplicate of this bug. ***
Comment 40 jonbugzilla 2009-07-12 10:07:02 PDT
Is there an eta on getting this fixed?  I'd be happy to be of any assistance.
Comment 41 Honza Bambas (:mayhemer) 2009-07-13 08:58:42 PDT
(In reply to comment #40)
> Is there an eta on getting this fixed?  I'd be happy to be of any assistance.

Depends on Kai's or someones review. I'll try to find someone else to do it.
Comment 42 Honza Bambas (:mayhemer) 2009-07-20 07:45:07 PDT
Comment on attachment 366929 [details] [diff] [review]
v3

Robert, could you please take a look? However, it's not that simple to review...
Comment 43 Robert Relyea 2009-07-23 10:15:28 PDT
Comment on attachment 366929 [details] [diff] [review]
v3

The change looks reasonable, but I am unfamiliare with the URI handle to know if the constant change is the correct one, you probably need a different reviewer.

bob
Comment 44 Xan Charbonnet 2009-08-07 15:04:26 PDT
Any chance of this being fixed in a 3.5.x release?  Right now I'm having to tell my customers to wait to upgrade to 3.5 because of this.  I really don't want to have to tell them they'll never be able to.
Comment 45 sjs 2009-08-14 23:07:02 PDT
I'll +1 this one.  This is causing the bogus security warning for my add-on, as well as many others:

http://www.google.com/search?q=%22contains+unauthenticated+content%22+firefox+add-on

Very unsettling for end users.
Comment 46 Xan Charbonnet 2009-08-14 23:11:43 PDT
This is a serious security flaw, because it destroys the value of that important error message, as everyone gets trained to ignore it.

I realize users are trained to click OK to just about anything already, but that should be getting better, not made worse, especially not by a case of "crying wolf" in a security matter.
Comment 47 Allen Castaban 2009-08-15 04:24:43 PDT
I completely agree. I am holding off updating to 3.5 because of this. It should be a priority
Comment 48 Johnathan Nightingale [:johnath] 2009-08-17 06:51:52 PDT
(In reply to comment #46)
> This is a serious security flaw, because it destroys the value of that
> important error message, as everyone gets trained to ignore it.
> 
> I realize users are trained to click OK to just about anything already, but
> that should be getting better, not made worse, especially not by a case of
> "crying wolf" in a security matter.

This bug doesn't need "me too" advocacy. No one disputes that it should be fixed.  What this bug actually needs...

(In reply to comment #25)
> And, I will add a test for this bug after bug 480713 gets fixed and mixed
> content tests are re-enabled.

is an updated patch with tests for review. Honza - I would personally expect that for this change, someone like bz might be a good alternate reviewer?
Comment 49 Honza Bambas (:mayhemer) 2009-08-17 07:16:16 PDT
(In reply to comment #48)
> Honza - I would personally expect
> that for this change, someone like bz might be a good alternate reviewer?

Yes, I will create a test for this and add a new patch, then I'll ask bz for review.
Comment 50 Honza Bambas (:mayhemer) 2009-08-17 07:39:37 PDT
Created attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]
Comment 51 Boris Zbarsky [:bz] 2009-08-24 10:09:12 PDT
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

I suppose we can live with this....
Comment 52 sjs 2009-08-24 13:13:35 PDT
I apologize for the noob comment, but does the approval1.9.2? flag mean this is being proposed for 1.9.2?  Is there any reason not to propose that it be added to 1.9.1.x given that it seems to be a substantial security concern?
Comment 53 Honza Bambas (:mayhemer) 2009-08-25 12:31:47 PDT
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

http://hg.mozilla.org/mozilla-central/rev/bec02958a3e1
Comment 54 Allen Castaban 2009-09-10 06:27:21 PDT
If "This bug doesn't need "me too" advocacy. No one disputes that it should be
fixed.", why is not being fixed yet? It was reported in Feb, now it is September, this is over 6 months and several hotfixes old... This is getting quite frustrating...
Comment 55 Boris Zbarsky [:bz] 2009-09-10 06:38:00 PDT
It's being fixed.  The fix is in the development builds. It's being tested.  Once it's been satisfactorily tested, it will be approved for the upcoming Firefox 3.6 release.

At the moment, no one has requested approval to land this on 1.9.1 (Firefox 3.5.x).  Need driver triage here to see whether it's even wanted there.

If your question is why it took so long to fix, it's because it's not particularly simple to fix and people have other priorities too.
Comment 56 Johnathan Nightingale [:johnath] 2009-09-10 06:43:43 PDT
(In reply to comment #54)
> If "This bug doesn't need "me too" advocacy. No one disputes that it should be
> fixed.", why is not being fixed yet? It was reported in Feb, now it is
> September, this is over 6 months and several hotfixes old... This is getting
> quite frustrating...

It also doesn't need entitlement. Firefox is built largely by volunteers and
even those paid to work on it charge nothing for the product or its support. If
you want any bug in Firefox fixed, please feel free to attach a patch. If
coding isn't your thing, I submit to you that other forms of help (regression
range finding, test reducing, running development nightly builds) are
substantially superior to folding your arms and insisting that, damnit, your
bug is most important and you'll not tolerate these volunteers working on other
bugs first.

As it happens, Honza has fixed this bug on our mozilla-central development
branch and is now awaiting approval to land it on the release branch as well.
I'm sure he will comment here once he has done so.

Any time you want to help fix a bug instead of complaining about the
insufficiency of the speed with which other people leap to your assistance, we
have an ample backlog. This is an open source project devoted to making the
internet a better place. We're not sitting on our hands, cackling about the
torment we cause our users, nor do we have our fingers up our nose waiting for
helpful souls to guide us as to which bug we should fix next. I'm sorry if I
seem harsh, but my hope is to turn your evident energy for the project in more
positive directions, because right now you're sort of seeming like an entitled
dickhead, and I'm pretty sure that's not your intent.
Comment 57 Allen Castaban 2009-09-10 07:42:17 PDT
Look, I understand this is an open source project and done by volunteers and I am highly grateful on that.
I am highly security conscious person and this effects FF security. How do I know whether the page has insecure content or not if I get warning for every SSL page I visit? (And yes certain people will get that for every SSL page they visit, irregardless of mixed content or not). One of my primary reasons I use FF is I find it is a lot securer. And that is one of the primary reasons I recommend to my friends. This problem does no bode well with that and it reduces FF usage. I don't understand why this is not scheduled for 3.5.x?  After all it is a security flaw. When will 3.6 come out?

And  Johnathan, this is not MY bug, it was reported by somebody else and it is effecting plenty other people. If you do not understand my frustration on a security issue reported 7 months ago and not fixed, you have a problem. I am involved with Firefox AS MUCH AS I CAN. My opening bug reports proves that. It definitely does not help you calling people ****
Comment 58 sjs 2009-09-10 07:59:38 PDT
I'd hate to see this turn into a flame war, especially because I think it would distract from getting this important bug fixed.

Johnath, I tried to ask whether this can make it into 1.9.1 here:
https://bugzilla.mozilla.org/show_bug.cgi?id=477118#c52

But frankly I don't understand the bugzilla process well enough to know how to do this formally.  I'm also happy to help with testing etc, but I'm such a noob to the process I don't know where to start.
Comment 59 Daniel Veditz [:dveditz] 2009-09-10 11:37:37 PDT
Landed on trunk so status is "fixed". Still need approval to land on 1.9.2 (triagers there were probably looking for trunk-fixed bugs and skipping this one).
Comment 60 Honza Bambas (:mayhemer) 2009-09-21 12:38:21 PDT
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

This patch clearly applies to 1.9.1 as well.
Comment 61 Daniel Veditz [:dveditz] 2009-09-21 14:53:34 PDT
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

This means a file: uri will also not cause mixed-mode, but on windows a file: uri can be a UNC path that goes out over the network.
Comment 62 Daniel Veditz [:dveditz] 2009-09-21 14:55:11 PDT
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

Approved for 1.9.1.4, a=dveditz for release-drivers
Comment 63 Honza Bambas (:mayhemer) 2009-09-22 11:24:18 PDT
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9d30d729f7f6
Comment 64 Honza Bambas (:mayhemer) 2009-09-22 12:44:45 PDT
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fa380bc4f892
Comment 65 Boris Zbarsky [:bz] 2009-09-22 21:51:16 PDT
*** Bug 518280 has been marked as a duplicate of this bug. ***
Comment 66 Al Billings [:abillings] 2009-10-01 11:31:43 PDT
Verified fixed for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090930 Shiretoko/3.5.4pre using attached testcase.
Comment 67 Johnathan Nightingale [:johnath] 2009-10-05 06:05:04 PDT
*** Bug 520464 has been marked as a duplicate of this bug. ***
Comment 68 Allen Castaban 2009-11-02 06:55:34 PST
I just installed 3.5.4 and I am very happy to report that this bug is now fixed. Thanks to everyone who helped
Comment 69 dev002 2009-11-10 12:06:08 PST
Do not fixed yet.
Try load data image encoded from external css file under ssl.
Comment 70 jonbugzilla 2009-12-08 16:32:13 PST
Can someone confirm that 3.5.4 was the first version that has this fix?  And does anyone know in what version this bug first appeared?
Comment 71 Boris Zbarsky [:bz] 2009-12-08 16:49:45 PST
> Can someone confirm that 3.5.4 was the first version that has this fix? 

Yes.

> And does anyone know in what version this bug first appeared?

3.5.0.
Comment 72 Boris Zbarsky [:bz] 2009-12-08 16:50:19 PST
Unless you were asking for the specific 3.5 alpha/beta/nightly/whatever that first had the behavior?
Comment 73 jonbugzilla 2009-12-08 17:03:08 PST
Hi Boris,

    Thanks for the quick reply.  The original poster on this thread reported this problem in ff3.1.  Are you sure it didn't appear until 3.5.0?

-jon
Comment 74 Boris Zbarsky [:bz] 2009-12-08 17:16:55 PST
The release after 3.0 was 3.5.0.  "3.1" was its internal version number in the early stages, before 3.0 even shipped.
Comment 75 jonbugzilla 2009-12-08 17:26:49 PST
Hi Boris,

    That clears things up.  So in which alpha/beta/nightly version did it first appear?

Thanks,

-jon
Comment 76 Boris Zbarsky [:bz] 2009-12-08 17:31:25 PST
When bug 135007 landed, which puts you at Gecko 1.9.1a2 (aka Firefox "3.1a2") or the 2008-09-02 nightly.

Not sure why that matters, though...
Comment 77 Honza Bambas (:mayhemer) 2010-02-06 06:24:12 PST
*** Bug 482245 has been marked as a duplicate of this bug. ***
Comment 78 Onno 2010-03-04 03:13:27 PST
I still have this bug. For example this site on Mozilla Developer: https://developer.mozilla.org/devnews/index.php/2010/03/03/mozilla-developer-preview-now-available-with-out-of-process-plugins/

But of course this is not the only one.
Comment 79 Allen Castaban 2010-03-04 03:39:43 PST
Because that site contain a mixture of secure and unsecured content. You are supposed to have the warning...
Comment 80 Onno 2010-03-04 04:12:08 PST
I have also other sites who should be allright but does now and then give that warning and sometimes does not. Even here on bugzilla.
Comment 81 Black_Ps` 2010-03-04 05:24:24 PST
Sometimes here i have the same problem and on Yahoo login page and when i Refresh it's secured again,it's not happening all the time for me,but i can confirm this old bug.
Comment 82 Boris Zbarsky [:bz] 2010-03-04 07:22:57 PST
If what you're seeing is intermittent, it is NOT this bug (which happened 100% reliably).  Please file a new bug with steps to reproduce (e.g. the exact pages you see it happening on) and cc me on it.
Comment 83 Onno 2010-03-04 08:51:17 PST
I'll file a new bug today.
Comment 84 Onno 2010-03-05 14:10:24 PST
I filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=550580

Note You need to log in before you can comment on or make changes to this bug.