Closed Bug 1162140 Opened 5 years ago Closed 5 years ago

[User Story] Allow user to select a query from search suggestions in Awesome Bar

Categories

(Firefox :: Search, defect, P1)

40 Branch
defect

Tracking

()

VERIFIED FIXED
Firefox 42
Iteration:
41.3 - Jun 29
Tracking Status
firefox40 --- affected
firefox41 --- fixed
firefox42 --- verified

People

(Reporter: kev, Assigned: mak)

References

Details

(Whiteboard: [suggestions][fxsearch])

User Story

As a user, when I select a suggested search query from the list I am presented with a results search engine results page based upon the selected query for the purposes of finding content from a search provider. (different selection states? hover, right click, middle, etc.)

Primary use case is selection for the purpose of executing a query against the default provider.

UX - STEVE is looking at first to see if we need to do the other parts.

May create a bug for Secondary use cases if needed - can include what happens on hover/right-click/middle-click, etc., but those should probably be tracked separately. Needs UX.

Attachments

(3 files, 1 obsolete file)

Allow user to select a query from a list of presented search suggestions.

Primary use case is selection for the purpose of executing a query against the default provider.

Secondary use cases can include what happens on hover/right-click/middle-click, etc., but those should probably be tracked separately.
Rank: 5
Flags: firefox-backlog+
Priority: -- → P1
Rank: 5 → 8
Summary: Allow user to select a query from search suggestions in Awesome Bar → [User Story] Allow user to select a query from search suggestions in Awesome Bar
this was #2 when prioritizing user stories for the theme "suggestions"
Rank: 8 → 5
Whiteboard: [fxsearch][searchsuggestions] → [searchsuggestions][fxsearch]
Whiteboard: [searchsuggestions][fxsearch] → [suggestions][fxsearch]
Iteration: --- → 41.1 - May 25
QA Contact: shorlander
Assignee: nobody → shorlander
User Story: (updated)
QA Contact: shorlander
Whiteboard: [suggestions][fxsearch] → [suggestions][UX][fxsearch]
Selecting a search suggest entry:

1) Type word or fragment into AwesomeBar
2) Get results from history intermixed with search suggest
3) Mouse over or arrow to desired result
4) Highlight result and append provider name to suggest; e.g. "— Yahoo! Search"
5) Select entry with mouse press or by hitting enter
6) Go to SAP

> Secondary use cases can include what happens on
> hover/right-click/middle-click, etc., but those should probably be tracked
> separately.

Onky two considerations here (that I can think of ATM):

1) Hover will append provider name
2) Ctrl/Command modifier  + Mouse, Middle-Click and Alt/Option + Enter select currently open a new tab from AwesomeBar results

Aside those I don't think we should tackle any kind of secondary behavior here right now. We can use follow-ups as needed.
Assignee: shorlander → nobody
Whiteboard: [suggestions][UX][fxsearch] → [suggestions][fxsearch]
Assignee: nobody → mak77
Iteration: 41.1 - May 25 → 41.2 - Jun 8
Hi Mak,

Have you had a chance to make progress on this bug?
Flags: needinfo?(sescalante)
I suppose the needinfo was for me :)
Just some brainstorming. On the other side, looks like bug 959594 is pretty much overlapping with this. So I will first feedback there, since I need to sync with Drew to avoid double work.

Also bug 959595 is overlapping with both, since once the result is shown there's not much to do to allow "selection" as requested here. The only thing left at that point is the presentation (append provider name when a row is selected), since we already handle middle-click/ctrl for awesomebar entries. I will look at that on Monday.
Flags: needinfo?(sescalante)
to support proper styling of these entries (that is, show Search With Engine only on the selected entry), we might need bug 1054800. I will know more after further investigation. Just annotating for now.
Blocks: 959595
Stephen I have a couple questions for you:

1 - we are currently using the string "- Search with Engine Name" in the first action row. The reasoning for not using "Engine Search" is that some engine might already include the "search" word, in such a case we'd end up with (for example) "MSN Search Search" while "Search with MSN Search" works fine. Can I retain the current "Search With" string everywhere (both the first action row and suggestion rows) or do you have alternative suggestions?

