1480503 - Create API for setting text (keyword) in and focusing on the awesomebar

Status: RESOLVED FIXED

(Firefox :: New Tab Page, enhancement, P1)

Description

[Kate Hudson :k88hudson]

In order to implement Top Site Search Shortcuts we need an API that will set some text in and focus on the awesomebar.

Specifically, the usecase is clicking on a Search Shortcut tile and adding @google or @amazon to the awesomebar.

There are some additional considerations here:
- We should avoid showing the search suggestion hint if possible (i.e. "Tip: Look for the [magnifying glass] next to search suggestions.)
- We may want to hide the one-off buttons?

Comment 1

[Justin Dolske [:Dolske]]

Needs implemented by the fxsearch team, not AS.

Comment 2

[Ed Lee :Mardak]

Attachment: prototype amazon top search

This is what I did for my very quick prototype (video attached):

```diff
diff --git a/browser/components/newtab/lib/PlacesFeed.jsm b/browser/components/newtab/lib/PlacesFeed.jsm
--- a/browser/components/newtab/lib/PlacesFeed.jsm
+++ b/browser/components/newtab/lib/PlacesFeed.jsm
@@ -318,3 +318,9 @@ class PlacesFeed {
       case at.OPEN_LINK: {
-        this.openLink(action);
+        //this.openLink(action);
+        const {document, gURLBar} = action._target.browser.ownerGlobal;
+        gURLBar.focus();
+        gURLBar.value = "@amazon ";
+        const event = document.createEvent("Events");
+        event.initEvent("input", true, true);
+        gURLBar.dispatchEvent(event);
         break;
```

I pinned an amazon tile and set a custom image then clicked the top site.

Comment 3

[Ed Lee :Mardak]

Where I would guess the API would be a new method on gURLBar.search("@amazon ") ? Not sure if we want to make it specifically for keyworded search engines (potentially to be reused if we decide to do search typing handoff)

Comment 4

[Drew Willcoxon :adw]

(In reply to Ed Lee :Mardak from comment #3)
> Where I would guess the API would be a new method on gURLBar.search("@amazon
> ") ?

Yeah, that's what I figured too.

> Not sure if we want to make it specifically for keyworded search
> engines (potentially to be reused if we decide to do search typing handoff)

Not sure either, but my feeling is we probably shouldn't err on the side of over-generalizing this right now.

Comment 5

[Marco Bonardo [:mak]]

(In reply to Kate Hudson :k88hudson from comment #0)
> - We should avoid showing the search suggestion hint if possible (i.e. "Tip:
> Look for the [magnifying glass] next to search suggestions.)

This only appears in new profiles for the first 3-4 times the address bar is used, and has 2 main scopes:
1. Allow users to understand they can use the address bar to search
2. Clarify the address bar provides search suggestions and provide a quick escape way for privacy reasons (currently represented by the Change Settings link.

I'm not sure it's a good idea to prevent it, for the privacy implications in the second point.
The first point would still be ok if we prevent showing it but don't decrease the counter (it will just be shown later).

Imo, in the long term it would be better to implement something like bug 782557, where we don't actually need to define search keywords, but rather activate the feature when the user types part of the partner origin and confirms with a key (a placeholder text can suggest the key).
We could reuse resultDomain for that, an engine having a resultDomain defined would activate this, others wouldn't.
Then this would naturally work by activating that functionality without the need to confirm it.
The main problem there is bug 1437524, where we have a vocal minority pushing to keep tab moving through items, and the accessiblity group willing it to move to one-offs (though, the accessibility problem would be solved by the new UX mock-up where one-offs move at the top and are accessible pressing UP from the top preselected result). Anyway, we could just use a different key.
By using resultDomain, we'd leave the keyword as user-defined, rather than overriding it with our value.

Comment 6

[Drew Willcoxon :adw]

Attachment: Bug 1480503 - Create API for setting text (keyword) in and focusing on the awesomebar. r?mak

Comment 7

[Drew Willcoxon :adw]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=1be0eb2de259a64855821163f6ea91c55c26dd59

Comment 8

[Drew Willcoxon :adw]

The browser_urlbar_keyed_search.js and browser_urlbar_search.js failures on that try push should be fixed now.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9d267b4bd268
Create API for setting text (keyword) in and focusing on the awesomebar. r=mak

Comment 10

[Marco Bonardo [:mak]]

Comment on attachment 8998374 [details]
Bug 1480503 - Create API for setting text (keyword) in and focusing on the awesomebar. r?mak

Marco Bonardo [::mak] (Away 9-26 Aug) has approved the revision.

Comment 11

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/9d267b4bd268

Comment 12

[Ed Lee :Mardak]

https://hg.mozilla.org/releases/mozilla-beta/rev/534420d993a5494bbc31cb8687928fff3f444fe9