NTP websearch string is handedoff to the search mod enabled address bar
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
People
(Reporter: aflorinescu, Unassigned)
Details
(Keywords: blocked-ux)
Affected versions
- Nightly 102
- Beta 101.0b2
- Release 100
- 91.9.0esr
Affected platforms
- Windows 10
- Ubuntu 22.04
- Mac 11
Steps to reproduce
- Open new profile.
- From address bar, select any search mode (non-default) : e.g amazon.
- While the search mode is enabled, use the NTP websearch to input a string.
Expected result
Search mode is reset and input string is handed off to the address bar.
Actual result
The input string is handed over to the address bar to be used with the search mode enabled.
Regression range
Not a regression (introduced by defaulting browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to true)
Note
The web search label reads: "Search with google or input address". If the STR would read that the string input is a https://address_input.com, the result would be that we would search with amazon for https://address_input.com
Updated•3 years ago
|
Comment 1•3 years ago
•
|
||
Just to clarify, I reproduced the steps you mentioned and set Amazon as the search mode and then used New Tab Page search to input a string, Amazon wasn't cleared from the address bar and the search mode was not reset.
However, we're expecting search mode to be reset and Amazon to be cleared, correct? It does seems strange to have the search box on the new tab page say one thing but then operate differently.
Added blocked-ux
tag just because it'd be good to confirm with UX that clearing the search mode is the best solution here.
Reporter | ||
Comment 2•3 years ago
|
||
(In reply to James Teow [:jteow] from comment #1)
However, we're expecting search mode to be reset and Amazon to be cleared, correct? It does seems strange to have the search box on the new tab page say one thing but then operate differently.
Added
blocked-ux
tag just because it'd be good to confirm with UX that clearing the search mode is the best solution here.
Great, guessing UX should be involved here. Taking the Description Expected Result with a grain of salt should be the right approach while we figure out what the best expected should be. The scenario signaled here is a case that we didn't consider when we defaulted browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to true.
Description
•