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

RESOLVED FIXED in Firefox 68

Status

()

defect
P1
normal
RESOLVED FIXED
8 years ago
27 days ago

People

(Reporter: u88484, Assigned: mixedpuppy)

Tracking

(5 keywords)

unspecified
mozilla68
Points:
---

Firefox Tracking Flags

(blocking2.0 -, firefox68 fixed)

Details

(Whiteboard: [arewepretty-add][doorhanger])

Attachments

(4 attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Updated

8 years ago
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]

Comment 5

6 years ago
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.)

Comment 6

a year ago
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
Last Resolved: a year ago
Resolution: --- → INACTIVE

Updated

a year ago
Duplicate of this bug: 1467500

Comment 8

a year ago
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 → ---

Updated

11 months ago
See Also: → 1232664

Updated

2 months ago
Duplicate of this bug: 1535445

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

Priority: -- → P1

Comment 11

2 months ago

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

Comment 13

2 months ago

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)

Updated

2 months ago
Assignee: nobody → mixedpuppy
(Assignee)

Comment 17

2 months ago
Posted image new panel.png

Comment 18

a month ago
Pushed by scaraveo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/539ae4c2bd53
refresh the install blocked panel text r=flod,aswan
Flags: needinfo?(mixedpuppy)
(Assignee)

Updated

a month ago
See Also: → 1543735
(Assignee)

Comment 22

a month ago
Posted 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)

Comment 24

a month ago

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 25

a month ago
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 26

a month ago
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+

Comment 27

a month ago
Pushed by scaraveo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e56cd039fd94
refresh the install blocked panel text r=flod,aswan
(Assignee)

Updated

a month ago
Flags: needinfo?(mixedpuppy)

Comment 28

a month ago
bugherder
Status: REOPENED → RESOLVED
Last Resolved: a year agoa month ago
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?

(Assignee)

Updated

a month ago
Depends on: 1544489

Comment 30

a month ago

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)

Comment 32

a month ago

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

Flags: needinfo?(mstriemer)
(Assignee)

Comment 33

a month ago

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