Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Use the extension's icon instead of the default extension icon for custom suggestions

NEW
Unassigned

Status

()

Toolkit
WebExtensions: Frontend
P2
normal
4 months ago
2 months ago

People

(Reporter: mattw, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [omnibox], triaged)

Attachments

(2 attachments)

(Reporter)

Description

4 months ago
The default extension icon does not tell the user which extension the custom suggestions are coming from.
(Reporter)

Updated

4 months ago
webextensions: --- → ?

Updated

4 months ago
webextensions: ? → ---
Whiteboard: [omnibox]

Comment 1

4 months ago
It was actually done on purpose I think?
Isn't the name of the extension already shown in the locationbar itself?
Allowing for an icon sounds like may expose security concerns, where an add-on could show a lock icon on urls making them look secure while they are not?
The plan was to show the name of the add-on in the input field, and a generic add-on icon in the popup, afaik.

Comment 2

3 months ago
what do we want to do here?
Flags: needinfo?(mjaritz)
(Reporter)

Comment 3

3 months ago
(In reply to Marco Bonardo [::mak] from comment #1)
> It was actually done on purpose I think?
I believe we initially decided to hold off on doing this because of bug 1309047, but I'm not sure if we should still have it block this.

> Isn't the name of the extension already shown in the locationbar itself?
Currently "Extension: " is displayed in the awesomebar, so there is no way to know which extension the suggestions are coming from. Bug 1323077 is meant to track using the extension's name instead.

> Allowing for an icon sounds like may expose security concerns, where an
> add-on could show a lock icon on urls making them look secure while they are
> not?
> The plan was to show the name of the add-on in the input field, and a
> generic add-on icon in the popup, afaik.
That's a good point, but the user has to first install the extension and then type in the unique keyword it registered for the extension to be able to add suggestions to the awesomebar, I don't know if we should not do it because of that. It's worth noting that Chrome uses the extension's icon for the results and uses the extension name instead of "Extension: " in the locationbar.
Do you have an extension for me with which I can experience the current implementation?
Flags: needinfo?(mwein)
(Reporter)

Comment 5

3 months ago
Sure, https://github.com/mdn/webextensions-examples/tree/master/firefox-code-search should be a good example for testing this. The keyword it registers is "cs".
Flags: needinfo?(mwein)
Created attachment 8857913 [details]
omnibox_custom_suggestion.gif

This whole feature requires a closer look before I can give a direction on details. This features hasn't gotten a lot of UX attention, but if popular it should.

Looking at it's function it seams to be very similar to keywords for search engines, but works completely different. And if it is similar, extensions using it should probably also show up in the list of search engines. Following this we should show the icon, and should align functionality with search keywords.

One concern though is that people wouldn't be aware that this is an extension. A concern that could be eliminated if people have an easy way to remove it if they do not like it. (currently that is only possible by knowing it is an extensions and going to about:addons to remove/disable that extension.) - For search engines this is easier, as there is a cog linking directly to search in about:preferences
Flags: needinfo?(mjaritz)

Updated

3 months ago
Whiteboard: [omnibox] → [omnibox], triaged
Created attachment 8875424 [details]
Screen Shot 2017-06-07 at 12.45.21 PM.png

> A concern that could be eliminated if people have an easy way to remove it if they do not like it.

FYI, Chrome requires extensions that simply provide this kind of search integration to show a browser action button.  I think this limits the "hidden extension" issue and allows people options to deal with it.  

As you can see you can uninstall "Remove from Chrome..." or hide the icon "Hide in Chrome menu" which prevents it from taking up useless toolbar space.

Here's an example you can try out in Chrome: https://chrome.google.com/webstore/detail/mdn-code-search/nifjgldbgogopimfdfclafkhbadkjfca/related


And the same experience in Firefox: https://addons.mozilla.org/en-US/firefox/addon/mdn-search/
You need to log in before you can comment on or make changes to this bug.