Closed Bug 1379431 Opened 2 years ago Closed 10 months ago

Figure out DELETE key handling in the popup and the input field

Categories

(Firefox :: Address Bar, defect, P3)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1525547
Tracking Status
firefox57 --- wontfix

People

(Reporter: ekr, Unassigned)

References

Details

(Whiteboard: [fxsearch])

Attachments

(2 obsolete files)

Affects: Nightly configured for single search bar

STR: 
1. Type something in search bar
2. Option to choose search engines appears
3. Click in search bar (e.g., to edit the text)

Expected behavior:
Search choices remain

Actual behavior:
Search choices disappear
Component: Untriaged → Search
Summary: Search chooser box disappears with click → Search box droplist should disappears when search box clicked
I assume by "single search bar" you refer to the awesomebar, so I've moved it to the proper component.

I'm not sure keeping the panel open is something we want to do. If you intend to edit the text, presumably your focus will be on the input field, not the results panel. Once you are done typing (or even start typing) it will pop up again.
Component: Search → Address Bar
Flags: needinfo?(philipp)
Summary: Search box droplist should disappears when search box clicked → Search chooser box disappears with click
Whiteboard: [fxsearch]
I agree with ekr here. The bar and the dropdown are functionally one piece of UI and moving the cursor in a text field is part of editing. It seems like we aren't really gaining anything by hiding it, but we are introducing more flashes and potentially throw users into a situation where they find it hard to get the dropdown back.

This also happens when using the arrow keys to move the cursor in the location bar.

FWIW, both Chrome and Edge keep the dropdown around when moving the cursor. The same is true for the search box on Amazon.
Flags: needinfo?(philipp)
Priority: -- → P2
Depends on: 1295718
Attachment #8975948 - Flags: review?(mconley) → review?(adw)
Thanks Harry - I've redirected to adw, who is maybe more familiar with this binding than I currently am.
Comment on attachment 8975948 [details]
Bug 1379431 - Keep URL bar open on arrows and click on anchor.

https://reviewboard.mozilla.org/r/244168/#review251214

This works great for clicks and I would r+ it for that, but there's a little bit of problematic behavior for left/right arrow keypresses: The selection in the popup disappears. The popup always has a selection, and I don't think we want this patch to have the unintended side effect of removing it. Offhand I'm not sure why it happens or what we can do about it. There are several key-related methods/handlers in urlbarBindings.xml (onKeyPress, keydown, keyup, handleKeyPress). I'd guess one or more of them would need updating.

Also, I think it would be better to set norolluponanchor in the XUL instead of JS, here: https://dxr.mozilla.org/mozilla-central/rev/11ee70f24ea52c4dc4f113593c288f4a6dc92c55/browser/base/content/browser.xul#172

I'm away next week but you can ask Marco [::mak] for reviews and help in the meantime.
Attachment #8975948 - Flags: review?(adw)
Attachment #8975948 - Attachment is obsolete: true
Assignee: nobody → htwyford
Status: NEW → ASSIGNED
Summary: Search chooser box disappears with click → Address Bar popup disappears when editing the input field
Comment on attachment 8979673 [details]
Bug 1379431 - Keep URL bar open on arrows and click on anchor.

https://reviewboard.mozilla.org/r/245814/#review252818

Please, squash your changesets.
Usually mozreview contains patches against mozilla-central, and you can have multiple changesets, but those should be used to split the work in chunks when a patch is very large, rather than doing incremental changes.
You can use the histedit mercurial extension to fold changesets, and while coding you can use the evolve mercurial extension to hg amend changes into an already committed changeset. If you have further questions about this feel free to ask.

There is a further problem that may require design help and a bit of discussion with Drew as well. It's the DELETE key. If we keep the popup open with a selection while the user edits text, he may press DEL to remove a char, but since the popup is also focused it will handle the keypress and try to remove the entry from the popup.
I'm not sure we can solve this without changing the "remove popup result" shortcut (only to SHIFT+DEL) and to make that discoverable we may have to fix bug 675818, otherwise users could be confused by the change.
I'll needinfo the relevant persons to get their opinion.

