Middle-click on a search bar completion or search engine options doesn't open new tab in foreground like location bar and bookmark

NEW
Unassigned

Status

()

defect
P3
normal
Rank:
35
4 years ago
6 months ago

People

(Reporter: human.peng, Unassigned)

Tracking

({regression})

36 Branch
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxsearch])

Reporter

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150114125146

Steps to reproduce:

Search something in search bar until some suggestions show.

Middle click the suggestions


Actual results:

The suggestion result opens in background new tab. 


Expected results:

It was in foreground new tab. And it still do so in location bar, so they're inconsistent.

Note: either new search bar design and the old one are affected.
Reporter

Updated

4 years ago
Component: Untriaged → Search

Comment 1

4 years ago
Does this happen with search history items (rather than suggestion items), too?
Flags: needinfo?(human.peng)
Reporter

Comment 2

4 years ago
(In reply to :Gijs Kruitbosch from comment #1)
> Does this happen with search history items (rather than suggestion items),
> too?

Yes. And I'm working on the windows, hold on!
Flags: needinfo?(human.peng)
This was implemented in bug 1106101 and is by design. The fact that it's not consistent with the location bar still seems like a valid bug though.
Reporter

Comment 4

4 years ago
(In reply to Florian Quèze [:florian] [:flo] from comment #3)
> This was implemented in bug 1106101 and is by design. The fact that it's not
> consistent with the location bar still seems like a valid bug though.

Hmm, i'm not very familiar with the developement procedure of firefox but the window I found is between 12/18 and 12/19: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e441ff66c5e&tochange=1427b365cd39 (can't go any further with mozreg on Windows) but in bug #1088660 the last rev I saw was in 11/27?
Reporter

Updated

4 years ago
Reporter

Comment 5

4 years ago
Ah ignore me, I read the wrong bug.
per comment 3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Philipp, double checking with you before we actually look for someone to implement this change: should middle-clicks on the location bar suggestions/completions open the URLs in background tabs to be consistent with the new behavior of the searchbar?
Flags: needinfo?(philipp)
Summary: Middle-click on suggestions of search bar open links in background, it was in foreground before 35 and foreground for location bar → Middle-click on a location bar completion should open the link in the background, like the searchbar does

Updated

4 years ago
Duplicate of this bug: 1123645

Comment 10

4 years ago
(In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond from comment #8)
> Sounds good to me!

Why this change in behaviour in the first place? I tried reading through bug 1106101, but the best rationale I can find is "We should keep the dropdown open so that you can search with multiple search engines" - but that of itself doesn't require the tabs to be opened in the background. So I'm confused, and before we replace this longstanding behaviour with one that multiple users are now complaining about, I'd really like to understand the motivation for that change better.
Flags: needinfo?(philipp)

Comment 11

4 years ago
I submitted bug 1123645 which was declared a duplicate of this bug. 

User has the option: "When I open a link in a new tab, switch to it immediately". 

This option should mean that when a new tab is opened the user has the option to switch to it immediately (the link is brought to the foreground) or if the option is not selected the link opens in the background. I believe this is how Firefox always used to work. I use the option "When I open a link in a new tab, switch to it immediately" and I know for sure middle clicking on search suggestions always opened in a new tab and the new tab was brought to the foreground. Apparently the latest release of Firefox  broke this convention.

I am not a technical person, just a very heavy Firefox user, so I would definitely appreciate someone fixing this issue.

Many thanks.
(In reply to :Gijs Kruitbosch from comment #10)
> (In reply to Philipp Sackl [:phlsa] please use needinfo to make me respond
> from comment #8)
> > Sounds good to me!
> 
> Why this change in behaviour in the first place? I tried reading through bug
> 1106101, but the best rationale I can find is "We should keep the dropdown
> open so that you can search with multiple search engines" - but that of
> itself doesn't require the tabs to be opened in the background. So I'm
> confused, and before we replace this longstanding behaviour with one that
> multiple users are now complaining about, I'd really like to understand the
> motivation for that change better.

I'm not sure there even was a conscious decision about whether or not the new tab should be opened in the background.

That being said, Peter raises a good point. Both the Awesomebar and the search field seem to have their behavior hard-coded (now in different ways) rather than respecting the pref. I'm not sure that deviation from the pref is by design or more of an implementation accident, but it seems inconsistent.
Flags: needinfo?(philipp)

Comment 13

4 years ago
Philipp: I greatly admire your tactful response. As a very longtime FF user I am certain this IS "an implementation accident" (i.e. a bug) and IS "inconsistent". The FF Menu Option reads very clearly: "When I open a link in a new tab, switch to it immediately". This option has been around for a long time and is very useful. Any time a new tab is opened should respect this option. Search suggestions in the search field currently do not respect this option. I have no idea how FF assigns issues to be fixed, but I am hopeful this will be fixed soon.
Priority: -- → P3
Whiteboard: [fxsearch]

Updated

4 years ago
Rank: 35
Reporter

Comment 14

4 years ago
OK, since now new search UI is mandatory on Firefox 43 and later, can we fix this as soon as possible?

Before I can just use alt+enter to open search results in new tab in foreground, now I have to middle click search engine button (when I'm going to use non-default search engines, for sure) and it opens in background unexpectedly.

Comment 15

4 years ago
Florian, can you comment as to the priority of this thing per comment #14 ?
Flags: needinfo?(florian)
Reporter

Comment 16

4 years ago
Now 43 is on release channel, still no fix on this??
Reporter

Comment 17

4 years ago
Also, the new title of this bug changed by Florian is just very wrong. We should follow the default behavior as before (i.e. middle click on the suggestion/auto completion of search bar should be frontground just like location bar.
Reporter

Updated

4 years ago
Summary: Middle-click on a location bar completion should open the link in the background, like the searchbar does → Middle-click on a search bar completion or search engine options should open the link in the frontground, like the old search bar and location bar
(In reply to :Gijs Kruitbosch (away 18-28 Dec.) from comment #15)
> Florian, can you comment as to the priority of this thing per comment #14 ?

Well, the priority is that we would review/take a fix, but I don't think anybody in the search team is currently intending to work on writing the patch for this.
Flags: needinfo?(florian)

Updated

4 years ago
Blocks: 1144948
Duplicate of this bug: 1144948

Updated

3 years ago
See Also: → 1316863
Reporter

Comment 20

3 years ago
Can we fix this? It has been a whole year.
Rephrasing the summary to match the decision in comment 12.
Summary: Middle-click on a search bar completion or search engine options should open the link in the frontground, like the old search bar and location bar → Middle-click on a search bar completion or search engine options should respect the browser.tabs.loadInBackground pref

Comment 22

3 years ago
(In reply to Florian Quèze [:florian] [:flo] from comment #21)
> Rephrasing the summary to match the decision in comment 12.

Are you sure that's the right pref? What happens for the context menu, where arguably this should go under browser.search.context.loadInBackground (where the default is different) ? On the other hand, the context menu should arguably do the same thing as middle click...

(And yes, it's crazy that we have two prefs... history. :-( )
I've just spent a bit of time investigating the prefs & behaviours. Here's the current situation in nightly builds as of today:

* General Search in the search bar popup (using one of the search results)

- browser.search.openInTab defaults to false.
- Enter is pressed with the alt key -> do the opposite of the browser.search.openInTab pref
-- No background available.
- Mouse event with middle button, or with accel key -> Open the tab in the background.
- Otherwise -> load in current tab


* URL Bar

- Middle Click -> Opens in new tab in foreground
- Middle Click & Shift -> Opens in new tab in background.

Doesn't seem affected by prefs.


* Highlight text in page, use context menu to search for the text

- Always opens in a new tab, and determines whether to load in background based on the browser.search.context.loadInBackground pref (defaults to false).


* Open the search bar & right click one of the one-off search engine buttons, select "Search in new Tab"

- Opens a new tab with foreground/background depending on "browser.tabs.loadInBackground" pref.


* Clicking the Search Button in the Search Bar (the arrow at the end)

Relies on https://dxr.mozilla.org/mozilla-central/rev/a2741dd43eeae54f4dd7423bd832a761481c56ce/browser/base/content/utilityOverlay.js#122

Basically:
- Left Click -> loads in current tab
- Left Click & Shift -> New Window
- Left Click & Meta/Ctrl -> New Tab
- Middle Click & (browser.tabs.opentabfor.middleclick = true) -> New Tab
- Middle Click & (browser.tabs.opentabfor.middleclick = true) & Shift -> New Tab in Background
- Middle Click & (browser.tabs.opentabfor.middleclick = false) -> New Window


My next comment will include proposals for the changes in behaviour.
Here's the bits I think we should change:

(In reply to Mark Banner (:standard8) from comment #23)
> * General Search in the search bar popup (using one of the search results)
> 
> - browser.search.openInTab defaults to false.
> - Enter is pressed with the alt key -> do the opposite of the
> browser.search.openInTab pref
> -- No background available.
> - Mouse event with middle button, or with accel key -> Open the tab in the
> background.
> - Otherwise -> load in current tab

Here we change the mouse middle button to respect the browser.tabs.loadInBackground. This will default to opening a search option in the background, which is similar to today.

We should probably then also make it so that middle click & shift does the opposite to browser.tabs.loadInBackground.

> * URL Bar
> 
> - Middle Click -> Opens in new tab in foreground
> - Middle Click & Shift -> Opens in new tab in background.

Again, change the middle click to respect the browser.tabs.loadInBackground. This will change today's default of opening in foreground, but to me it feels more consistent.

I think the other functionality should stay the same for now.

I will work on a patch to implement the change, it looks like we don't already have tests for this, so I'll write those as well. In the meantime if Philipp/Florian/Gijs have any feedback on the plan I'll be happy to take it.
Assignee: nobody → standard8
Flags: needinfo?(philipp)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(florian)

Comment 25

2 years ago
I don't have an opinion, it's mostly a UX question, seems to me, so I'll wait for Philipp to pipe up.
Flags: needinfo?(gijskruitbosch+bugs)
Seems reasonable to me, but like Gijs said it's really a UX decision.
Flags: needinfo?(florian)
Huh, I could swear that I have responded to this already... looks like I'm getting old.
Anyway, those changes sound sensible to me!
Flags: needinfo?(philipp)
I took a look at this in a bit more detail, and discovered a couple of extra things:

- The urlbar currently doesn't reflect the browser.tabs.loadInBackground preference as it is seen to be within "chrome" code (openLinkIn in utilityOverlay.js).

- Things like the bookmarks toolbars, follow the same flow as the urlbar.

- Just changing the searchbar to use the preference would make them inconsistent with each other.

At the moment I don't have time to do further work on this. The next steps would probably be to work out the effect of changing the urlbar to not be "chrome" when middle-clicking and see how that plays with consistency for the rest of the browser.
Assignee: standard8 → nobody
Reporter

Comment 29

2 years ago
Thanks for your investigation!

But just to make things clear, since I kinda feel the situation has changed from the time I reported this bug.

The current behavior is:

1) middle click bookmark bar bookmarks: always open in foreground
2) middle click suggestions of location bar: always open in foreground
3) middle click suggestions of search bar: always open in *background*

None of those behaviors are changed with browser.tabs.loadInBackground setting.

I personally don't feel they should be affected by browser.tabs.loadInBackground any more (I don't know why I thought so 2 years ago, it has been a long time).

But I still feel: 2) and 3) should be the same. Is there any reason why search bar is different from location bar? You mentioned urlbar, I assume you mean location bar; so what's your opinion about the search bar?

And I'm totally ok with the current behavior of 1) and 2). My only concern is 3).
Reporter

Updated

2 years ago
Summary: Middle-click on a search bar completion or search engine options should respect the browser.tabs.loadInBackground pref → Middle-click on a search bar completion or search engine options doesn't open new tab in foreground like location bar and bookmark
Reporter

Comment 30

2 years ago
Changed the ticket title to match with my comment #29.
You need to log in before you can comment on or make changes to this bug.