Closed Bug 1552463 Opened 2 years ago Closed 4 months ago

Searching from newtab activity stream with handoff to awesomebar does not show one-click search engines.

Categories

(Firefox :: New Tab Page, defect, P3)

67 Branch
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- wontfix
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- wontfix
firefox69 --- fix-optional
firefox70 --- fix-optional

People

(Reporter: ke5trel, Unassigned)

References

(Blocks 2 open bugs, Regression)

Details

(Keywords: regression, ux-consistency)

Attachments

(1 file)

STR:

  1. Set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar = true and/or browser.privatebrowsing.searchUI = true.
  2. Go to about:newtab or a private new tab and type into the search box.
  3. Try to select a different search engine.

Searching from activity stream prepends the search term with @<default engine> which effectively locks-in that engine and does not show one-click search icons like it did before. The only way to change search engine is to remove the @ term at the beginning which is very clumsy. This is a regression and UX inconsistency, there is no apparent reason why initiating search from activity stream should make it more difficult to use a non-default search engine.

While other browsers are making it easier to use a different search engine in private windows (Vivaldi, Brave) (Bug 1411340), Firefox is making it harder.

FWIW, this is intended behavior when entering an @ alias, but I'm not sure why such an alias is used in the first place here. Since the search field uses the default engine, ? could be used instead.

not a recent regression and we are shipping 67 next week, wontfix 67.

Mikes, could you folks weigh in on what you would expect the user flow to be here

Flags: needinfo?(mverdi)
Flags: needinfo?(mconnor)

Marking this as a P3 (backlog) until we hear back from Mconnor/mverdi the importance of fixing this bug. Then we'll re-assess. Thanks!

Priority: -- → P3
Component: Activity Streams: Newtab → New Tab Page

Marking disabled for 68. Per mconnor: "Behaviour is nightly only, and Verdi is thinking about how we should proceed."

Blocks: 1501747
No longer regressed by: 1501747

The search hand-off has been in release since 66 for private windows which I reflected in tracking flags, consequently it is not completely disabled in 68 so I think wontfix is more accurate.

Rares can you help find someone from QA to test if this still happens in non-nightly versions? Thanks!

Flags: needinfo?(rares.doghi)

I tested this issue on Windows 10, Mac OS X 10.14 and Ubuntu 18.04 and I have different results:

On Windows 10 x64 FF Beta 69.0b13 and FF release 68.0.1 the behaviour from the description it doesn't happen, Is the same behaviour as in Nightly 70.0a1(2019-08-14).

On Mac OS X 10.14 and Ubuntu 18.04, FF Beta 69.0b13 and FF release 68.0.1 the behaviour from the description is still reproducible. On Nightly 70.0a1(2019-08-14) it doesn't reproduce.

So to sum up, the issue is still happening on non-nightly versions on Mac and Ubuntu OSes but not on Windows.

Flags: needinfo?(rares.doghi)

(In reply to Patricia Lawless from comment #5)

Marking disabled for 68. Per mconnor: "Behaviour is nightly only, and Verdi is thinking about how we should proceed."

Any reason why we don't just use '?' instead of '@' as suggested earlier?

(In reply to Dão Gottwald [::dao] from comment #1)

FWIW, this is intended behavior when entering an @ alias, but I'm not sure why such an alias is used in the first place here. Since the search field uses the default engine, ? could be used instead.

Happy to take a patch for 70 or beyond.
Since we are getting close to the end of the 69 beta cycle and this is set to P3, I'm marking it fix-optional for 69 and 70 to remove it from weekly triage.

Blocks bug 1344931.

Depends on: 1616700
No longer blocks: pocket-newtab
See Also: → 1645293

This is fixed in the update-2 redesign.

Flags: needinfo?(mverdi)
Flags: needinfo?(mconnor)
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.