Steps to reproduce

WebExtension with

• runtime.onInstalled listener
• chrome_settings_overrides, search_provider with is_default: true in the manifest

Actual result

When installing the WebExtension the onInstalled listener fires before the user made a choice regarding the default search_provider.

Expected result

onInstalled should fire after the default search_provider choice is made.

Notes

This is relevant if an Add-on wants to open a "welcome page" in a new active tab after install - which makes the search_provider doorhanger prompt disappear. An alternative solution might be that the doorhanger stays open even if a new tab is opened after Add-on install.

Can we get some Product guidance on where this notification should be (during the install flow? after?) which should inform its potential persistence (which is the real bug here).

... (which is the real bug here).

To clarify (to the reporter): runtime.onInstalled is fired when an extension has been installed. There is no documented relation between search provider registration and that event. That part of the bug report is invalid and we won't change the behavior of the onInstalled event.

But the remark in "Notes" section does point to a potential issue: The search provider doorhanger is automatically dismissed when the user (or extension) switches to a different tab. Consequently search provider registration requests are dismissed without user interaction.

Based on the potential issue mentioned in Comment 2, will you file a new bug regarding this? If yes, I would require to know whether we can mark the current issue as Invalid. Thanks!

It seems that the main motivation for filing this bug is in "Notes", so if we update the summary and the first comment, then this bug can be re-used to track that bug.

stoically (Reporter): We are not going to change the onInstalled event's behavior. Could you edit the first comment and the bug title to more accurately represent the issue that you are facing? Or do you prefer that we mark this bug as INVALID and file a new one?

Thanks for looking into this. If the doorhanger would stay open that would be perfectly fine. I've changed the title - but I don't think I can change the first comment, unfortunately. Feel free to edit as you see fit.

FYI: This notification is opened by https://searchfox.org/mozilla-central/rev/b38e3beb658b80e1ed03e0fdf64d225bd4a40327/browser/modules/ExtensionsUI.jsm#480
and was added by bug 1397975

Would a valid workaround be delaying code in onInstalled that opens the tab until the user has made a choice on the search engine (or, after a timeout) ?

Would be great to get this fixed if it is simple to do. Rob, can you foresee how much work this would be?

What's the desired behavior?

The current behavior is as follows (introduced in bug 1397975):

1. Find the current tab browser when the extension is installed (ref).
2. Create a doorhanger that is anchored on the icon of the tab from 1.
3. When the tab switches, the notification is removed (ref).

I can change the implementation to not automatically remove the notification from step 3. Then, when the original tab (from step 1) is focused again, the doorhanger would be shown again. This would be two days work at most (to also account for edge cases and writing unit tests).

But I am wondering whether the current implementation makes sense. The search provider request is anchored to the current tab, which at best is a tab from where the user triggered an installation. It is also realistic for that tab to be completely unrelated to the source of the add-on install.

Alternatives to persisting the doorhanger in the original tab include:

• removing doorhanger as soon as the tab is unfocused (current situation)
• showing the doorhanger at whichever is the current tab, until the user takes action (= nagging the user to make a decision)
• showing the doorhanger in the current window, not anchored to any tab (e.g. like the post-install doorhanger).

What approach should we take? Do we need UX input?

Another consequence of the current situation, as laid out by Rob Wu, is that if multiple Add-ons get synced to a new device, and one of the synced Add-ons is a search engine Add-on, it's "make default" doorhanger will disappear if another Add-on that opens a welcome page is synced after - so personally I'd agree that "showing the doorhanger at whichever is the current tab" would be a good solution.

This would be addressed by bug 1683954, leaving open as potential test case. This is otherwise relatively unimportant as the only side effect is an addon doesn't gain default search.

The severity field for this bug is set to S4. However, the following bug duplicate has higher severity:

• Bug 1640613: S3

:willdurand, could you consider increasing the severity of this bug to S3?

For more information, please visit auto_nag documentation.