'Search <Search Engine> for "<selection>"' should respond to middle-click

NEW
Unassigned

Status

()

Firefox
General
7 years ago
2 years ago

People

(Reporter: alex_mayorga, Unassigned)

Tracking

(Blocks: 1 bug, {ux-efficiency})

Trunk
ux-efficiency
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox10 affected)

Details

Attachments

(1 obsolete attachment)

(Reporter)

Description

7 years ago
Do you close the book you're currently reading to look up something in a dictionary or encyclopedia? Me neither ;-)

After bug 695482, context menu 'Search <Search Engine> for "<selection>"' open search results in the current tab, which I find annoying.

Please make the option respond to middle-click so the search results are displayed in a background tab next to the current one and not in the foreground tab.
(Reporter)

Updated

7 years ago
Blocks: 695482
(Reporter)

Updated

7 years ago
Keywords: ux-efficiency
Summary: 'Search <Search Engine> for "<selection>"' should respond middle-click → 'Search <Search Engine> for "<selection>"' should respond to middle-click

Comment 1

7 years ago
(In reply to alex_mayorga from comment #0)
> Do you close the book you're currently reading to look up something in a
> dictionary or encyclopedia? Me neither ;-)

This metaphor is nonsensical. We don't close the tab you're reading.
(Reporter)

Comment 2

7 years ago
My apologies, you're right =(

Still I often find myself looking up things in a search engine but I don't want my current reading interrupted with the definitions or fact checks right away but conveniently opened in the background for when I finish the main reading.

Makes sense?
We support shift/control/option modifiers in other contexts to allow the user to have more control over where links will open. Maybe that would make sense to do here. [Instead of, or in addition to, middle click.] Though I suppose, from a purity PoV, middle click and even modifiers are slightly odd for a menu item. Do we already support those anywhere else?

Comment 4

7 years ago
(In reply to Justin Dolske [:Dolske] from comment #3)
> We support shift/control/option modifiers in other contexts to allow the
> user to have more control over where links will open. Maybe that would make
> sense to do here. [Instead of, or in addition to, middle click.] Though I
> suppose, from a purity PoV, middle click and even modifiers are slightly odd
> for a menu item. Do we already support those anywhere else?

"View Image" supports middle-, ctrl-, and shift-click.

Comment 5

7 years ago
Created attachment 573962 [details] [diff] [review]
patch

Makes the search results open in a background tab if shift key is pressed or middle button is clicked.
Assignee: nobody → fryn
Status: NEW → ASSIGNED
Attachment #573962 - Flags: review?(dolske)
Comment on attachment 573962 [details] [diff] [review]
patch

Shift usually opens a new window. You should probably just utilize whereToOpenLink.
Attachment #573962 - Flags: review?(dolske) → review-

Updated

7 years ago
status-firefox10: --- → affected

Comment 7

7 years ago
This feels like a poor compromise. I don't see any evidence that people use this feature in a wildly different manner from opening links in a new tab. If the selection that I'm searching for was a link then I would have middle-clicked it. It's only when it's not a link that I right-click and search for it. The intent is the same: to queue up something to read when I've finished with the current tab.

The current situation breaks the flow of reading and also resets the tab ordering for new tabs (i.e., they start opening at the first position to the right again after you to switch back).

I think this should be backed out unless some evidence appears (I think one of the test pilot studies might have useful data) that more people are switching to the new tab straight away than continue reading the current tab.

Updated

7 years ago
Assignee: fryn → nobody
Status: ASSIGNED → NEW

Updated

7 years ago
Attachment #573962 - Attachment is obsolete: true

Updated

6 years ago
OS: Windows 7 → All
Hardware: x86 → All
(Reporter)

Comment 8

6 years ago
With bug 695482 FIXED can we get this implemented sooner rather than later?

Thanks in advance.

Updated

6 years ago
No longer blocks: 695482
Depends on: 695482

Updated

2 years ago
Blocks: 1327284
You need to log in before you can comment on or make changes to this bug.