695482 - "Search Google for <selection>" should open in the foreground, not be governed by loadInBackground preference

Status: RESOLVED FIXED

(Firefox :: Menus, defect)

Description

[Frank Yan (:fryn)]

Yes, this is a duplicate from bug 612965, but Limi and I agree that a fundamental difference between "Open Link in New Tab" and "Search Google for <selection>" exists. Searching is almost always a direct action that expects immediate feedback.

Comment 1

[Frank Yan (:fryn)]

Attachment: patch

Comment 2

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 567852 [details] [diff] [review]
patch

Yes, this should be the default. It's not obvious what happens when you select this menu action, which makes it seem broken. You usually use it to look something up quickly (as opposed to opening a lot of tabs in the background), so it should be frontmost by default.

Comment 3

[Frank Yan (:fryn)]

Thanks for the quick review, Gavin and Limi!

https://hg.mozilla.org/integration/fx-team/rev/7b05a3d1f56e

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/7b05a3d1f56e

Comment 5

[alex_mayorga]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #2)
> Yes, this should be the default. It's not obvious what happens when you
> select this menu action, which makes it seem broken. You usually use it to
> look something up quickly (as opposed to opening a lot of tabs in the
> background), so it should be frontmost by default.

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

Can we please get a preference for this at least?

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I generally use this to queue up stuff for later reading, so this change is quite annoying.

Can we either get a pref for this for fix Bug 696747 for 10?

Comment 7

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #6)
> I generally use this to queue up stuff for later reading, so this change is
> quite annoying.
> 
> Can we either get a pref for this for fix Bug 696747 for 10?

I too do the same, right-click, search Google for... for later reading, would prefer that a pref be added as well.  

To me, from the right-click context menu - mid-clicking would not be intuitive enough as I would guess most if not all users right-click for context-menu, left click for desired section, so not sure fixing 696747 for this issue is the right fix.

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

Further comment, the 'keyword' UI Efficiency is clearly wrong from a users standpoint.  Its not efficient if I have switch back to the tab I was reading because I don't want to read the searched item just yet.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This check-in broke our mozmill test which covers this feature. See bug 701903.

Comment 10

[Daniel C]

I too would like to dispute the last sentence of comment 0. More often than not (almost entirely actually), I have immediately switched back from the newly created tab to the tab I was reading. This is frustrating as it breaks the flow of reading (like the comment 5 analogy) and also messes up the tab ordering of unread background tabs (as once you switch back new tabs start opening at the first position to the right again).

I think this should be backed out. For people that like the new behaviour, it is less disruptive to click the background tab (as before this change) than it is for people who dislike this change to have an unexpected tab steal their attention and break the tab-ordering.

Comment 11

[Dão Gottwald [:dao]]

