STR:

1. Launch Firefox
2. Start to install an add-on that has a search engine defined and sets the engine as default (e.g. Ecosia).
3. Accept the initial prompt to install.
4. Accept the prompt to set the engine as default.
5. On the add-on installed prompt, tick the box for "Run in Private Windows" and accept the prompt.

Actual Results

The prompt to set the engine as default is re-displayed.

I'm not quite sure what the expected behaviour should be here, I would guess that ideally the prompts would not display twice.

Hello,

Ran a bisection and narrowed the regression range between 2021-03-29 (good build) and 2021-03-30 (bad build) before Mozregression could not find any more data to bisect and stopped.

Running a second bisection between the above dates ended in the same manner – Mozregression stopped because it could not find enough data to bisect.

The pushlog from the first run is here: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a1de64fd7866144bf60fc434189e1fbfb18c3bbf&tochange=eed530931ca05b277c29539784ac24dea224f368 . In case it can help point to the regression.

Most likely related to this which is in the regression range.

Can the search team investigate further?

Sorry for the delay.

I think given the changes in bug 1646338, we're doing what is expected here - enabling the add-on in private mode seems to effectively uninstall and re-install the add-on. Hence, we are re-prompting because that's all ext-chrome-settings-overrides sees that's happening.

I think the only way around this would be for the add-on manager to either handle enabling private mode differently, or provide some sort of indication in the notifications that the add-on is being disabled to enable private mode.

Is that something the add-on manager would be willing to support (or maybe it does already?)

When setting private access, the addon is disabled and enabled, and bug 1646338 seems to specifically reprompt in that situation. Disable/enable is necessary to reset a bunch of internal stuff. We may be able to bypass that in some circumstances but it would take some investigation.

Yes, we decided to be explicit and ask the user again in the disable -> enable situation.

So we would either need to bypass or have some way of remembering in the disable -> enable situation.