Closed Bug 1400182 Opened 7 years ago Closed 3 years ago

The first searched keywords are not redisplayed when clicking the "Back" button after a search was performed

Categories

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

defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox57 --- wontfix
firefox58 --- wontfix

People

(Reporter: mcoman, Unassigned)

References

Details

Attachments

(1 file)

Attached image new tab search.gif
[Notes]
- The issue is not reproducible on "about:home" page.
- The issue is reproducible on every New Tab.
- If a second search is performed, when clicking back to the New Tab page, the previous searched keyword is redisplayed.

[Affected versions]
- Nightly 57.0a1 Build ID 20170914100122

[Affected Platforms]
- All Windows
- All Mac
- All Linux

[Steps to reproduce]
1. Open the latest Nightly and go to New Tab page.
2. Write a keyword in the "Search Bar" and press enter.
3. Click the "back" button and observe the "Search Bar" from the New Tab page.

[Expected result]
- The previous searched keyword is redisplayed.

[Actual result]
- The search bar is empty.

[Additional Notes]
- Attached a screen recording of the issue
Component: Activity Streams: Newtab → New Tab Page

With Proton having browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar true as default, don't think this scenario would apply. I still cannot reproduce either with setting browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false.
Mac11/91.0a1 20210701211644

mak:, can you think of any case in which query search term from the in-page search box should be populated after pressing back?

Flags: needinfo?(mak)

We discussed multiple times about which approach to take to allow the user repeat the same query. So far the only implemented thing is search history and some reverse parsing. It would be interesting to study how much this case is useful and used in reality.
I'd expect that going back after executing a search in most cases means the search didn't bring the expected results, thus settings back the old search may or may not be expected. Without clear data showing the advantage of one approach I think for now we can close this as invalid because the behavior changed too much from when it was filed, and it's definitely invalid for the new tab page.

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(mak)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.