1747531 - Dedicated search bar - cant go back in history

Status: NEW

(Firefox :: Search, defect, P3)

Description

[Marek]

Attachment: FF95.gif

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Suppose we search for the word "firefox", enter. The search bar will continue to show "firefox". Replace with "test", enter. Back in the search bar, ctrl+z (or ctrl+shift+z) doesn't go back to the word firefox. Only the current phrase seems to be available. Previously, you could freely go back in the search history.
The last version in which it worked was FF v93.

Discussion: https://support.mozilla.org/pl/questions/1362117

Actual results:

Only last search phrase is available

Expected results:

It should be possible to go back in the search to previous phrases.

Comment 1

[Marek]

Attachment: FF92 search history is available

How it works in Firefox 92.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Navigation' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Estanislao Larriera]

Hi Marek,

I tested this on latest Release version 95.0, on Beta 96.0 and on Nightly 97.0.a1 and couldn´t reproduce it.

Please, re-test this on Nightly with a clean profile (you can download it from here: nightly.mozilla.org) and let us know if you can still reproduce it.

Thanks,

Estanislao

Comment 4

[Marek]

I did a clean installation of Ubuntu on VirtualBox. The problem occurs all the time regardless of the system.

Comment 5

[Marek]

Attachment: No history on Ubuntu either

Comment 6

[Cristian Baica [:cbaica], Release Desktop QA]

Hello Marek,

I've also looked into the issue and managed to successfully reproduce it using the latest nightly, beta and release on Windows 10, using the steps you provided. My suspicion is that it occurs on all OSs, not just Windows.

I've also looked into the regression which points to: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4f7e9fe53b44e13edc2813523abefcb0b75e01f0&tochange=9237deee110beeaa7605195528a273b2bbc77352

@Mak could you please have a look at this? Bug 350079 seems to be the cause of the regression.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 350079

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

The change is actually caused on purpose by Bug 350079. On Enter the undo stack is cleared, because on multiple ESC we'd like to go back to the latest confirmed search, similarly to how the urlbar is behaving. That causes us to lose ctrl+z going back forever, because we clear the stack at specific points.

Though, when you open the search field, by either using CTRL+K or clicking on it, you should see the list of all the previous confirmed searches, and pressing down you can recall them into the field itself. This alternative is more visual and less likely to produce unexpected values.

While I understand the new behavior may affect some specific workflows, I think the available workaround is the intended way to reach previously executed searches. We are aligning more on the urlbar behavior related to ESC, while removing a less discoverable behavior that has a better supported workaround.
Thus my suggestion would be a wontfix, unless there's a common case not covered by search history.
Mark, wdyt?

Comment 10

[Other Realm]

I don't understand why you would want to clear the stack? A big reason I used the search bar instead of the URL bar is because it retained a list of past search terms. Doing Ctrl-Z on the search box should be entirely different from doing it on the URL bar, the way it is on a webpage. Doing ctrl-z on different text areas on a page results in independent storage of the history of what you typed. I see no reason this should not be the case for the search box. Why does pressing ESC clear the history of what you typed? I can see some reasoning for it to go back to the lasts actual search, but why not have that return to the last search be pushed into the undo stack instead of clearing things? Pressing Ctrl-Z in the URL bar goes back in browsing history indefinitely because ctrl-z is the history of past urls; pressing Ctrl-Z on the Search Box should retain the past search terms instead of doing nothing.

Comment 11

[Asif Youssuff]

