Open Bug 860712 Opened 7 years ago Updated 7 years ago
Mixed content blocker doorhanger needs a "For this session" choice
No description provided.
Trying to use a mixed-content site without this feature, or one similar, is really a PITA. There are some sites that users just can't use less often, so they will more than likely just switch to a different browser that isn't "breaking" the website.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Jared Wein [:jaws] from comment #1) > There are some sites that users just can't use less often, so they will more > than likely just switch to a different browser that isn't "breaking" the > website. We have not seen any examples of that. Please provide examples of a non-Mozilla site that raised this concern and which MSIE or Chrome handle better than us in this respect. (Mozilla sites should just all get fixed before this makes it to the release channel.) I doubt this is going to get changed without concrete evidence that we're actually doing worse than other browsers on some real-world (and important) website.
This is visible on the Apis Networks control panel, which is a hosting company that I use. Their secure site has other issues (it uses a self-signed certificate), but going from one page to another over HTTPS is quite bothersome. I see that IE also lacks the ability to whitelist a site (temporary or permanent). I didn't think about the fact that IE and Chrome also will be blocking mixed content, so there may not be an alternative browser that people can use. This does change the urgency of it, and I guess puts more pressure on the website authors.  https://cp.borel.apisnetworks.com/login
(In reply to Jared Wein [:jaws] from comment #3) > I see that IE also lacks the ability to whitelist a site (temporary or > permanent). > > I didn't think about the fact that IE and Chrome also will be blocking mixed > content, so there may not be an alternative browser that people can use. > This does change the urgency of it, and I guess puts more pressure on the > website authors. Right. My thinking is that we don't need to make these broken sites any *more* convenient to use than they are to use in MSIE or Chrome, but we should put effort into being *as* convenient. If others think it is good to try to be more convenient, then we can talk about that, but I think that in the long run that is harmful to the internet. See, many websites simply don't realize that when they load a script from a non-HTTPS page into a HTTPS page, what they're doing is in many ways *worse* than not using HTTPS at all for the page with the script tag. So, trying to make this tolerable is actively working against the security of the sites that are using the mixed content, so IMO we should only do so if we have a really big motivation. And, at this point, with MSIE and Chrome already blocking mixed content for over a year each, I think it's unlikely we'll find such a big motivation.
This bug proposes including a per this session option in the UI. Bug 902156 is to add some persistence automatically, but not for an entire session. Hence it's not quite a duplicate.
There are two ways the UX could go for this: 1) Take the "Disable Protection on This Page" option and extend it so that it actually disables protection for the entire session. 2) Create a new option in the doorhanger for "Disable Protection for this Session". There are unfortunately some issues with both of these. For number 1 - IMHO, per session persistence of a user's decision to "Disable protection on this page" should not be possible without a "re-enable protection" mechanism. If a user disabled protection on a page, they would have to restart the browser in order to re-enable that protection. A re-enable option is what bug 902586 is for.n The UI for that is going to be tricky and I don't see it happening anytime soon. The backend code for this would actually be really easy (we just have to set the mixedContentChannel to null). For number 2 - from UX I've heard that the user's don't understand what a session is. If UX is okay with adding a "Disable Protection for this Session" option to the doorhanger, then the UI would be easy. The backend would take a bit more work, but it's feasible. Thoughts?
Depends on: 902586
Regardless of how it's surfaced in the UI, wouldn't the session persistence issue be solved with the same mechanism click-to-play uses for enabling blocked plugins (IIRC the permission expires after 1.5 hours if the user has not visited the domain the enabled plugin resides). Maybe "session" is not the right word for the bug summary.
You need to log in before you can comment on or make changes to this bug.