(In reply to Daniel Cater from comment #10)
> I think this should be backed out. For people that like the new behaviour,
> it is less disruptive to click the background tab (as before this change)
> than it is for people who dislike this change to have an unexpected tab
> steal their attention and break the tab-ordering.

I agree, this change doesn't seem worth the frustration it seems to cause for some users. I find it hard to speculate about the number of users disliking this change vs. those liking it. Without a clearer sense of this*, it's not even clear that bug 696747 is the right way forward.

*: We can add telemetry probes for the context menu item usage and tab switching behavior.

Comment 12

[Jim Jeffery not reading bug-mail 1/2/11]

Can we just re-open this and back out pending a better solution or just resolve to back this out and WONTFIX please.

Comment 13

[Ed Morley [:emorley]]

This breaks my workflow when reading bugmail and doing the select a bug number, search with bugzilla trick, since every time I have to switch back to my pinned gmail tab to finish going through the messages.

Given this is quite a change in behaviour and there is no way to disable it with an about:config pref, I personally feel it's best to back this out now until the kind of statistics Dao mentioned have been collected and analysed, or an about:config pref can be added.

Comment 14

[Erunno]

(In reply to Daniel Cater from comment #10)
> also messes up the tab ordering of unread background tabs (as once you switch 
> back new tabs start opening at the first position to the right again).

This issue was reported years ago though I can't find the corresponding bug at the moment. Chrome does a far better job in this regard when switching between tabs in comparison.

Comment 15

[Alex Limi (:limi) — Firefox UX Team]

(In reply to alex_mayorga from comment #5)
> Can we please get a preference for this at least?

This is a perfect example of picking a default, and letting add-ons handle the other case. I don't have any opinion on an about:config preference or whether to handle it all in the add-on, but this isn't something that justifies a preference in Firefox UI.

Comment 16

[Dão Gottwald [:dao]]

Attachment: backout

I'd like to back this out from aurora in order to do bug 704538 before possibly relanding this.

Comment 17

[LegNeato]

Comment on attachment 577256 [details] [diff] [review]
backout

[triage comment]
Sounds like a good plan. Please land on mozilla-aurora when possible

Comment 18

[Dão Gottwald [:dao]]

backed out:
https://hg.mozilla.org/mozilla-central/rev/e8e2efb5bf69
http://hg.mozilla.org/releases/mozilla-aurora/rev/3bae93f4651f

Comment 19

[tracy.cooperjr]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #15)
> (In reply to alex_mayorga from comment #5)
> > Can we please get a preference for this at least?
> 
> This is a perfect example of picking a default, and letting add-ons handle
> the other case. I don't have any opinion on an about:config preference or
> whether to handle it all in the add-on, but this isn't something that
> justifies a preference in Firefox UI.

Exactly. The default should be what everyone is used to and addons can change it if a user wants.

Comment 20

[Frank Yan (:fryn)]

(In reply to tracy.cooperjr from comment #19)
> Exactly. The default should be what everyone is used to and addons can
> change it if a user wants.

This is entirely the wrong way to make design decisions.
Everyone was once used to IE6.
More recently, everyone was used to tabs-on-bottom, but we believed and still believe that tabs-on-top is better, so we changed it and after a while, most people realized that they actually like tabs-on-top more.
Faaborg gives this example at around 14:20 into his talk at PARC.
http://youtu.be/hMDBwa4huUY#12m20s

The telemetry probe that Dão proposed mitigates this problem for the most part.

Comment 21

[tracy.cooperjr]

(In reply to Frank Yan (:fryn) from comment #20)
> (In reply to tracy.cooperjr from comment #19)
> > Exactly. The default should be what everyone is used to and addons can
> > change it if a user wants.
> 
> This is entirely the wrong way to make design decisions.
> Everyone was once used to IE6.
> More recently, everyone was used to tabs-on-bottom, but we believed and
> still believe that tabs-on-top is better, so we changed it and after a
> while, most people realized that they actually like tabs-on-top more.
> Faaborg gives this example at around 14:20 into his talk at PARC.
> http://youtu.be/hMDBwa4huUY#12m20s
> 
> The telemetry probe that Dão proposed mitigates this problem for the most
> part.

Can't disagree with you but even for Tabs on Top there is still an option to turn it off if you liked how it originally was designed and used. That's all I'm asking for at a minimum.

Comment 22

[David Smith]

I misread Limi's post at first, it seems.  For some reason I (and possibly a few others) was sure he said that the only way it should be possible to change it was via an addon.

He's not actually saying (unless I'm really confused) that there shouldn't be a pref at all, just that it shouldn't be a standard UI pref (eg: in options dialog or a menu item like Tabs on Top/Bottom).  That's perfectly fine (though it's not like you're pressed for space in the Tabs category of the Options dialog).  It just needs an about:config pref for it that does the same thing as the other prefs for how tabs open (eg: middle-click, etc).

Comment 23

[Frank Yan (:fryn)]

Unassigning myself; awaiting verdict.

Comment 24

[Frank Yan (:fryn)]

Telemetry confirmed that this was indeed the right fix.
We found that 72% of the time, within five seconds of selecting "Search Google for <selection>", users select the newly created tab with the search results.

I'm going to back out the telemetry bits and re-land this in the next few days, unless someone has a reasonable objection.

Comment 25

[tracy.cooperjr]

Not an objection but will there be an about:config option to keep it the way it currently works for the other 28% of us? I ask as that was my main problem with the way it was initially implemented, I had no option to change it back to how I was used to.

Comment 26

[Dão Gottwald [:dao]]

I'll object gently. We probably should have defined this at the outset, but... While 28% vs. 72% looks clear, I think we'd want the minority case to be smaller. The reason is that this change disrupts those users' workflow, while the status quo merely doesn't automatically take the final step that those other users want.

28% is also high enough that a hidden pref doesn't cut it.

Comment 27

[Frank Yan (:fryn)]

(In reply to tracy.cooperjr from comment #25)
> Not an objection but will there be an about:config option to keep it the way
> it currently works for the other 28% of us?

(In reply to Dão Gottwald [:dao] from comment #26)
> I'll object gently. We probably should have defined this at the outset,
> but... While 28% vs. 72% looks clear, I think we'd want the minority case to
> be smaller. The reason is that this change disrupts those users' workflow,
> while the status quo merely doesn't automatically take the final step that
> those other users want.
> 
> 28% is also high enough that a hidden pref doesn't cut it.

First of all, the 28% vs. 72% result does _not_ imply that 28% of the time, users prefer the tab in the background. (This is also different from 28% of _users_.) The 28% also includes the times for which users who unable to find the newly opened tab and times for which users were indifferent about the result.

Limi and I agree that the 72% result for times that users clearly prefer seeing the results page first is sufficient validation that the default should be to select the new tab immediately. We also would like to keep the telemetry probe active until we have more results that show the distribution after we land the change. If the distribution still shows that >20% of the time, users prefer the tab to be in the background, that will warrant a visible preference.

Comment 28

[Dão Gottwald [:dao]]

(In reply to Frank Yan (:fryn) from comment #27)
> First of all, the 28% vs. 72% result does _not_ imply that 28% of the time,
> users prefer the tab in the background.

Why not?

> Limi and I agree that the 72% result for times that users clearly prefer
> seeing the results page first is sufficient validation that the default
> should be to select the new tab immediately.

No surprise here. Instead of making bold statements, though, would you mind responding to the distinction I made? (I.e. disrupting the workflow for a significant minority can be worse than letting a majority take a final step manually.)

Comment 29

[Paul [pwd]]

(In reply to Frank Yan (:fryn) from comment #24)
> Telemetry confirmed that this was indeed the right fix.
> We found that 72% of the time, within five seconds of selecting "Search
> Google for <selection>", users select the newly created tab with the search
> results.
> 
> I'm going to back out the telemetry bits and re-land this in the next few
> days, unless someone has a reasonable objection.

5 seconds is a long time. Can this data be presented for perusal? What is the percentage for people changing tab instantly (<2 seconds)?

Comment 30

[Frank Yan (:fryn)]

(In reply to Dão Gottwald [:dao] from comment #28)
> (In reply to Frank Yan (:fryn) from comment #27)
> > First of all, the 28% vs. 72% result does _not_ imply that 28% of the time,
> > users prefer the tab in the background.
> 
> Why not?

I explained above. Default settings affect behavior. The 28% set also includes the times that people who are mostly indifferent or simply confused. Therefore, users prefer the tab in the background _at most_ 28% of the time. Once we change the default, the times that people that are mostly indifferent will then be include in the "foreground" set, i.e. the set of times that people didn't switch back to the original tab.

(In reply to Dão Gottwald [:dao] from comment #28)
> (I.e. disrupting the workflow for a
> significant minority can be worse than letting a majority take a final step
> manually.)

Of course it _can_. We simply have to make a best judgment on the amount of disruption vs. convenience that is tolerable. I don't know a magic number.

(In reply to Paul [sabret00the] from comment #29)
> 5 seconds is a long time. Can this data be presented for perusal? What is
> the percentage for people changing tab instantly (<2 seconds)?

That is not up to me; we don't have that data.

Comment 31

[Paul [pwd]]

> (In reply to Paul [sabret00the] from comment #29)
> > 5 seconds is a long time. Can this data be presented for perusal? What is
> > the percentage for people changing tab instantly (<2 seconds)?
> 
> That is not up to me; we don't have that data.

This appears to be a kind of "We can't find any information that there's no WMDs so there has to be WMDs" type argument. Clearly there's enough data to suggest this should be looked into further. But as stated, five seconds is a long time compared to instantaneous look up.

Comment 32

[Dão Gottwald [:dao]]

(In reply to Frank Yan (:fryn) from comment #30)
> I explained above. Default settings affect behavior. The 28% set also
> includes the times that people who are mostly indifferent or simply
> confused. Therefore, users prefer the tab in the background _at most_ 28% of
> the time. Once we change the default, the times that people that are mostly
> indifferent will then be include in the "foreground" set, i.e. the set of
> times that people didn't switch back to the original tab.

I buy that the number is the upper margin, I don't by that it's _significantly_ skewed.
Confusion wears off -- we most likely weren't testing users new to Firefox here.
Why would users be indifferent? They should know pretty well whether they would rather keep reading or research a term immediately. Selecting a tab is not a significant burden to accomplish the latter.

> (In reply to Dão Gottwald [:dao] from comment #28)
> > (I.e. disrupting the workflow for a
> > significant minority can be worse than letting a majority take a final step
> > manually.)
> 
> Of course it _can_. We simply have to make a best judgment on the amount of
> disruption vs. convenience that is tolerable. I don't know a magic number.

There's no magic number, but 28% seems rather high to me.

We implicitly made the above distinction from the beginning. Nobody claimed that a majority wants to see the search results later, so clearly that's not the figure the telemetry probe was expected to verify or falsify.

Comment 33

[Dão Gottwald [:dao]]

Attachment: adaptive behavior

automatically selects the tab once the user did so five times in a row

Comment 34

[Daniel C]

(In reply to Frank Yan (:fryn) from comment #24)
> Telemetry confirmed that this was indeed the right fix.
> We found that 72% of the time, within five seconds of selecting "Search
> Google for <selection>", users select the newly created tab with the search
> results.
> 
> I'm going to back out the telemetry bits and re-land this in the next few
> days, unless someone has a reasonable objection.

I had wanted to mention something before the results came in but I didn't get around to it. The results of the Telemetry I don't feel actually mean that something specific should or shouldn't be done. Even if the results show that more people select the tab within 5 seconds than not still doesn't mean that opening in the foreground should be the default. It may seem strange to think that at first, but as Dão implied, you also need to consider the downside for users on both sides.

The current downside for users that want to switch to that tab is that they have to make an extra click.

The downside with this change for users that want the current behaviour is much greater. Disrupts reading, loses place in tab, messes up tab ordering for unread tabs.

I don't believe that people are greatly frustrated by the current experience. I back this up partly by the amount of bugs filed to fix this (not very many) and the amount of people CCed on this bug (a very, very rough indication of the amount of people that want it fixed).

Now, contrast this with the situation when this patch landed for a few days. People were noticeably frustrated.

I think Telemetry can sometimes falsely "prove" that a fix is correct when really it doesn't cover enough aspects. If you added Telemetry for how often people switched to a tab within 5 seconds after it had been opened in the background I expect it would show a high percentage of users do so. I wouldn't expect anyone to propose opening all new tabs in the foreground though.

Comment 35

[Alex Limi (:limi) — Firefox UX Team]

(In reply to Dão Gottwald [:dao] from comment #32)
> There's no magic number, but 28% seems rather high to me.

But this measures the opposite. The majority is *very clearly* going to the tab immediately, and that's what should be the default action. 

Adapative UI for this is not the solution. Changing behaviors silently based on a click threshold is not something we do as a general design pattern. There are many, many reasons to not do this. It's not obvious, it's not expected, and it's not predictable in any way.

Here's what should happen:
1. We land the new default again (opening tab-in-front)
2. We measure the corresponding opposite behavior (how many people switch back to the original tab immediately after opening) once the new default is active.
3. If this number is over 20%, we can introduce a preference. If it's under: this is add-on and/or about:config territory.

Comment 36

[tracy.cooperjr]

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #35)
> Here's what should happen:
> 1. We land the new default again (opening tab-in-front)
> 2. We measure the corresponding opposite behavior (how many people switch
> back to the original tab immediately after opening) once the new default is
> active.
> 3. If this number is over 20%, we can introduce a preference. If it's under:
> this is add-on and/or about:config territory.

Couldn't you add the preference as an about:config option and see how many people change it? In that case the preference would be there when release time comes and the only thing that would need to happen is to set it to true or false as the default depending on the majority of users.

Comment 37

[Dão Gottwald [:dao]]

Limi, Tracy, see previous commts as to why "majority wants" isn't per se a good measure. I can only repeat myself at this point. I think Gavin needs to decide now.

Comment 38

[tracy.cooperjr]

(In reply to Dão Gottwald [:dao] from comment #37)
> Limi, Tracy, see previous commts as to why "majority wants" isn't per se a
> good measure. I can only repeat myself at this point. I think Gavin needs to
> decide now.

I am one of the people that wants it to stay the way it currently is so my main concern is having an option if it does change. Otherwise I could really care less whether it changes or not as I can just change it back.

Comment 39

[Dão Gottwald [:dao]]

I think the change isn't justified, so I'm not primarily interested in discussing whether it requires adding a visible pref. It's still going to piss off users before they would even consider that there could be a pref, not to mention that there are people out there who never actively customize Firefox. A pref isn't the silver bullet.

By the way, a word on the adaptive behavior. This was meant to be a compromise. It surely has its downside; my preference is to just wontfix this bug. (By that I don't mean my personal preference. I don't have one as I never use this feature.)

Comment 40

[:Gavin Sharp [email: [e-mail]]]

(In reply to Dão Gottwald [:dao] from comment #26)
> The reason is that this change disrupts those users' workflow,
> while the status quo merely doesn't automatically take the final step that
> those other users want.

I don't think the disruption to the minority's workflow is significant, or at least not any more significant that the hassle of having to select the tab for the majority - in both cases it's just a matter of selecting another tab.

I think we've probably over-rotated on this a little. I think we should re-land this. I don't think  it's worth re-adjusting the telemetry probe to measure the opposite case. I am ambivalent about adding a hidden pref.

Comment 41

[Frank Yan (:fryn)]

https://hg.mozilla.org/mozilla-central/rev/3af49eca2c77
https://hg.mozilla.org/mozilla-central/rev/58054442448a

Comment 42

[tracy.cooperjr]

(In reply to Frank Yan (:fryn) from comment #41)
> https://hg.mozilla.org/mozilla-central/rev/3af49eca2c77
> https://hg.mozilla.org/mozilla-central/rev/58054442448a

Did this jsut make it so search is now in Foreground? If so will there be a pref to change it back?

Comment 43

[Daniel C]

(In reply to Gavin Sharp (use [e-mail] for email) from comment #40)
> (In reply to Dão Gottwald [:dao] from comment #26)
> > The reason is that this change disrupts those users' workflow,
> > while the status quo merely doesn't automatically take the final step that
> > those other users want.
> 
> I don't think the disruption to the minority's workflow is significant, or
> at least not any more significant that the hassle of having to select the
> tab for the majority - in both cases it's just a matter of selecting another
> tab.

I won't say anything more about what I disagree with that - the previous comments in this bug serve that purpose.

If this decision is final, I really do feel that an about:config pref would be a good idea. I know everyone always asks for prefs for things and usually it's not worth the trouble, but I believe this is different.

Firstly it is a change in behaviour in a high-percentage of cases (28%) where there is a high-chance that the user didn't want to change to that tab (I don't believe that many of these cases are due to the user not being able to locate the new tab within 5 seconds).

Secondly it has some level of dogfood-resistance given some of the people that have objected to the change here.

Thirdly, it is possible to open almost every other type of new tab in the background, either with a pref or by holding down the modifier keys. That does not work in this case.

I personally would be happy with allowing the modifier keys to be effectual along with or instead of a pref.

Comment 44

[:Gavin Sharp [email: [e-mail]]]

Please file a new bug, and CC me!

Comment 45

[Jim Jeffery not reading bug-mail 1/2/11]

While I'm one of the 25% minority that does not want this change, testing with a clean profile and using the latest hourly build from m-c win32 on win7 x64 this patch is not working as intended.  Selecting text and right-click ->search with 'google' the tab loads in background following the pref browser.tabs.loadInBackground , default setting - 'true' , toggling the 'pref' to 'false' opens the tab immediately as this patch proposed to occur no matter what the setting of the pref was. 

So.. patch bit-rotted maybe ? 

Reopening...

Comment 46

[Jim Jeffery not reading bug-mail 1/2/11]

oops - nevermind - grabbed wrong build to test

Comment 47

[alex_mayorga]

(In reply to Daniel Cater from comment #43)
> Thirdly, it is possible to open almost every other type of new tab in the
> background, either with a pref or by holding down the modifier keys. That
> does not work in this case.
> 
> I personally would be happy with allowing the modifier keys to be effectual
> along with or instead of a pref.

Please review bug 696747, I believe is what you meant.

(In reply to Gavin Sharp (use [e-mail] for email) from comment #44)
> Please file a new bug, and CC me!

I've CC'd you on the bug above.

Comment 48

[tracy.cooperjr]

So does a new bug need to be filed to add an about:config pref or is that part of this bug since they both deal with the same bug?

Comment 49

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to tracy.cooperjr from comment #48)
> So does a new bug need to be filed to add an about:config pref or is that
> part of this bug since they both deal with the same bug?

Yes, and CC gavin on it...

Comment 50

[tracy.cooperjr]

Done. Gavin has been CC'd.

Comment 51

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to tracy.cooperjr from comment #50)
> Done. Gavin has been CC'd.

bug number ?

Comment 52

[tracy.cooperjr]

Sorry about that. Bug 727131