1166754 - Confusing approval message for add-on install process via drag&drop

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, enhancement, P5)

Description

[Vasilica Tamas, QA [:vtamas]]

Reproducible on: Firefox 41.0a1 and Firefox 40.0a2 across Windows 7 64-bit and Mac OS X 10.9.5


STR
1.Launch Firefox with clean profile
2.Drag & drop a signed add-on into the browser (or install it from about:addons->Install Add-on From File...)
3.Check the install doorhanger

ER
The system requires the user approval for the local file add-on install process.

AR
The approval message “This site would like to install...” is confusing because the add-on is installed from the user’s local file.


Additional notes:
- This issue is reproducible on Firefox 41.0a1 (2015-05-19) and 40.0a2 (2015-05-20) using Windows 7 64-bit and Mac OS X 10.9.5
- This issue also reproduces for add-ons that are installed from about:addons->Install Add-on From File...
- I am attaching a screenshot http://i.imgur.com/fWHiAkY.jpg

Comment 1

[Dave Townsend [:mossop]]

I agree this message is confusing. Given the string change though I don't think this is something we'd need to take in Firefox 40. Markus, what other text should we use here?

Comment 2

[Markus Jaritz [:designakt] (UX)]

In the design I planned to have the domain be stated in the add-on install doorhanger. For local files this should state "Local File" and the page should not be blank, but provide some reference to the add-on. As can be seen here: https://bug1120996.bugzilla.mozilla.org/attachment.cgi?id=8598797
For this site might still not be perfect, but much less confusing. Is it in that case till necessary to have a separate string for this edge case? If so I can re-iterate with Matej on the wording of local installs. (Local File, Another Program, Add-ons Manager). What is the time-frame for that to be implemented?

Comment 3

[Dave Townsend [:mossop]]

Looks like I lost track of that one, filed bug 1166949. I don't know how high priority it is, I'll have to talk these other bugs over with Kev.

I think even with "Local File" in the doorhanger the term "site" seems confusing.

Comment 4

[Tony Mechelynck [:tonymec]]

IIUC, for local files the site is "localhost". Some browsers (lynx…) even resolve file:///path/to/filename.htm as file://localhost/path/to/filename.htm

This said, shouldn't XPIs manually installed from a local location bypass the doorhanger and go straight to the are-you-sure "Install Now" countdown, like those from AMO do?

Comment 6

[Markus Jaritz [:designakt] (UX)]

I believe we should block drag-and-drop of .XPIs on all pages but about:addons to solve that issue.

I recently re-considered this problem when working on the install for WebExtension.
The current behavior is not consistent with how we deal with dragging other files into Firefox.

For any other file we currently replace the site with the file itself. (Try dragging an image into Firefox. It will replace the current page.) Or, as currently seen in Nightly, we block dragging it onto a website if the website specified any drag-and-drop behavior (try dragging an image onto Facebook or Twitter in Nightly, it will be blocked if not dragged into the dedicated areas.)

For dragging .XPIs we currently leave the previous page in place and display the extension install flow, which is neither of the 2 previous behaviors.
To unify that we can either replace the underlying page with about:addons and the show the install dialog, or block drag-and-drop on all pages but about:addons.

As this is a feature similar to load from file in about:addons and more focused towards power users, I would suggest only enabling it on about:addons.
And maybe we could even give a drag-and-drop feedback on about:addons, confirming that drag-and-drop will add the file. (like the many sites use to indicate that one can drag into a certain area to upload.)

Comment 7

[Vasilica Tamas, QA [:vtamas]]

The confusing message “This site would like to install...” is still present while installing a legacy add-on from local file in Firefox 54.0a1 (2017-02-19), Firefox 53.0a2 (2017-02-20), Firefox  52.0b7 and Firefox 51.0.1. Setting the tracking flags accordingly.

See screenshot: https://www.screencast.com/t/IpU01OUbjy

Comment 8

[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.