Mixed content notification should be non-dismissible

VERIFIED FIXED in Firefox 34

Status

()

Firefox
General
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Unfocused, Assigned: Georgios Kontaxis)

Tracking

(Depends on: 1 bug)

30 Branch
Firefox 34
Points:
3
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +
qe-verify +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 17 obsolete attachments)

2.75 KB, application/zip
Details
111.55 KB, image/png
Details
52.63 KB, patch
mmc
: review+
Details | Diff | Splinter Review
The mixed content shield notification icon in the URL bar should not go away when mixed content blocking is disabled for that page. This will make it easy to re-enable that protection (and other types of protection) after it has been disabled.

When any such protection is disabled, the icon should be replaced with a shield with a strike through it (with all other behaviour the same).

Mockup: attachment 8459851 [details]
Flags: firefox-backlog+
Note: There should be no change in how the grey/yellow triangle for the site identity currently works.
Blocks: 1043805
Blocks: 1043780
(Assignee)

Comment 2

3 years ago
I think this bug applies to the existing popup notifications module. Extending the module to meet our need of bundling mixed content with other types of security notifications avoids the primary/secondary action interface completely. Therefore the notification icon appears to stay in place.
(Assignee)

Comment 3

3 years ago
While the above is true we were not acting upon the new security state when the page was reloaded protection-free. I guess because we currently do not have a different shield icon to show. The patch I've uploaded fixes that but shows the same icon. We need a new icon.
(Assignee)

Comment 4

3 years ago
Created attachment 8464189 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Assignee: nobody → gkontaxis
Status: NEW → ASSIGNED
(Assignee)

Comment 5

3 years ago
Created attachment 8465544 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8464189 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Depends on: 1043797
(Assignee)

Comment 6

3 years ago
FYI we are unable to provide a re-enable mixed content protection button because of bug 1045809
(Assignee)

Comment 7

3 years ago
Created attachment 8465546 [details]
Screen Shot 2014-07-31 at 9.21.13 AM.png
(Assignee)

Comment 8

3 years ago
Created attachment 8465862 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8465544 - Attachment is obsolete: true
(Assignee)

Comment 9

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=88cb4799fc86
(Assignee)

Comment 10

3 years ago
Mochitests must now not only test the presence of the doorhanger but also its state through the function _IsMixedContentBlocked() exposed by the notification
(Assignee)

Comment 11

3 years ago
Created attachment 8466367 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8465862 - Attachment is obsolete: true
(Assignee)

Comment 12

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=169a00b2b63f
(Assignee)

Comment 13

3 years ago
Created attachment 8467461 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8466367 - Attachment is obsolete: true
(Assignee)

Comment 14

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=ee9af987d7cb
(Assignee)

Comment 15

3 years ago
Comment on attachment 8467461 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

Now the doorhanger shows up when mixed content is being loaded (white-listed) in addition to when content is being blocked (current behavior).
Attachment #8467461 - Flags: review?(bmcbride)
(Assignee)

Comment 16

3 years ago
Created attachment 8469358 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
Attachment #8467461 - Attachment is obsolete: true
Attachment #8467461 - Flags: review?(bmcbride)
Attachment #8469358 - Flags: review?(bmcbride)
Philipp: Do we have an asset for the shield with a strike through it?
Flags: needinfo?(philipp)
Comment on attachment 8469358 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

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

::: browser/base/content/browser.js
@@ +6596,5 @@
>      if (state & nsIWebProgressListener.STATE_BLOCKED_MIXED_ACTIVE_CONTENT)
>        this.showBadContentDoorhanger(state);
> +
> +    // Ensure the doorhanger is shown when mixed active content is detected but not blocked.
> +    if (state & nsIWebProgressListener.STATE_LOADED_MIXED_ACTIVE_CONTENT)

Feel like this should just be added to the above if-condition, since you'll be adding two more possibilities for tracking protection and we don't want to call showBadContentDoorhander multiple times.

