1474716 - An https PDF opened in a new tab is called as "Not Secure", respectively the padlock icon is missing

Status: RESOLVED FIXED

(Firefox :: Site Identity, defect, P3)

Description

[Darkspirit]

Attachment: Screenshot_20180710_223713.png

1. Open https://www.natlawreview.com/article/german-court-issues-first-gdpr-ruling
2. First sentence: Right click on "first decision" > Open in new tab.
3. Switch to the second tab. If you don't see a padlock: That's the bug.

Screenshot:
mozregression --launch 2018-07-10 --pref security.insecure_connection_icon.enabled:true security.insecure_connection_text.enabled:true -a 'https://www.natlawreview.com/article/german-court-issues-first-gdpr-ruling'

It's seems to be rarely(?) possible to see a green padlock if you try a second time (on an existing connection with a cached pdf?) and wait a bit before switching tabs, but the default is a missing padlock.

This seems to be a longstanding bug:
mozregression --good 2014-09-01 --bad 2015-01-01 -a 'https://www.natlawreview.com/article/german-court-issues-first-gdpr-ruling'
> 5:58.40 INFO: Last good revision: 62990ec7ad78 (2014-11-05)
> 5:58.40 INFO: First bad revision: 2114ef80f6ae (2014-11-06)
> 5:58.40 INFO: Pushlog:
> https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=62990ec7ad78&tochange=2114ef80f6ae

Comment 1

[Ryan VanderMeulen [:RyanVM]]

I can reproduce this intermittently as well (first attempt I got the padlock, second time I didn't). Nothing obvious in the browser console. Possibly related to bug 971432?

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #1)
> I can reproduce this intermittently as well (first attempt I got the
> padlock, second time I didn't). Nothing obvious in the browser console.
> Possibly related to bug 971432?

So, I can reproduce the issue as well (first time no green padlock, second time there was one). Unfortunately I don't have the cycles to debug this at the moment. However, stepping through nsMixedContentBlocker::ShouldLoad() for the various calls might shed some light on the underlying problem.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix in 63. We could still take a patch for 65 and potentially for 64.

Comment 5

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I can't seem to reproduce this any longer - maybe the changes in bug 832834 or a follow-up fixed it?

Comment 6

[Darkspirit]

Yes, thank you! :)

mozregression --find-fix --bad 2018-07-10 --good 2018-10-13 --pref security.insecure_connection_icon.enabled:true security.insecure_connection_text.enabled:true -a 'https://www.natlawreview.com/article/german-court-issues-first-gdpr-ruling'
> 17:16.74 INFO: First good revision: 2f4adf14e6231a1668558dd78ecbe56a421591b6
> 17:16.74 INFO: Last bad revision: 7056aff16fb8124f1d6043538b9947017c4623e4
> 17:16.74 INFO: Pushlog:
> https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7056aff16fb8124f1d6043538b9947017c4623e4&tochange=2f4adf14e6231a1668558dd78ecbe56a421591b6

> 2f4adf14e623	Dana Keeler — bug 832834 - reimplement nsSecureBrowserUIImpl r=franziskus,Felipe

Comment 7

[Sayed [:LiquidO2]]

I can reproduce this issue in Nightly 63.0a1 (2018-07-10) (64-bit) on Linux x86_64 (Arch)

I can verify that this is fixed in latest beta 64.0b12
Build ID 	20181122182000
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0