::: browser/base/content/browser.xul:181
(Diff revision 1)
>             noautofocus="true"
>             hidden="true"
>             flip="none"
>             level="parent"
> -           overflowpadding="15" />
> +           overflowpadding="15"
> +           norolluponanchor="true" />

add the attribute on the previous line, so you only touch blame of a single line

::: browser/base/content/browser.xul:181
(Diff revision 1)
>             noautofocus="true"
>             hidden="true"
>             flip="none"
>             level="parent"
> -           overflowpadding="15" />
> +           overflowpadding="15"
> +           norolluponanchor="true" />

add the attribute on the previous line, so you only touch blame on a single line
Attachment #8979673 - Flags: review?(mak77)
mverdi and adw, we have a problem with DELETE being handled by the popup instead of the input field. some platforms IIRC require shift+delete to remove from the address bar, so we could just unify on that. Though it will become pretty much undiscoverable, for which we may want to fix either bug 675818 or bug 1041761 to provide a discoverable option.

What are your opinions about this issue?
Flags: needinfo?(mverdi)
Flags: needinfo?(adw)
Shift-delete is better than delete by itself (of course), but the shift key is also commonly used while typing, so shift-delete is still a little dangerous.  Accel-delete or some other control key modifier would be better I think.

I'll leave the question about the other bugs/UI to Verdi.

(This is a separate problem, but I notice on macOS that it's actually shift-backspace, not shift-delete.  You have to hold down the function key to trigger a delete, so deleting a result by mistake (with this patch) is even more likely to happen than it should be.)
Flags: needinfo?(adw)
Comment on attachment 8979673 [details]
Bug 1379431 - Keep URL bar open on arrows and click on anchor.

We should evaluate this for the Quantum Bar at this point, so clearing the review request on the current patch. On keyboard navigation we don't close the popup already, we should check what happens on click.

And at that point I think the only solution to the DELETE problem (comment 7) for which we likely want to change the keyboard shortcut. Possibilities are SHIFT+DEL that we already use on the Mac, or accel+DEL that Drew suggested. Though I'm not sure people don't use Accel when typing, ALT and ALTGR are used by non-english languages to type chars our of the keyboard layout, and ctrl is commonly used to move cursor by full words. So in general I'm not sure there is a real advantage vs shift, that is already supported on the Mac and may be easier to the user.
Attachment #8979673 - Flags: review?(mak77)
I believe bug 959567 fixed the click handling in the legacy urlbar popup by setting consumeoutsideclicks="never"...
Depends on: 959567
What do you mean by "fixed"? if I click in the input field while the popup is open, the popup closed, that is not what we want.
(In reply to Marco Bonardo [::mak] from comment #13)
> What do you mean by "fixed"? if I click in the input field while the popup
> is open, the popup closed,

It doesn't do so over here on Ubuntu.
(In reply to Marco Bonardo [::mak] from comment #11)
> Comment on attachment 8979673 [details]
> Bug 1379431 - Keep URL bar open on arrows and click on anchor.
> 
> We should evaluate this for the Quantum Bar 

Yes. My hope for the Quantum Bar has been that once it opens it stays open until you navigate or click outside of it.

(In reply to Marco Bonardo [::mak] from comment #11)
> And at that point I think the only solution to the DELETE problem (comment
> 7) for which we likely want to change the keyboard shortcut. Possibilities
> are SHIFT+DEL that we already use on the Mac, or accel+DEL that Drew
> suggested. 

Agreed. Do we have any telemetry on how many people use this (I just learned about it from reading the bug)?
Flags: needinfo?(mverdi)
No, I don't think we have telemetry. From past experience it's common for users to try to remove entries when the awesomebar returns something they don't like, though the current behavior is quite unpredictable (some entries can be removed, others can't) and the shortcut is undiscoverable. And that's why in the past it was suggested to either add an "X" button to each entry, or better to have a contextual menu for each entry.
Depends on: 1514139
Assignee: htwyford97 → nobody
Status: ASSIGNED → NEW
Summary: Address Bar popup disappears when editing the input field → Figure out DELETE key handling in the popup and the input field
Attachment #8979673 - Attachment is obsolete: true
Depends on: 1506126
Priority: P2 → P3
No longer depends on: 959567
No longer blocks: quantumbar-input
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1525547
You need to log in before you can comment on or make changes to this bug.