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

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!

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

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!

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.

(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.

This is fixed in the update-2 redesign.