(In reply to Marco Bonardo [:mak] from comment #9)

Though, when you open the search field, by either using CTRL+K or clicking on it, you should see the list of all the previous confirmed searches, and pressing down you can recall them into the field itself. This alternative is more visual and less likely to produce unexpected values.

If this is the expected behavior, it doesn't work for me (Firefox on Linux). Doing Ctrl-k or clicking the field merely focuses the input. It is hard to judge whether expected behavior is a decent workaround for the previous behavior, since the workaround isn't working for me.

Comment 12

[Other Realm]

(In reply to Asif Youssuff from comment #11)
If this is the expected behavior, it doesn't work for me (Firefox on Linux). Doing Ctrl-k or clicking the field merely focuses the input. It is hard to judge whether expected behavior is a decent workaround for the previous behavior, since the workaround isn't working for me.

Yes same on my Windows 10 Firefox 97.0b4, although I can a list of previous searches by pressing the down arrow when there is no text in the search box, the list is not ordered chronologically (appears to be fairly random). Please explain why the Search bar has anything to do with the URL bar (given, you can do searches in both of them, but Ctrl-Z should be local to the textbox and not have much to do with what the textbox is for.) Thanks

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Other Realm from comment #12)

Yes same on my Windows 10 Firefox 97.0b4, although I can a list of previous searches by pressing the down arrow when there is no text in the search box, the list is not ordered chronologically (appears to be fairly random).

I'm not sure why I was seeing the panel open before, you're right that pressing down is necessary.
I checked the code, the order is indeed not chronological, it's instead based on a ranking similar to the urlbar one (based on usage and recent-ness).
This makes it not a good workaround, thanks for pointing that out.

The urlbar example was just a way to say users expect ESC on the search bar to behave in a consistent and coherent way.
We should evaluate if there's an alternative solution to implement Bug 350079, that doesn't clear the field history, we could maybe cache the previous valid search value and then restore it? Though then the undo history would not be restored. Maybe we could use a batch started when a value is confirmed, finished on ESC or another search. Then just undo the top batch on ESC.
That's something to experiment with.

Comment 14

[Other Realm]

I think this is basically what you were suggesting, but I would say probably the easiest way would be to re-implement the old method, but store the last completed search. Then, when someone presses ESC, just replace what is in the search box with the stored value and add that to the Ctrl-Z stack as the most recent change in the search box (because it is).

Comment 15

[Peter Barney]

I heartily disagree with the logic being presented here, especially by @Marco Bonardo. You're essentially turning the search bar into a duplicate of the url bar. If that's the case, why bother even having a search bar? In addition, not all previous searches are displayed when you press the down arrow in the search bar. The list is almost random, showing only 20 previous searches over several months, in a random order.

So the big question everyone has is this: why do you feel the need to make this entirely separate control box, which has an entirely different use case, into a carbon-copy of the url bar? There's a common phrase: "a foolish consistency is the hobgoblin of little minds," or put another way, consistency for the sake of consistency is a reflection of a lack of critical thinking into the reasons things may be different.

I strong request that you revert the changes. These are the kinds of little breaking changes that just slowly but incrementally drive people away from Firefox, and there's literally no reason for it.

Comment 16

[Other Realm]

What

Comment 17

[Other Realm]

I am assuming that the issue will be fixed in version 98?

Comment 18

[schmurtz]

Yes please repair this useful functionality !

Comment 19

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Peter Barney from comment #15)

You're essentially turning the search bar into a duplicate of the url bar.

Most users expect consistency, it's also the reason you're here, you expect ctrl+z to work consistently in the search bar like it does in the other fields. Similarly other users expect ESC to work consistently in this bar, like it does in other fields.
Long term we hope to also use the same exact code, why? Because that makes maintenance a lot better, the code is more tested, it's better maintained, more people have knowledge over it, it's more future proof. Of course bugs found along the way must be addressed.

I'll try to find some time to look into the batch solution and see if it will work, otherwise we can always revert the change temporarily until we have a non-regressing solution.

Comment 20

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I clearly didn't find the time for this, so moving it into our papercuts backlog to be scrubbed.

The scope here is finding an alternative to the fix in Bug 350079, that allows for ESC to work like in the urlbar (revert to the previously confirmed search term and select it), but without clearing the input field history. Maybe we could use a batch started when a value is confirmed, finished on ESC or at the next confirmed search. Then ESC could just undo the top batch?
It's something to experiment with.

Comment 21

[y2kdman97]

We haven't forgotten. We've just given up on FF.