2 - In the mockup you are not showing the "Search With" on the first action row. Should I assume the rule to hide "Search With" is valid not just for suggestions but for any search-like row? (the first row is preselected on typing so the action is still clear for the user)
Flags: needinfo?(shorlander)
My other problem is that it might not be trivial to implement "autofill" as in the mock-up for selected entries, so that the whole suggestion is copied into the locationbar input field. So, I'd leave that for future if possible, it might open a can of worms.
Attached image WIP screenshot
this is what I have so far
Attached patch patch v1Splinter Review
Drew, you can apply this before your patch to get proper styling.
The only thing to do for adding search suggestions is invoking _addSearchEngineMatch like
this._addSearchEngineMatch(match, this._originalSearchString, suggestion);
where match should be built by PlacesSearchAutocompleteProvider.jsm
Attachment #8617923 - Flags: feedback?(adw)
(In reply to Marco Bonardo [::mak] from comment #7)
> Stephen I have a couple questions for you:
> 
> 1 - we are currently using the string "- Search with Engine Name" in the
> first action row. The reasoning for not using "Engine Search" is that some
> engine might already include the "search" word, in such a case we'd end up
> with (for example) "MSN Search Search" while "Search with MSN Search" works
> fine. Can I retain the current "Search With" string everywhere (both the
> first action row and suggestion rows) or do you have alternative suggestions?

That makes sense. I am ok with using "— Search with <Engine Name>" everywhere. 

Although I don't think <Engine Search> would be too terrible since it seems that search engine names that end with search are not that common.

> 2 - In the mockup you are not showing the "Search With" on the first action
> row. Should I assume the rule to hide "Search With" is valid not just for
> suggestions but for any search-like row? (the first row is preselected on
> typing so the action is still clear for the user)

Yes. The magnifying glass is the "hey this is a search" indicator, and we would only add the action text to the item that is currently highlighted/selected.
Flags: needinfo?(shorlander)
Comment on attachment 8617923 [details] [diff] [review]
patch v1

Review of attachment 8617923 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me.
Attachment #8617923 - Flags: feedback?(adw) → feedback+
Blocks: 959594
Comment on attachment 8617923 [details] [diff] [review]
patch v1

ok, now that I got Stephen's feedback let's make this a proper review.
Attachment #8617923 - Flags: review?(adw)
Iteration: 41.2 - Jun 8 → 41.3 - Jun 29
Comment on attachment 8617923 [details] [diff] [review]
patch v1

Review of attachment 8617923 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me.  (Nothing to add to my previous f+.)
Attachment #8617923 - Flags: review?(adw) → review+
https://hg.mozilla.org/mozilla-central/rev/e420871145cb
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
QA Contact: petruta.rasa
Flags: qe-verify+
Depends on: 1176107
Depends on: 1176441
No longer blocks: 959594, 959595
Depends on: 959594, 959595
Depends on: 1178788
No longer depends on: 1178788
Some of the issues (such as no suggestions when there are too many history items; pages deleted from history are still visible in awesome bar etc) initially found while verifying this bug are no longer reproducible on latest Nightly.

One issue (maybe) that still reproduces is:
- without entering anything in location bar, press the Down arrow key and then Enter -> the default search engine page is opened
- Press Down arrow again -> there are 2 options in the drop down, both covering the same link: "Visit <<link>>" and "Search - switch to tab"

Should I fill this? Thanks!

I'm marking this bug as verified on Nightly 42.0a1 as it was disabled on 41.0a2 Dev Edition. Will file a follow if needed.
Status: RESOLVED → VERIFIED
Target Milestone: Firefox 41 → Firefox 42
(In reply to Petruta Rasa [QA] [:petruta] from comment #19)
> One issue (maybe) that still reproduces is:
> - without entering anything in location bar, press the Down arrow key and
> then Enter -> the default search engine page is opened

bug 1176437?
But the option doesn't do anything for me, it doesn't open the default search engine. Which OS was this on?

> - Press Down arrow again -> there are 2 options in the drop down, both
> covering the same link: "Visit <<link>>" and "Search - switch to tab"

Is the locationbar still empty? I cannot reproduce this. Likely cause I cannot reproduce opening the default search engine page at the first step? I'm interested in understanding why "switch to tab" appears, since it should never appear for an empty location bar.
Were all the options in Privacy / Locationbar at the default value? Was History enabled there?
Reproduced under OS X 10.9.5 and Win 7 64-bit using new profiles.

In previous build pressing once Down arrow was enough, now I see that it must be pressed twice to select the magnifying glass "Search with" first row.

The Visit link and "switch to tab" appear when pressing twice the Down arrow key, while on the same page (the location bar is not empty)

Maybe bug 1176437 will fix this too.
(In reply to Petruta Rasa [QA] [:petruta] from comment #21)
> Reproduced under OS X 10.9.5 and Win 7 64-bit using new profiles.
> 
> In previous build pressing once Down arrow was enough, now I see that it
> must be pressed twice to select the magnifying glass "Search with" first row.

This is wrong, if something regressed it we need to figure what. I cannot reproduce on Windows.
I open a new tab (this also focuses the locationbar) and press DOWN, the first entry (bogus) is selected, enter does nothing.

> The Visit link and "switch to tab" appear when pressing twice the Down arrow
> key, while on the same page (the location bar is not empty)

Ah yes, this is bug 555694, it was there already.
(In reply to Marco Bonardo [::mak] from comment #22)
> This is wrong, if something regressed it we need to figure what. I cannot
> reproduce on Windows.
> I open a new tab (this also focuses the locationbar) and press DOWN, the
> first entry (bogus) is selected, enter does nothing.

Could you please try no navigate between the dropdown items and press Enter only when the first row is selected and the magnifying glass is shown on location bar (http://i.imgur.com/xWFBWbV.png)

> > The Visit link and "switch to tab" appear when pressing twice the Down arrow
> > key, while on the same page (the location bar is not empty)
> 
> Ah yes, this is bug 555694, it was there already.

No we have the same link twice: http://i.imgur.com/XwIuDZB.png
(In reply to Petruta Rasa [QA] [:petruta] (PTO until 3rd August) from comment #23)
> Could you please try no navigate between the dropdown items and press Enter
> only when the first row is selected and the magnifying glass is shown on
> location bar (http://i.imgur.com/xWFBWbV.png)

I see, I think bug 1176437 will solve this.
 
> > > The Visit link and "switch to tab" appear when pressing twice the Down arrow
> > > key, while on the same page (the location bar is not empty)
> > 
> > Ah yes, this is bug 555694, it was there already.
> 
> No we have the same link twice: http://i.imgur.com/XwIuDZB.png

Yes, the switch to tab entry should not appear (bug 555694), the visit entry is expected.

Thank you for verifying this.
This is disabled in Firefox 41 so I'm removing the qe-verify+ flag.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.