Closed Bug 1766965 Opened 3 years ago Closed 3 years ago

Self-hosted Firefox extension install flow is broken on Firefox 100 & 101 beta

Categories

(WebExtensions :: General, defect)

Firefox 101
Desktop
macOS
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: artur.valiev, Unassigned)

References

Details

Steps to reproduce:

  1. Install Firefox 100.0 (Windows or macOS - reproduced on both)
  2. Open the link to a self-hosted XPI file. You can use "open -a Firefox <link_to_xpi>" in macOS Terminal to easily reproduce it.

Actual results:

Firefox only showed the link to the XPI in the address bar but did not prompt for install as usual.

Expected results:

Firefox should have presented the usual add-on install dialog where it asks the user to confirm the installation. With Firefox 100.0 this only happens when I click on the address bar and click Enter additionally. That causes the usual install dialog to appear.
That is very confusing to the user. Why didn't this happen to begin with?

Is this related to the email with "Add-on Install Changes for Self-Hosted Add-ons" subject sent out to developers? Is this how it is supposed to work now? Looks very confusing to users.

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Address Bar
Component: Address Bar → Untriaged
OS: Unspecified → macOS
Hardware: Unspecified → Desktop
Summary: Help-hosted Firefox extension install flow is broken on Firefox 100.0 beta → Helf-hosted Firefox extension install flow is broken on Firefox 100.0 beta

Updated to 101.0b2. The same issue applies to this version

Version: Firefox 100 → Firefox 101
Summary: Helf-hosted Firefox extension install flow is broken on Firefox 100.0 beta → Self-hosted Firefox extension install flow is broken on Firefox 100 & 101 beta

Found this message in the browser log

[Exception... "https://download.sp.f-secure.com/firefox-extension-install/beta/browsing-protection.firefoxextension.xpi install cancelled because of missing user gesture activation" nsresult: "0x0 (NS_OK)" location: "JS frame :: resource://gre/modules/amContentHandler.jsm :: handleContent :: line 51" data: no] amContentHandler.jsm:51:32 handleContent resource://gre/modules/amContentHandler.jsm:51

So sounds to me that it's exactly about the changes in the self-hosted extension install process in the recent email. And indeed in our case, the user does not click on the link. The main product opens the link in Firefox and expects it to start the install process.

So in the essence, it is a user initiated action (user clicks on the button in the product UI) but Firefox only allows direct user click on the link to XPI which is a bummer if I understand the situation correctly.

Component: Untriaged → General
Product: Firefox → WebExtensions

Hello Arthur,

As per what you mentioned in Comment 0 regarding the "Add-on Install Changes for Self-Hosted Add-ons" email received by add-on developers and as well as in Comment 3 about the browser log you found, this is an intended change starting with Firefox 100 wherein add-on installs require explicit user activation.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1768160 for more details about a similar report to yours, more precisely https://bugzilla.mozilla.org/show_bug.cgi?id=1768160#c9 where a suggestion on how to go about this is presented.

For more details regarding the patch that landed the changes, see https://bugzilla.mozilla.org/show_bug.cgi?id=1759737.

Hope this helps !

I will be resolving the issue as WFM since this is the intended behavior. Thank you !

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
See Also: → 1768160

Hello!
Thank you for clarification. That's what we also understood so far looking at the current Firefox behavior.

We decided to try publish our existing extension to the Mozilla Web Store to avoid complications with self-host add-on install flow.

But good to hear the confirmation that this is the intended behavior.
Thank you!

You need to log in before you can comment on or make changes to this bug.