The default bug view has changed. See this FAQ.

Feeds served over HTTPS act insecure (no SSL indicators)

RESOLVED WONTFIX

Status

()

Firefox
RSS Discovery and Preview
P3
normal
RESOLVED WONTFIX
11 years ago
a month ago

People

(Reporter: philor, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 -
wanted-firefox3 +
blocking-firefox2 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

11 years ago
STR:

1. For extra fun, set security.warn_leaving_secure to true
2. Go to https://bugzilla.mozilla.org/buglist.cgi?bug_id=333751
3. Click the "RSS" link at the bottom of the list.
4. Get a warning that you are leaving a secure page for an insecure one, and when the feed at https://bugzilla.mozilla.org/buglist.cgi?bug_id=333751&ctype=rss loads note that the addressbar background is white, and that there's no lock icon.
Assignee: nobody → bugs
Priority: -- → P3
Target Milestone: --- → Firefox 2 beta1
Whiteboard: [swag:5d]
Flags: blocking-firefox2+
The reason for this is:

- the original content loads over https (secure)
- the preview page is loaded from a jar channel (insecure)

nsSecureBrowserUIImpl inspects the current channel for securityInfo and uses that to update the browser UI. 

In this "nested" channel situation we have no way of knowing what the securityInfo of the original channel is. 

This will potentially require significant API changes. Since this is lesser priority (worst case is user getting freaked out that content isn't secure when it actually is - anyway https: is still shown in location bar if coloration and lock icon isn't), I'm going to mark this not blocking. 
Flags: blocking-firefox2+ → blocking-firefox2-
Keywords: relnote
related with bug 232944?
Flags: blocking1.9?
Keywords: relnote
Target Milestone: Firefox 2 beta1 → Firefox 3 alpha1

Updated

11 years ago
Flags: blocking1.9? → blocking-firefox3?
Assignee: bugs → nobody
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [swag:5d] → [wanted-firefox3]
(Reporter)

Updated

10 years ago
Target Milestone: Firefox 3 alpha1 → ---
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]
(In reply to comment #2)
> related with bug 232944?

I would more say no, but might be. At least, I don't believe fixing that bug will be sufficient to fix this one.
Seems more like fixing bug 482245 will help here because we change location of the page to file://.../subscribe.xhtml.
Depends on: 482245
Duplicate of this bug: 498376
Blocks: 130949
(Reporter)

Updated

7 years ago
Duplicate of this bug: 530153
I promise I searched for this, but I used SSL and not HTTPS in my search. :(
Summary: Feeds served over HTTPS act insecure → Feeds served over HTTPS act insecure (no SSL indicators)
Duplicate of this bug: 660139
Duplicate of this bug: 681601
The feed reader component has been mostly demoted in recent versions of Firefox, and we're unlikely to extend or expand on it. The bug mentioned here sounds relatively minor, and unique to the feed reader component, so I'm marking WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → WONTFIX
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1140192

Updated

2 years ago
Duplicate of this bug: 1171023

Updated

2 years ago
Duplicate of this bug: 1206905
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1214251

Comment 15

9 months ago
Appears to be fixed as of Firefox 47.

I'm Running Firefox 47 on OpenBSD-current amd64, getting the correct padlock indicator when viewing RSS feeds over TLS.

Comment 16

5 months ago
FF49.0.2 Mac still shows this error.  Have had to explain to customers that the issue is with Firefox, not services provided by my employ.

Updated

a month ago
Duplicate of this bug: 1338840
You need to log in before you can comment on or make changes to this bug.