1558336 - Allowing extension to run in PB via doorhanger closes post-install page and breaks extension

Status: RESOLVED FIXED

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

Description

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

STR:

1. Install an extension such as Clippings1 or AdNauseam2 from AMO
2. Extension will open a post-install page
3. Check the box in the doorhanger to allow extension to run in PB mode
4. Click "Okay, Got it"

Expected result: Post-install page to remain open and extension to remain active/working

Actual result: Closes post-install page, and extension partially stops working. Restarting the browser enables the extension to work again.

Tested on Release and Nightly
macOS Mojave 10.14.5

Video: https://drive.google.com/open?id=1Y-u6ztJlTwwh5NFIVLfzGOYoZuSh-BqC

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:ddurst, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

The extensions tabs are being closed as a side-effect of setting the private browsing permission (which currently reloads the extension), and so that part is technically expected (even if it is probably not expected by the installed extension).

Is the "extension partially stops working" issue related to the "clippings"'s context menu items missing from the context menu?

Comment 3

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

(In reply to Luca Greco [:rpl] from comment #2)

Is the "extension partially stops working" issue related to the "clippings"'s context menu items missing from the context menu?

Yes, the clippings do not appear in the context menu. Also, clicking the toolbar icon does not open a dialog as it's supposed to.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Rob Wu [:robwu]]

As comment 2 said, the closed tabs is expected behavior; the side effect of reloading (=also unloading) an extension.

The other reported problem is the absence of context menus in the Clippings add-on - https://addons.mozilla.org/en-US/firefox/addon/clippings/
This add-on creates the menu items from an init function, which is called from runtime.onStartup and runtime.onInstalled:

• onStartup is not fired, because the extension startup is not the result of the browser starting up.
• onInstalled is not fired either, because the extension was not just installed or updated.

The add-on would also not show context menus if you just disable, then re-enable the add-on.

It looks like this extension was ported from Chrome. In Chrome, the API contract is: Context menus that are registered in the onInstalled event are persisted at least until the next onInstalled event. In Firefox, this is not the case, context menus are forgotten as soon as an extension is unloaded. This difference is the actual cause of the bug that you're observing.

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

The closed tabs may be expected on a technical level, but it's still bad UX and can break an extension's onboarding experience. On our last meeting I asked whether it would be possible to show the PB notification before the extension is installed, and I don't think that possibility has been discarded.

Is there a good reason we treat onInstalled differently than Chrome?

Comment 7

[Rob Wu [:robwu]]

(In reply to Jorge Villalobos [:jorgev] from comment #6)

Is there a good reason we treat onInstalled differently than Chrome?

We don't treat onInstalled differently from Chrome:

• When an installed extension (CRX file) is reloaded in Chrome (e.g. by granting incognito access), the onInstalled event is not fired.
  When an installed extension (XPI file) is reloaded in Firefox (e.g. by allowing private browsing access), the onInstalled event is not fired either.
• When an unpacked extension is reloaded in Chrome, onInstalled is fired with reason=update.
  When a temporary extension is reloaded in Firefox, onInstalled is fired with reason=update as well.

I filed a new bug for the disappeared context menu, as bug 1567467, which covers the second issue from comment 5.

The only remaing issue (the closed extension tabs) is expected behavior from a technical POV, but we were indeed receptive to the idea of improving the onboarding experience.

Comment 8

[Andreas Wagner [:TheOne] [use NI]]

It worth noting that this also has impact on our add-on policies where add-ons collecting data are required to show a data collection consent with opt-in or opt-out choice for the user. If that data collection consent page disappears, users might not have a chance to see the data collection policy of the add-on and make a choice of whether to opt in to or opt out of the data collection.

Comment 9

[Shane Caraveo (:mixedpuppy)]

rob, the bug linked to in comment 7 is this bug.

Comment 10

[Rob Wu [:robwu]]

Thanks, I edited the comment. It should have been the one that I added in "See also".

Comment 12

[Luke Crouch [:groovecoder]]

Ping - we just hit this bug with Relay, which we definitely expect + want people to use in private browsing.

Comment 13

[Rob Wu [:robwu]]

Luke - if you want to avoid being closed, a work-around is to not use any extension API in the tab.
Due to bug 1399655, such tabs are not automatically closed when an extension unloads.

Comment 14

[Andreas Wagner [:TheOne] [use NI]]

(In reply to Rob Wu [:robwu] from comment #13)

Luke - if you want to avoid being closed, a work-around is to not use any extension API in the tab.
Due to bug 1399655, such tabs are not automatically closed when an extension unloads.

The tabs often contain controls for data collection, whose settings must be stored somewhere in the extension storage. Is there a way to achieve both?

Comment 15

[Rob Wu [:robwu]]

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #14)

(In reply to Rob Wu [:robwu] from comment #13)

Luke - if you want to avoid being closed, a work-around is to not use any extension API in the tab.
Due to bug 1399655, such tabs are not automatically closed when an extension unloads.

The tabs often contain controls for data collection, whose settings must be stored somewhere in the extension storage. Is there a way to achieve both?

If delaying the API calls until the user explicitly interacts with those controls is not sufficient, then you could try to use browser.extension.getViews({type: "tab"}) from the background page (to get a direct reference to the tab's window global), and inject an API in the page. That would break when the background page reloads, and would also break if the background page and the extension page have different origin attributes (e.g. tab is in private browsing or container tab). To minimize the risk of breakage, add a fallback to the extension page's extension namespace and you should be good.

This is a hack though, we should fix this bug to avoid the need for such hacks.

Comment 16

[Alexei]

Extension users losing the just-installed extension's welcome page is indeed bad UX and should be addressed at the browser (Firefox) level. Individual extensions shouldn't have to deal with bad gotchas like this.

Having said that, other workarounds include hosting the welcome/onboarding page on your website (not great for privacy extensions in particular!) and adding a post-installation timer to help decide whether the welcome page should be reopened.

Comment 17

[Shane Caraveo (:mixedpuppy)]

Enough addons will have a problem with onboarding due to this, we will move the private browsing permission checkbox into the permissions prompt and always show the permissions prompt.

Comment 19

[Stig Nygaard]

(In reply to Shane Caraveo (:mixedpuppy) from comment #17)

Enough addons will have a problem with onboarding due to this, we will move the private browsing permission checkbox into the permissions prompt and always show the permissions prompt.

That was last comment on this bug 1 1/2 year ago, but nothing has changed?

Comment 21

[Luca Greco [:rpl] [:luca] [:lgreco]]

Bug 1842832 moved the private browsing incognito checkbox to the initial install dialog and landed in Firefox 129, and so this should now also be fixed in Firefox 129 as a side-effect of fixing Bug 1842832 (which by moving the checkbox in the dialog opened before installing the addon it also doesn't need to reload the addon on the user making a choice about the private browsing access).

I've updated the tracking flags to reflect that this is fixed in 129, not uplifted to 128 (and so set to wontfix at the moment) and that 130 is not affected anymore.