1443843 - Installing a search engine extension results in a double-panel

Status: NEW

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

Description

[Markus Jaritz [:designakt] (UX)]

Attachment: double-dialog.png

Way to reproduce:

- go to startpage.com
- click "add to Firefox"
- allow install
- accept permissions
- see install confirmation and a second panel asking to confirm changing the default search engine at the same time, attached to each other.

observed on todays nightly on macOS.

Comment 1

[Markus Jaritz [:designakt] (UX)]

Attachment: NewTabOverride.png

expected result

- see install confirmation
- see search engine change message on first search
(as we do with new Tab and Homepage override)
(see attachment)

This message would should up when someone triggers their first search with the new engine. It would be anchored to the extensions icon in the toolbar, and if there is no icon, to the firefox menu.

Comment 2

[Andrew Swan [:aswan]]

cc mkaply.  I asked him about this before and he said it was expected.
Markus, what is the behavior you expect to see instead?

Comment 3

[Mike Kaply [:mkaply]]

We've decided not to go with a Chrome style method and require explicit opt-in for additional search engines.

I know the double panel is not optimal, but we haven't come up with another good solution (yet).

We could have put the search engine into the permissions dialog as well, but we wanted to allow the extension to be installed even if the user didn't want the search engine.

I'm open to other suggestions. But anything that installs the search engine without the user consenting is off the table.

Comment 4

[Markus Jaritz [:designakt] (UX)]

With the concerns I see, we should combine existing options in the most protective way:
(like we do with Tab hiding)

So instead of introducing this new way to ask for a permisson, we should enable search to be an optional permission, so the extension can request it when they want, after install, for extensions that have search as an optional addition. And allow for it to be requested as general permission too, so extensions that have it as core functionality, can get permission right on install.
And to ensure full user control and awareness, we might follow that up with a dialog on first use - that has users confirm that this results page is what they want to see.
(see flow for tab hiding as example: https://mozilla.invisionapp.com/share/KXEUSPHHN )

And to ensure users ca get rid of this changed search we should also surface the search override in preferences, next to the default search engine setting.
(this would look similar to what one sees when installing Momentum or Tabby Cat)


More context: We have built out a set of ui options on how to surface any given permission to users. With those we should be able to cover all cases, from very serious to just information. Adding another option to that set is the last thing we should do, unless we have a very good reason for it, that can't be covered with any of the existing ones... as it introduces more complexity, for people using it, and for developers implementing and maintaining it.

The current options are:

- show permission on install (general permission) - extension does not work without it
- ask for permission on first time use (optional permission) - extension works fine without it
- don't show permission on install (other permission - permissions we decided are not relevant to surface

and any of those can be combined with:

- a notice on first use of that feature (e.g. newTab, Home, tab hiding) - for users to experience the change
- a permanent notice in preference, if a preference is affected (newTab, Home, TP...) - for users to easily revert

(Adding Mike as this might be relevant to our chat about building a framework for when to use what kind of permission UI.)

Comment 5

[Mike Kaply [:mkaply]]

Our concern with using a default permission was that this particular permission would get lost in a sea of other permissions. Especially if an add-on deliberately added multiple permissions to cause the search permission to fall off.

And we wanted the permission to be explicit: "This add-ons wants to change your search engine from A to B"

We also didn't want to encourage the user to choose one way or the other (you'll notice that neither button has a highlight in the search case).

Some other thoughts I had were to move the doorhanger away from being a page doorhanger and associating it with the add-on icon. This would be an issue of the add-on didn't have an icon.

Comment 6

[Andrew Swan [:aswan]]

Mike, what's hte plan here?

Comment 7

[Mike Kaply [:mkaply]]

Leaving the needinfo for mconca to chime in, but here's my recollection based on a meeting we had.

I think the direction was to create a "setDefault" API instead of using the manifest.

The API could be called once and it would use UI similar to the optional permissions dialog.

This would actually solve a lot of other issues we're running into with this confirmation as well.

I'm currently working on a search query API as part of bug 1352598 - this would end up as part of that work.

So two parts:

1. build the WebExtension API
2. Modify the optional permissions API to work for this search cases, showing the search popup as it exists but only allowing it to ask the question once.

Comment 8

[Mike Conca [:mconca]]

It looks like progress is being made on bug 1352598. It isn't clear to me what part of this bug will be handled there, and what would remain to be done in this bug. Mike, would you mind providing a quick update?  Thanks.

Comment 9

[Mike Kaply [:mkaply]]

Sure. I'm trying to get through that search bug but keep getting sidetracked. Once that bug is done, I'll extend the API to include the new search optional API.

Comment 11

[Tomislav Jovanovic :zombie]

Hey Mark, did we remove support for open search, and is this bug now invalid/wontfix?

Comment 12

[Mike Kaply [:mkaply]]

This isn't opensearch, this is search in webextensions, and this bug still exists.