1615149 - Changing the search string when a one-off is selected doesn't reset the selection

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Kartikaya Gupta (email:[e-mail])]

Was seeing this on 74 Nightly, and still happens on the latest 75 Nightly (2020-02-12). On macOS 10.14, if that matters.

STR:

1. Go to a URL like https://tools.ietf.org/html/rfc822#section-3.1.1
2. Click on the URL bar and hit backspace a couple of times to trim off a few chars from the end of the URL
3. Press the up button. This should put focus on the settings icon in the bottom-right corner of the URL bar dropdown, but ALSO keeps the blinking cursor in the text-entry part of the URL bar.
4. Continue editing the URL, e.g. continue backspacing until the entire URL fragment portion (#section-3.1.1) is deleted. For good measure even click and highlight parts of the URL with the mouse, just to be extra sure that the focus is on the text entry part of the URL bar.
5. Hit enter

Expected:
The edited URL is navigated to

Actual:
about:preferences#search is opened in a new tab, because apparently that settings icon in the bottom-right that got focus in step 3 gets activated in step 5.

Comment 1

[Drew Willcoxon :adw]

This looks like a quantumbar regression -- at least I went as far back as 66, and on 66 and 67, once you change the input text, the one-off search button selection goes away, and the heuristic first result becomes selected. Starting in 68, the one-off remains selected.

Comment 2

[Marco Bonardo [:mak]]

Imo this is not a bug.
When a one-off is selected it has the priority anyway, and based on that the behavior is expected. We never remove the focus from the input field.

The case would be different if there would be another row selected, like the heuristic row, but that's not the case afaict?

Comment 3

[Drew Willcoxon :adw]

I can understand arguments both for and against the idea that this is a bug, but at least this is a change in behavior from awesomebar that might not have been intentional. There's no other row selected. If you want to wontfix it, that's fine with me.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

It's unexpected from a user point of view because it really really looks like you're interacting with the text entry part of the url bar and then hitting enter does something else entirely. I've run into this accidentally a couple of times before and couldn't figure out what happened until I sat down to reproduce it this time.

Also as far as I can tell, once you hit up/down to move focus there's no way you can get it back to where hitting enter uses the text from the text entry part. Although I'm not at my desktop right now so I can't confirm that.

Comment 5

[Drew Willcoxon :adw]

You can cycle back to the first result. When you hit enter while the first result is selected, it'll use the text you're typing.

I agree it's strange. Part of it is just the nature of having the one-off search buttons, where there can be two highlights/selections at the same time. But the settings button in particular is a special case. When another search button is highlighted, it's clearer what will happen, at least to me: pressing enter will do a search for your text using the highlighted engine.

Although it would be even clearer if quantumbar also highlighted the first result at the same time since it says "Search with <Engine>", which we used to do... That seems like a bug.

Also, I notice that we don't update the "<Engine>" part of the first result when a search button is highlighted and then you type. That's definitely a bug.

Comment 6

[Drew Willcoxon :adw]

(In reply to Drew Willcoxon :adw from comment #5)

Also, I notice that we don't update the "<Engine>" part of the first result when a search button is highlighted and then you type. That's definitely a bug.

I filed bug 1615470.

Comment 7

[Marco Bonardo [:mak]]

My point is that the input field is always in focus, regardless of a selection in the results pane. That's not going to change. The problem here is we don't reset anymore the selection.
If we want to reset the selection when the search string changes, we can surely do it; just note that it will made no more possible to refine the search string after picking a one-off engine. We should clarify with UX if that's something we're ok to lose.

Comment 8

[Drew Willcoxon :adw]

Yes, that's what I meant by it's part of the nature of having one-off buttons at all.

Summing up, there are three problems or potential problems here:

1. We don't clear the one-off selection when you start typing. That might not be a bug, but it's a change from awesomebar that might have been unintentional. Edit: It's particularly weird when the one-off settings button is selected.
2. We don't select the heuristic result when you start typing while a one-off is selected. This also might not be a bug, but it would make it clearer what happens when you press enter.
3. The "Search with" text and favicons in the heuristic and private-search results revert to the default engine when a one-off is selected and you start typing. That's bug 1615470.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

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

If we want to reset the selection when the search string changes, we can surely do it; just note that it will made no more possible to refine the search string after picking a one-off engine. We should clarify with UX if that's something we're ok to lose.

Can we just reset the selection if the selection is the settings button (as opposed to the one-off search icons)? Because in that scenario you're not "refining the search string", you're just refining something that will be ignored. If the user is editing the URL after selecting the search settings, I think it should be pretty clear that the user intent is no longer to go to the search settings.

Comment 10

[Marco Bonardo [:mak]]

(In reply to Kartikaya Gupta (email:[e-mail]) (away until 17-Feb-2020) from comment #9)

Can we just reset the selection if the selection is the settings button (as opposed to the one-off search icons)? Because in that scenario you're not "refining the search string", you're just refining something that will be ignored.

yes, but is it worth the time? that's a really edge case. It would be better to first define exactly which behavior is expected more in general, and then maybe that problem will solve by itself.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Given that nobody has filed this bug before despite it being in production for a while, I guess it is more of an edge case than it feels like to me. Feel free to fix as you feel is best.

Comment 13

[Marco Bonardo [:mak]]

I think Search Mode in 83 solves all the concerns in comment 8, but the problem with the settings button is still present.

Comment 14

[Djfe]

Please kindly forward my suggestions/analysis to the UI department so they can decide what's best here :)
I feel like this behavior can and shall be improved to allow users to use the up arrow in the address bar correctly.
(yes, this is an exact copy of my comment here. I'm sorry if I made you receive the message twice, but since currently there are two bug reports on the exact same issue.. :/ https://bugzilla.mozilla.org/show_bug.cgi?id=1687125#c6 )

ok, this bug has been annoying me for quite a while now and I finally figured out what causes it. which in turn allowed me to find this bug report.
You honestly can't blame users for this issue imo.
https://support.mozilla.org/bm/questions/1353683

This is a clear design flaw that needs to be fixed because people currently don't notice where the selection jumps towards when pressing up once. (for a several reasons listed below)

What is happening from a user perspective:
I subconciously started using the up arrow for killing the current autocomplete suggestion. Because nothing in the address bar indicates otherwise.
The selection is removed when I press up, I can still keep on typing and enter a url or type in a search.
Then when I press enter, it opens the search preferences and everytime I'm confused why this happens, because I only press enter like I always do. And I'm 99% certain I didn't accidentally hit another key while doing so (like shift + Enter or I dunno, some other kind of hotkey combination that could cause this behavior). The up arrow I used was in between typing the text and seconds before I hit enter. I never brought that together in my mind and it always left me annoyed:

1. for not knowing why
2. for having to retype the url or search suggestion from the top of my head

My suggestion for solving this:
Every other selection in the results pane currently tells you right in the address bar, that it's selected and allows you to cancel it by pressing the x selection next to it. Only "change search preferences" doesn't.
It should tell you before your address bar input while you're typing: "Enter/Open search preferences"

Also this could come as a surprise to users using the up arrow the way I started using this. I'm certain this is kind of common by now.
So let's make it a feature:
One times "up arrow" for killing the autosuggestion (in addition to pressing backspace)
Two times "up arrow" for changing the search preferences.
Three or more times for all the other suggestions.

This solves everything and we can keep the cursor blinking in the address bar.
We can also keep the up arrow to clear/hide the autocomplete suggestion and don't kill this feature to prevent users from using the up arrow in the wrong way. There is no wrong way just the way people have been using this software for years now and habits like these are hard to change. So let's adjust Firefox slightly to incorporate this usage.

Why did I even start getting used to pressing the "up"-arrow for clearing the autocomplete suggestion?
Because the selection button for the search preferences is on the bottom right which is outside of my primary field of vision and in my peripheral view. I'm using a WQHD monitor 27". it's a distance of ~1372x436px or ~33cm (longer than a DIN A4 page) and far away from where my eyes look while typing.
even the other buttons at the bottom left are kind of far away.

This could and should be solved as well, so users start using the up arrow correctly:
Make the button(s) on the bottom right flash once when selected via the arrow key. This causes awareness for the button being there and being selected. Making the button blink once would allow me to visuallize the change in my peripheral vision making my eyes dart towards the bottom right and thinking ah, that's where my selection currently is. (the default background can still be dark, but it should flash once: either just a bright background or also invert the color of the gear icon for even more contrast).

This can be done for all buttons or just the button on the bottom right since it's furthest away and since it's the only button where it's reversed (jumping to the back of the possible options)