1138138 - Addon install exceptions dialog is unclear that it now only applies to secure pages

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Pierre Chazal]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150228030231

Steps to reproduce:

options, security, select "advise when a site tries to install add-ons" (sorry, translated from French), exceptions, add (for instance) tmp.garyr.net

go to 
http://tmp.garyr.net/dev-builds/

and try to install the last add-on listed there by cliking on it



Actual results:

A dialog box asks me to give an authorization manually


Expected results:

No authorization is needed and the installation dialog box appears

Comment 1

[Pierre Chazal]

Attachment: Screenshot 1 : exceptions, sites authorized to install add-ons

Comment 2

[Pierre Chazal]

Attachment: Screenshot 2 : trying to install an addon from one of the exceptions

Comment 3

[Petruta Horea [:phorea]]

Reproduced on Nightly 39.0a1 and Firefox 37 beta 1 under Win 7 64-bit. I didn't found an issue to dupe this one after, so confirming this one.

Comment 4

[:Gijs (he/him)]

Blair, I think this might be due to a fix you landed. Plausible? And if so, do we want to fix this, or should we just update the language there to make it clear we require https for this to work?

Comment 5

[Petruta Horea [:phorea]]

Regression range:

Last good revision: 2cb22c058add (2015-02-10)
First bad revision: ee093ca70666 (2015-02-11)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2cb22c058add&tochange=ee093ca70666

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to :Gijs Kruitbosch from comment #4)
> Blair, I think this might be due to a fix you landed. Plausible? And if so,
> do we want to fix this, or should we just update the language there to make
> it clear we require https for this to work?

Yea, this is the new HTTPS requirement. Entirely intentional, but I guess the failure mode could be more clear. We could probably look into providing a doorhanger similar to what happens if the add-on hash is wrong - "this add-on can't be installed because the page installing it is not secure" or something. We don't have an existing appropriate message for this, and it may need an API change to actually detect that in the frontend :\

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Oh, and we shouldn't be asking for authorisation confirmation - that's an existing bug in the doorhanger code.

Comment 8

[Liz Henry (:lizzard)]

Tracking for 38 and 39. I agree, we shouldn't do this without an explanation to the user. 

What is the existing bug about authorization?

Blair, is this something you would decide how to handle or does it need some discussion and planning?

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Ugh, ignore comment 6 and comment 7 - over-stressed brain got that way wrong.

The notifications are working as they should. And the install is allowed, it just always requires manual confirmation if it's not over HTTPS. So I don't think we should add another notification, nor change the wording of the existing notification. AFAIK this is in line with all other notifications for permissions that require HTTPS to persist a permission - this is the general trend for all permissions.

Given that, IMO the only thing affected here is the wording of the preferences exceptions dialog. We could add "when accessed securely" (or something) to that wording, but I don't think that's something worth tracking for 38/39.

Comment 10

[Pierre Chazal]

Is it too complicated fixing the bug (regression) and having the same behavior in dev versions as in the release version, currently 36 ?

Comment 11

[Liz Henry (:lizzard)]

Blair, I see what you mean now!  It would make sense to me to say something in the about:preferences#security dialogue so that people know when they add exceptions that exceptions only work if accessing over https (or whatever phrasing you think would be best). Thanks for the explanation. 

Pierre I can see that it might be annoying to have to click the exception button while you are developing and testing. It sounds like we are moving towards a consistent approach in encouraging secure connections. Given that it is intentional, I don't think we're seeing this as a regression. 

Untracking for 38 and 39.

Comment 12

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.