::: browser/base/content/urlbarBindings.xml
@@ +1594,5 @@
>              <xul:description class="popup-notification-item-message" xbl:inherits="popupid">
>                &mixedContentBlocked2.moreinfo;
>              </xul:description>
>              <xul:label anonid="mixedContent.helplink" class="text-link" href="" value="&mixedContentBlocked2.learnMore;"/>
> +            <xul:description anonid="mixedContentProtectionDisabled" hidden="true" class="popup-notification-item-message popup-notification-item-message-critical" xbl:inherits="popupid">

Wrap to ~80 characters per line?

@@ +1620,5 @@
>          }
> +        if (this.notification.options.state & Ci.nsIWebProgressListener.STATE_LOADED_MIXED_ACTIVE_CONTENT) {
> +          document.getAnonymousElementByAttribute(this, "anonid", "mixedContent").hidden = false;
> +          document.getAnonymousElementByAttribute(this, "anonid", "mixedContentProtectionDisabled").hidden = false;
> +          document.getAnonymousElementByAttribute(this, "anonid", "mixedContent.helplink").href = Services.urlFormatter.formatURLPref("app.support.baseURL") + "mixed-content";

Now that you're using these elements multiple times, you should store them in fields.

@@ +1634,5 @@
>            // Reload the page with the content unblocked
>            BrowserReloadWithFlags(nsIWebNavigation.LOAD_FLAGS_ALLOW_MIXED_CONTENT);
>          ]]></body>
>        </method>
> +      <method name="_IsMixedContentBlocked">

We generally try to avoid introducing methods that are only used for testing.

