Closed Bug 628041 Opened 14 years ago Closed 6 years ago

"Firefox prevented this site ..." doorhanger's wording makes little sense

Categories

(Toolkit :: Add-ons Manager, defect, P1)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla68
Tracking Flags:
Tracking Status
blocking2.0 --- -
firefox68 --- fixed

People

(Reporter: u88484, Assigned: mixedpuppy)

References

Details

(5 keywords, Whiteboard: [arewepretty-add][doorhanger])

Attachments

(4 files)

Screenshot of prompts
62.65 KB, image/png
Details
Bug 628041 refresh the install blocked panel text
47 bytes, text/x-phabricator-request
Details | Review
new panel.png
134.26 KB, image/png
Details
unknown-source.png
102.57 KB, image/png
meridel
: feedback+
Details
Attached image Screenshot of prompts —
The "Firefox prevented this site (site) from asking you to install software on your computer" (with the options of 'Allow' and 'Not Now') doorhanger's wording makes little sense. If I clicked a link to install an extension then why am I prompted about a blocked prompt? Why not just show me the add-on installation prompt to being with? Plus the add-on installation prompt says that I requested to install the software, not the site as the first prompt states. STR: 1) Click http://glandium.org/files/startup.xpi 2) Read the doorhanger then click allow 3) Read the next prompt 4) Be confused on why you were prompted about a blocked prompt, why one says the site requested and the next says you requested, and that you have to go through two prompts to allow an add-on to be installed from third-party sites.
blocking2.0: --- → ?
The first prompt is to make sure that you actually meant to start an installation because it is trivial for websites to start them with no user interaction or unintentional interaction, the second prompt is to make sure that you actually want to install the add-on. This text has been the way it has for many versions of Firefox, not going to block on changing it.
blocking2.0: ? → -
This is totally broken. The doorhanger needs to ask a question, and the action button needs to be so self describing that you can get all context by reading only it. (more details here https://bug588240.bugzilla.mozilla.org/attachment.cgi?id=466966 ) For instance: Would you like to share your location with this site? [share location] Currently, this dialog makes a declarative statement, and then provides a vague ok. I don't think this is bad enough to block the release, but I'll add it to the doorhanger cleanup work over at http://areweprettyyet.com/4/notifications/ Did these messages ever go through ui-review?
Whiteboard: [arewepretty-add]
(In reply to comment #2) > Did these messages ever go through ui-review? Beltzner was the one who actually provided the string nearly 5 years ago in bug 308060 if that counts ;)
Not really, for some reason we treated doorhangers as simply a new API that could be called with all of the existing functionality. We now have to clean up a bunch of them retroactively. Browser level events are being handed to doorhangers, pretty much all of them have strings that don't ask a question, etc. All of these should have had a ui-review sometime during this ship cycle before being checked in (this, indexeddb, etc).
Whiteboard: [arewepretty-add] → [arewepretty-add][doorhanger]
I've actually had to read this bug report to finally understand what the phrase "Firefox prevented this site (www.eff.org) from asking you to install software on your computer." attempts to say. Suggested replacement: "Firefox stopped this site from opening the Add-ons dialog." No more. And the button would say "Allow opening". (It is in my opinion not needed to mention the site, as it is right there next to the doorhanger in the location bar.)
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INACTIVE
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 20180607220114 This bug is not an enhancement request, it's still present in the latest Nightly, and a duplicate was just filed. Hopefully that makes it okay to reopen. See attachment 8984193 [details] for an up-to-date screenshot.
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
See Also: → 1232664

It's nearly Spring. Let's clean up a bit.

Priority: -- → P1

Final copy:

Header: Allow [site name] to install an extension?
Body: This site needs your permission to install an extension on your computer. Make sure you trust the site before continuing.
Buttons: Don't Allow / Allow
Link: Learn more about installing extensions safely (https://support.mozilla.org/kb/tips-assessing-safety-extension)

See also bug 1475710
I guess we should dupe that bug to this one, but it would be good if the folks writing the copy (Amy?) take a look at the technique described in that bug and ensure it is taken into consideration.

See Also: → 1475710

This copy was written in collaboration with Meridel, ddurst, and Jorge, so I believe it was taken into consideration, but we can verify.

Flags: needinfo?(ddurst)

I don't understand why that would be considered a dupe. I can't imagine any messaging would combat that type of manipulation.

(Maybe we should put an opacity filter on the content pane when the doorhanger is shown)

((I'm only kidding a litte))

Flags: needinfo?(ddurst)
Assignee: nobody → mixedpuppy
Attached image new panel.png —
Pushed by scaraveo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/539ae4c2bd53 refresh the install blocked panel text r=flod,aswan

Backed out changeset 539ae4c2bd53 (bug 628041) for Browser-chrome failures in toolkit/mozapps/extensions/test/xpinstall/browser_doorhanger_installs.js. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=239520930&repo=autoland&lineNumber=5236

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=239517689&revision=539ae4c2bd53dbff20f2a547049b9fd37c295e4d

Backout:
https://hg.mozilla.org/integration/autoland/rev/3886031416c91989349313713f321903f5bdc782

Flags: needinfo?(mixedpuppy)
See Also: → 1543735
Attached image unknown-source.png —

A failing test uses a hidden pref to test the blocked panel with a local install from a file url. This panel is also hit with drag/drop of an xpi.

STR

  • set xpinstall.whitelist.directRequest to false
  • drop an xpi onto a new tab

Because we don't have a nice host name to show the user, and may not have a url (with drag/drop), I've choosen to insert "an unknown source" in place of the domain.

The overall wording is still a little awkward, but it's unlikely a user will hit this in the real world as it requires that pref flip to hit it. I need something here for the test to pass appropriately, and in the odd case we want something relatively readable.

Flags: needinfo?(mixedpuppy)
Attachment #9057589 - Flags: feedback?(mwalkington)

Is the host/source different from the site?

I am inclined to use this phrasing for this case:

Header: Allow an unknown site to install an add-on?
Body: You are attempting to install an add-on from an unknown site. Make sure you trust this site before continuing.
Buttons: Cancel / Continue to Installation

Flags: needinfo?(mixedpuppy)
Comment on attachment 9057589 [details] unknown-source.png Is the host/source different from the site? I am inclined to use this phrasing for this case: Header: Allow an unknown site to install an add-on? Body: You are attempting to install an add-on from an unknown site. Make sure you trust this site before continuing. Buttons: Cancel / Continue to Installation
Attachment #9057589 - Flags: review+
Comment on attachment 9057589 [details] unknown-source.png Is the host/source different from the site? I am inclined to use this phrasing for this case: Header: Allow an unknown site to install an add-on? Body: You are attempting to install an add-on from an unknown site. Make sure you trust this site before continuing. Buttons: Cancel / Continue to Installation
Attachment #9057589 - Flags: review+
Attachment #9057589 - Flags: feedback?(mwalkington)
Attachment #9057589 - Flags: feedback+
Pushed by scaraveo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e56cd039fd94 refresh the install blocked panel text r=flod,aswan
Flags: needinfo?(mixedpuppy)

https://hg.mozilla.org/mozilla-central/rev/e56cd039fd94

Status: REOPENED → RESOLVED
Closed: 7 years ago → 6 years ago
status-firefox68: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

This is not translatable to my language. “an unknown site” needs different translations in xpinstallPromptMessage.header and xpinstallPromptMessage.message. Preferably, the versions for an unknown site would be separate strings. Do I need to reopen this bug, or file a new one?

Depends on: 1544489

Would "anonymous site" or "unidentifiable site" translate?

Flags: needinfo?(piotrdrag)

It wouldn’t change the problem in the slightest. Any phrase still needs to be declined appropriately.

Flags: needinfo?(piotrdrag)

Mark, can you weigh in when back in office? I believe you defined a solution for this.

Flags: needinfo?(mstriemer)

(In reply to Meridel from comment #30)

Would "anonymous site" or "unidentifiable site" translate?

Other disagreement on this is that these are local files or drag/drop operations and therefor not a "site". Again, we only hit this particular path when a hidden pref is flipped. Dealing with this is all about making a test pass. Unlikely any user will ever see it.

The unknown string should be getting fixed in bug 1544489. Looks like the solution we had discussed before.

Flags: needinfo?(mstriemer)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: