[User Story] Search Suggestions in the AwesomeBar should be clearly identified as such

RESOLVED FIXED in Firefox 41

Status

()

Firefox
Search
P1
normal
Rank:
8
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: kev, Assigned: adw)

Tracking

(Blocks: 1 bug)

40 Branch
Firefox 41
Points:
---
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(firefox40 affected, firefox41 fixed)

Details

(Whiteboard: [suggestions][UX][fxsearch])

User Story

As a user, I will be able to differentiate suggested searches from other content types presented in the AwesomeBar dropdown to help me differentiate suggested searches and to understand why they are appearing from other list entries such as URIs or other content.

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
Ensure search suggestions presented in the AwesomeBar drop-down list can be clearly identified as a suggest, for the purpose of helping users understand that selecting a suggestion will result in a search being performed.

Updated

3 years ago
Rank: 5
Flags: firefox-backlog+
Priority: -- → P1

Updated

3 years ago
Summary: Search Suggestions in the AwesomeBar should be clearly identified as such → [User Story] Search Suggestions in the AwesomeBar should be clearly identified as such

Comment 1

3 years ago
this bug relates to user story 3 here https://docs.google.com/document/d/1de2o8Osl_z98BBfkt243i-dHdcKmQB15xJ9rShkwk3Q/edit... which was the last part of initial talk for v1 minimum.
Rank: 5 → 8

Updated

3 years ago
Whiteboard: [fxsearch][searchsuggestions] → [suggestions][fxsearch]

Comment 2

3 years ago
initial work is done, but we should have enough to start and take what crops up as it does.  STeve - attach info
Flags: needinfo?(shorlander)
Whiteboard: [suggestions][fxsearch] → [suggestions][UX][fxsearch]

Updated

3 years ago
Assignee: nobody → shorlander
Iteration: --- → 41.2 - Jun 8
Created attachment 8614678 [details]
AwesomeBar Search Indicator — 01

When performing a search from the AwesomeBar the Search Indicator Icon (Magnifying Glass) appears next to the search suggest entry and in the AwesomeBar field.

A search action label "— Search <Provider Name>" appears next to the entry when it is highlighted or hovered.
Flags: needinfo?(shorlander)

Updated

3 years ago
Iteration: 41.2 - Jun 8 → 41.3 - Jun 29

Comment 4

3 years ago
Hi Drew - for priority this is after the "opt-in/opt-out" - but looks like the UX is ready to go if Bug 959565 is blocked for UX.  I just need info'd Steve to ask about the UX for that other bug.
Assignee: shorlander → nobody
Flags: needinfo?(adw)
(Assignee)

Comment 5

3 years ago
(In reply to Stephen Horlander [:shorlander] from comment #3)
> When performing a search from the AwesomeBar the Search Indicator Icon
> (Magnifying Glass) appears next to the search suggest entry

We do this already...

> and in the AwesomeBar field.

... but not this.

> A search action label "— Search <Provider Name>" appears next to the entry
> when it is highlighted or hovered.

We do this already too.

So the only thing to do in this bug is to show the magnifying glass in the awesomebar.
Assignee: nobody → adw
Status: NEW → ASSIGNED
Flags: needinfo?(adw)
(Assignee)

Comment 6

3 years ago
Created attachment 8626004 [details] [diff] [review]
patch

This seems to work...  The selectors and values are based on those for the identity-box in each theme's CSS.
Attachment #8626004 - Flags: review?(mak77)
so, why don't we just put the icon in identity-box and switch it with page-proxy-favicon, instead of copying over all the code? regardless, afaict, when using autocomplete we always use the generic icon there, the risk should be low.
(Assignee)

Comment 8

3 years ago
Created attachment 8626404 [details] [diff] [review]
patch v2

This actually uses page-proxy-favicon itself and switches its image.
Attachment #8626404 - Flags: review?(mak77)
Comment on attachment 8626404 [details] [diff] [review]
patch v2

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

This is definitely simpler and less likely to break.

::: browser/themes/osx/browser.css
@@ +1809,5 @@
>    }
>  }
>  
> +#urlbar[actiontype="searchengine"] > #identity-box > #page-proxy-favicon {
> +  -moz-image-region: inherit;

it looks to me the osx theme is only overriding -moz-image-region from identity-block.inc.css, do we really need to set everything rather than just that?
Attachment #8626404 - Flags: review?(mak77) → review+
(Assignee)

Comment 10

3 years ago
https://hg.mozilla.org/integration/fx-team/rev/bfa8b42bd280

You're right, I removed the OS X-specific CSS and it still worked, so the final patch only modifies identity-block.inc.css, nice.
(Assignee)

Updated

3 years ago
Attachment #8626004 - Attachment is obsolete: true
Attachment #8626004 - Flags: review?(mak77)
https://hg.mozilla.org/mozilla-central/rev/bfa8b42bd280
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox41: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
You need to log in before you can comment on or make changes to this bug.