::: browser/themes/shared/badcontent-doorhanger.inc.css
@@ +17,5 @@
>    width: 200px;
>  }
>  
> +.popup-notification-item-message-critical[popupid="bad-content"] {
> +  color: red;

As per Chameleon, this should be #d74345 (see error red - http://people.mozilla.org/~jgruen/chameleon/#nav5)
Attachment #8469358 - Flags: review?(bmcbride) → review-
Created attachment 8469980 [details]
Strikethrough Shield

Here are the assets for the shield
Flags: needinfo?(philipp)
Blocks: 1029886
(Assignee)

Comment 20

3 years ago
Created attachment 8473259 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8469358 - Attachment is obsolete: true
(Assignee)

Comment 21

3 years ago
Created attachment 8473400 [details]
Screen Shot 2014-08-14 at 6.08.14 PM.png
Attachment #8465546 - Attachment is obsolete: true
(Assignee)

Comment 22

3 years ago
Created attachment 8473402 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8473259 - Attachment is obsolete: true
(Assignee)

Comment 23

3 years ago
Created attachment 8473421 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8473402 - Attachment is obsolete: true
(Assignee)

Comment 24

3 years ago
Created attachment 8473422 [details]
Screen Shot 2014-08-14 at 7.06.44 PM.png
Attachment #8473400 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Blocks: 1045809
Comment on attachment 8473421 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

Don't forget to tag me for review - too easy to miss these otherwise!
Attachment #8473421 - Flags: review?(bmcbride)
(Assignee)

Comment 26

3 years ago
Created attachment 8473884 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Comment 27

3 years ago
Comment on attachment 8473884 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

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

Addressed review comments. We do need some way to test the state of the doorhanger, either with a method or a field that aliases to 'notification.state'. Right now we are doing the first but I guess we could do the latter.
Attachment #8473884 - Flags: review?(bmcbride)
(Assignee)

Updated

3 years ago
Attachment #8473421 - Flags: review?(bmcbride)
(Assignee)

Updated

3 years ago
Attachment #8473421 - Attachment is obsolete: true
Hey Philipp, if protection is disabled and the strike-through shows in the location bar, should the strike-through also be in the doorhanger? If so, could we get a larger version of strike-through shield?

https://bug1043803.bugzilla.mozilla.org/attachment.cgi?id=8473422
Flags: needinfo?(philipp)
(Assignee)

Comment 29

3 years ago
Created attachment 8475329 [details]
Screen Shot 2014-08-19 at 11.20.35 AM.png
Attachment #8473422 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Attachment #8473884 - Flags: review?(bmcbride)
(Assignee)

Comment 30

3 years ago
Created attachment 8475330 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8473884 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Attachment #8475330 - Flags: review?(adw)
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #28)
> Hey Philipp, if protection is disabled and the strike-through shows in the
> location bar, should the strike-through also be in the doorhanger? If so,
> could we get a larger version of strike-through shield?
> 
> https://bug1043803.bugzilla.mozilla.org/attachment.cgi?id=8473422

Good point. Yes, there should be a strikethrough.
I'll post an asset here as soon as I have it.
Flags: needinfo?(philipp)
(Assignee)

Comment 32

3 years ago
Created attachment 8476795 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Comment 33

3 years ago
(In reply to gkontaxis from comment #32)
> Created attachment 8476795 [details] [diff] [review]
> checkIdentity following onSecurityChange now shows doorhanger on
> STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

This one carries over changes made after bug 1043797 was reviewed. Minor stuff (renaming, space trimming)
(Assignee)

Comment 34

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=b781490fe3be
(Assignee)

Updated

3 years ago
Blocks: 1043801
(Assignee)

Comment 35

3 years ago
Created attachment 8477004 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

Updated

3 years ago
Attachment #8477004 - Flags: review?(adw)

Updated

3 years ago
Attachment #8475330 - Attachment is obsolete: true
Attachment #8475330 - Flags: review?(adw)

Updated

3 years ago
Attachment #8476795 - Attachment is obsolete: true
(Assignee)

Comment 36

3 years ago
Created attachment 8477535 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Comment 37

3 years ago
(In reply to gkontaxis from comment #36)
> Created attachment 8477535 [details] [diff] [review]
> checkIdentity following onSecurityChange now shows doorhanger on
> STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

minor (major? ) fix. Broken shield icon did not appear on Windows when an Aero theme was used. Entry was missing from jar.mn

Comment 38

3 years ago
Comment on attachment 8477004 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

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

Here are comments I had saved while working on the version of this patch posted yesterday... I'll start reviewing the new patch now, but I won't copy the comments below there.

::: browser/base/content/browser.js
@@ +6589,5 @@
> +    // - mixed active content is blocked
> +    // - mixed active content is loaded (detected but not blocked)
> +    if (state &
> +        (nsIWebProgressListener.STATE_BLOCKED_MIXED_ACTIVE_CONTENT
> +        |nsIWebProgressListener.STATE_LOADED_MIXED_ACTIVE_CONTENT)) {

Nit: Please put the | at the end of the previous line with a space before it.

@@ +6596,4 @@
>    },
>  
>    showBadContentDoorhanger : function(state) {
> +    let nsIWebProgressListener = Ci.nsIWebProgressListener;

Nit: I don't think this is helpful.

::: browser/base/content/urlbarBindings.xml
@@ +1617,5 @@
>                  </xul:menupopup>
>                </xul:button>
>              </xul:hbox>
> +            <xul:hbox anonid="mixedContentProtectionDisabled" hidden="true"
> +              class="popup-notification-footer" xbl:inherits="popupid">

Nit: We usually indent so that the first attribute names on all the lines line up, like:

<xul:hbox anonid="" hidden=""
          class="" xbl:inherits=""
          foo="">

@@ +1647,5 @@
>            "mixedContentAction.unblock")
>        </field>
> +      <field name="_mixedContentProtectionDisabledWarning">
> +        document.getAnonymousElementByAttribute(this, "anonid",
> +        "mixedContentProtectionDisabled")

Nit: Please indent the third arg with the open paren, or at least two spaces if that's what your patch in bug 1043797 mostly does.

@@ +1671,5 @@
>              Services.urlFormatter.formatURLPref("app.support.baseURL")
>                + "mixed-content";
>          }
> +        if (this.notification.options.state &
> +          Ci.nsIWebProgressListener.STATE_LOADED_MIXED_ACTIVE_CONTENT) {

Nit: Please indent the second line with the open paren.
Attachment #8477004 - Flags: review?(adw)

Updated

3 years ago
Attachment #8477004 - Attachment is obsolete: true

Updated

3 years ago
Attachment #8477535 - Flags: review?(adw)

Comment 39

3 years ago
Comment on attachment 8477535 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

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

::: browser/base/content/test/general/browser_bug822367.js
@@ +57,2 @@
>    PopupNotifications.panel.firstChild.disableMixedContentProtection();
> +  notification.remove();

Why does this patch make it necessary to call remove()?

::: browser/base/content/urlbarBindings.xml
@@ +1653,1 @@
>        <field name="_mixedContentHelplink">

Nit: Would be nice to capitalize Link.

@@ +1674,5 @@
> +        if (this.notification.options.state &
> +          Ci.nsIWebProgressListener.STATE_LOADED_MIXED_ACTIVE_CONTENT) {
> +          _mixedContent.hidden = false;
> +          _mixedContentProtectionDisabledWarning.hidden = false;
> +          _mixedContentHelplink.href =

Nit: This link is set in both this case and the STATE_BLOCKED_MIXED_ACTIVE_CONTENT case above.  Since each case is an `if`, instead of the second case being an `else if`, at first glance it kind of looks like an error.  It happens that the URL is the same in both cases, so the intent would be a little clearer if you wrote

if (state & (BLOCKED | LOADED)) {
  _mixedContentHelplink.href = ...;
}

I'm really nitpicking here, though.

@@ +1692,5 @@
>            BrowserReloadWithFlags(
>              nsIWebNavigation.LOAD_FLAGS_ALLOW_MIXED_CONTENT);
>          ]]></body>
>        </method>
> +      <method name="_IsMixedContentBlocked">

I see that Blair said we don't usually expose things for tests like this.  You can access the .notifications property from test code and then do this check there.

But, I actually think that having a "public" (meaning non-underscored) isMixedContentBlocked property is perfectly reasonable, even if it is only used in tests.  So how about changing the name to that and making it a read-only property instead of a method?
Attachment #8477535 - Flags: review?(adw) → review+
(Assignee)

Comment 40

3 years ago
(In reply to Drew Willcoxon :adw from comment #39)
> Comment on attachment 8477535 [details] [diff] [review]
> checkIdentity following onSecurityChange now shows doorhanger on
> STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
> 
> Review of attachment 8477535 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/base/content/test/general/browser_bug822367.js
> @@ +57,2 @@
> >    PopupNotifications.panel.firstChild.disableMixedContentProtection();
> > +  notification.remove();
> 
> Why does this patch make it necessary to call remove()?
> 
Is there way to undo the outcome of notification.reshow()? It's not necessary everywhere but I had tests fail because of the shift in focus.

> ::: browser/base/content/urlbarBindings.xml
> @@ +1653,1 @@
> >        <field name="_mixedContentHelplink">
> 
> Nit: Would be nice to capitalize Link.
> 
> @@ +1674,5 @@
> > +        if (this.notification.options.state &
> > +          Ci.nsIWebProgressListener.STATE_LOADED_MIXED_ACTIVE_CONTENT) {
> > +          _mixedContent.hidden = false;
> > +          _mixedContentProtectionDisabledWarning.hidden = false;
> > +          _mixedContentHelplink.href =
> 
> Nit: This link is set in both this case and the
> STATE_BLOCKED_MIXED_ACTIVE_CONTENT case above.  Since each case is an `if`,
> instead of the second case being an `else if`, at first glance it kind of
> looks like an error.  It happens that the URL is the same in both cases, so
> the intent would be a little clearer if you wrote
> 
> if (state & (BLOCKED | LOADED)) {
>   _mixedContentHelplink.href = ...;
> }
> 
I already have a bug which adds two more blocked/loaded states for tracking protection. So I think it's cleaner to have four blocks of code each containing everything that should apply under the respective state.

> I'm really nitpicking here, though.
> 
> @@ +1692,5 @@
> >            BrowserReloadWithFlags(
> >              nsIWebNavigation.LOAD_FLAGS_ALLOW_MIXED_CONTENT);
> >          ]]></body>
> >        </method>
> > +      <method name="_IsMixedContentBlocked">
> 
> I see that Blair said we don't usually expose things for tests like this. 
> You can access the .notifications property from test code and then do this
> check there.
> 
> But, I actually think that having a "public" (meaning non-underscored)
> isMixedContentBlocked property is perfectly reasonable, even if it is only
> used in tests.  So how about changing the name to that and making it a
> read-only property instead of a method?
(Assignee)

Comment 41

3 years ago
Created attachment 8477636 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state
(Assignee)

Updated

3 years ago
Attachment #8477535 - Attachment is obsolete: true
(Assignee)

Comment 42

3 years ago
(In reply to gkontaxis from comment #41)
> Created attachment 8477636 [details] [diff] [review]
> checkIdentity following onSecurityChange now shows doorhanger on
> STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

This addresses both reviews from above.
(Assignee)

Comment 43

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=abb816b7e846 just to make sure tests are working after the _IsMixedContentBlocked() -> isMixedContentBlocked change

Comment 44

3 years ago
(In reply to gkontaxis from comment #40)
> > ::: browser/base/content/test/general/browser_bug822367.js
> > @@ +57,2 @@
> > >    PopupNotifications.panel.firstChild.disableMixedContentProtection();
> > > +  notification.remove();
> > 
> > Why does this patch make it necessary to call remove()?
> > 
> Is there way to undo the outcome of notification.reshow()? It's not
> necessary everywhere but I had tests fail because of the shift in focus.

I'm not very familiar with this, but removing after reshowing sounds like a reasonable thing to do, it's just that it's not clear why, if it wasn't necessary before this patch, it now is.
Comment on attachment 8477636 [details] [diff] [review]
checkIdentity following onSecurityChange now shows doorhanger on STATE_LOADED_MIXED_ACTIVE_CONTENT. Doorhanger now acknowledges this new state

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

Carrying over adw's r+ from comment 39.
Attachment #8477636 - Flags: review+
(Assignee)

Comment 46

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=e443fc2023ef
https://hg.mozilla.org/integration/fx-team/rev/cb7e88a77a48
https://hg.mozilla.org/mozilla-central/rev/cb7e88a77a48
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34

Updated

3 years ago
Iteration: --- → 34.3
Flags: qe-verify?
Flags: qe-verify? → qe-verify+
QA Contact: catalin.varga
I've tested this bug using:

FF 34
Build Id: 	20140831030206
OS: Win 7 x64, Ubuntu 13.04 x64, Mac Os X 10.9.4

The shield icon notification disappeared on the https://people.mozilla.org/~mkelly/mixed_test.html page.
Just Disable the protection on the page and the enable it back adn the shield will disappear. I did not manage to reproduce this using other pages. Is this an issue with the page or an issue with the implementation?
Flags: needinfo?(georgios.kontaxis)

Comment 50

3 years ago
I see it, too, on the page you linked, but I cannot reproduce on https://people.mozilla.org/~mchew/show_ads.html.  The first page has the green site identity section in the location bar but Monica's page doesn't.  Maybe that's related?  Could you please file a new bug?
Tanvi, I suspect this has to do with the underlying implementation of Mixed Content Blocker, not the shield being non-dismissible. Could you take a look?
Flags: needinfo?(georgios.kontaxis) → needinfo?(tanvi)
Filled bug https://bugzilla.mozilla.org/show_bug.cgi?id=1063390 .
Depends on: 1063390

Comment 53

3 years ago
Cancelling need info, I'm following up in bug 1063390.
Flags: needinfo?(tanvi)
Blocks: 1063831
As the only issue encountered during testing was logged in a different bug. Marking this issue as
Verified on:
FF 34
Build Id: 	20140831030206
OS: Win 7 x64, Ubuntu 13.04 x64, Mac Os X 10.9.4
Status: RESOLVED → VERIFIED

Comment 55

3 years ago
(Bug 1063831 is a Fennec bug, and this is a desktop bug)
No longer blocks: 1063831
You need to log in before you can comment on or make changes to this bug.