Closed Bug 1657212 Opened 4 years ago Closed 4 years ago

Support key-modified one-offs and their context menus in update 2


(Firefox :: Address Bar, task, P1)




82 Branch
82.2 - Sep 7 - Sep 20
Tracking Status
firefox82 --- verified


(Reporter: mak, Assigned: bugzilla)




(1 file)

Today we asked UX what to do about key modifiers, so for example when a user CTRL/SHIFT+clicks a one-off button.
The current proposal is that, if there is a search string, it will act as the old buttons, directly executing a query in a new tab/window.
If there isn't a search string, it may open a new tab/window with the urlbar focused and search mode active on that engine. Though, I suppose we could initially just make it ignore the modifier and split this empty string part to a separate bug, if the patch starts to complicate.

I imagine we should use the same behaviour for the "Search in New Tab" one-off context menu item.

See Also: → 1658620
Priority: P3 → P2
Summary: Support key modifiers one one-off buttons → Support key-modified one-offs and their context menus in update 2
See Also: → 1658993
Assignee: nobody → htwyford
Iteration: --- → 82.1 - Aug 24 - Sep 6

This bug is closely tied to what we do with one-off keyboard shortcuts going forward. We identified some inconsistencies in the current shortcuts and this is a good opportunity to fix them. This is also blocked on what we decide to do with the one-off context menu, so I'm marking this blocked-ux and will pause work on it.

Keywords: blocked-ux
See Also: → 1662169

We're going to support Shift+Click and Shift+Enter executing a search immediately in the current tab (i.e. how one-offs behaved before update2). All other keyboard shortcuts will behave as they do now. For example, Alt+Enter will continue to search immediately in a new foreground tab and Accel+Click will continue to search in a new background tab. Shift+Enter previously opened a one-off search in a new window, so we're dropping support for that behaviour. The user can still open a one-off search in a new window by selecting a one-off with the keyboard and then Shift+Clicking on the heuristic result or on the Go button.

We're also going to remove the context menu entirely from the one-offs. Both items in the context menu can be achieved by other means. Also, the context menu doesn't make any sense for the local one-offs and it is confusing that the engine one-offs have a context menu but the local one-offs do not.

Iteration: 82.1 - Aug 24 - Sep 6 → 82.2 - Sep 7 - Sep 20
Keywords: blocked-ux

This patch adds support for key modifiers on the refreshed one-offs. They work the same as the old key modifiers, with one exception: Shift+Click and Shift+Enter both execute a search immediately in the current tab, replicating the behaviour of the old one-offs. For empty searches, Shift+Click and Shift+Enter just enter search mode. To support these Shift modifiers, we dropped support for opening a one-off search in a new window. Users can still search in a new window with a non-default engine by typing a search string, selecting a one-off with the keyboard, then Shift+Clicking the heuristic result or the Go button.

Other key modifiers worth pointing out include Accel+Click to search in a new background tab and Alt+Enter to search in a new foreground tab. If these modifiers are used on the local one offs or with an empty query, we open search mode in the new tab.

This needs tests, but I'm posting this tentative version to get feedback on the design.

Priority: P2 → P1
Pushed by
Support one-off key modifiers and remove one-off context menus. r=adw
Regressions: 1664598
Regressions: 1651963
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch

I verified this issue using 82.0a1 (2020-09-14) on macOS 10.13 and Windows 10 x64.
Adrian could you help me with Ubuntu verification?

Flags: needinfo?(adrian.florinescu)

Verified on latest Nightly 83.0a1 under Ubuntu 18.04 64-bit.

Flags: needinfo?(adrian.florinescu)
You need to log in before you can comment on or make changes to this bug.