111842 - tabbed browser prefs text "load links in the background" misleading

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[Troels Tolstrup]

In tabbed browsings preferences window there is an item labeled "Load links in
the background" which is misleading as all tabs load in the background. What it
seem to mean is whatever or not you want to automatically switch focus to newly
opened tabs. A less confusing phrase could be: "Don't switch focus to new tabs"

Comment 1

[Neil Pryde]

There's only one master or main tab, on a per window basis. This master or main
tab is selected/activated (so focus set to it) and the corresponding view is
visible. 

All other tabs are in fact, more or less, slave tabs and are not
selected/activated (no focus). I guess that 'Slave Tabs' is something to think
about, it would be better, but might still be misleading for end users.

-Neil.

Comment 2

[sairuh (rarely reading bugmail)]

cc'ing jatin for additional phrasing suggestions.

Comment 3

[David Hyatt]

Reassigning to new component owner.

Comment 4

[jag (Peter Annema)]

A few suggestions:

1) [ ] Open tab in background

2) [ ] Select newly opened tab

cc'ing mpt, he might have some suggestions too (other than removing the
tabbrowser feature).

Comment 5

[sairuh (rarely reading bugmail)]

#1 "open tab in background" in comment 4 sounds fine to me.

jatin/marlon/mpt?

Comment 6

[jag (Peter Annema)]

Well, it's also too broad. It only applies to new tabs opened for loading a
(new) page, not to new tabs opened through accel+T.

Comment 7

[Jatin Billimoria]

I feel users are more familiar with the function of "keep on top." So my
suggested wording carries that common verbiage over to tabs:

"Keep a selected tab on top of other opening tabs."

P.S. Context-sensitive help within this pref. will further explain each of these
checkboxes.

Comment 8

[R.K.Aa.]

*** Bug 153382 has been marked as a duplicate of this bug. ***

Comment 9

[alanjstr]

Shouldn't this be UI?

I'm all for "Load tabs in the background" instead of "Load links"

Comment 10

[Lee]

Load new tab under current tabs.
or
Load new tab behind current tabs.
or
Uninterrupted Tabbed Browsing.

Comment 11

[haferfrost]

How about "Focus newly opened tab" or "Activate newly opened tab" or "Focus tab
when opening" or "Activate tab when opening" or "New tab to foreground" (these
would invert the meaning of the switch!).

At the very least change it to "Open tabs in background" , i.e. replace "load
links" with "open tabs". I think that's clearer.

Comment 12

[Max Spicer]

I think the use of "background" should be avoided completely.  To UNIXy people,
anything to do with this sounds as if is referring to processes.  For months, I
assumed that "Load links in the background" was something to do with prefetching
linked pages.  I actually had to resort to reading the help before I discovered
what this feature really did.  I now use it all the time.  The wording
definitely needs changing!

I would suggest that most non-technical users probably don't understand what
focus means, so this is also a no-go.

Another problem with the current text is that is doesn't make it at all clear
that it is only referring to the situation when a user requests that a link is
opened in a new tab.  It sounds like it should apply to all links being opened.

The best I can do is:

"When opening a link in a new tab, keep the current tab selected."

Comment 13

[Kalin Kozhuharov]

Second on Comment #12 : "background" and "focus" are no-go.

Now thinking again, this bug should go to Browser:Preferences, right? Whoever
can do it, please!

The present UI:

=================== Tabbed Browsing============================

 - Tab Display -----------------------------------
| ( ) Hide the tab bar when only one tab is open  |
| (o) Load links in background                    |
 -------------------------------------------------

 - Open tabs insdtead of windows for ----------------------
| (o) Middle-click or control-click of links in a web page |
| (o) Cotrol+Enter in the Location bar                     |
 ----------------------------------------------------------
===============================================================

I thing this bug "Load links in background" first doeas not at all belong to the
Tab Display group. So what about the following UI:


=================== Tabbed Browsing============================


( ) Hide the tab bar when only one tab is open 

(o) Opening a link in a new tab keeps the current tab selected

 - Open tabs insdtead of windows for ----------------------
| (o) Middle-click or Ctrl+click of links in a web page    |
| (o) Ctrl+Enter in the Location bar                       |
 ----------------------------------------------------------
===============================================================

Unrelated to this bug: The name of the key is "Ctrl" not control right? Nobody
writes Alternative instead of "Alt" :-) I was once asked by a newbie "Where is
the control key on my KBD?" Also control-click is something different than
Ctrl+click (note "+"), but simply don't have a control button on my mouse :-)

Comment 14

[Andrew Hagen]

Select has other meanings as well, relating to the selection of text.

Suggest:

When loading page in a new tab, switch to the new tab immediately. 

I agree that changing the text to say "CTRL+xyz" is needed, too.

Comment 15

[Mario Lia]

I like the new UI design as proposed in Comment 12, as well as the change from
"control" to "Ctrl". Perhaps one or both of these issues should be moved to
thier own bug issue?

I agree that "background" should not be used. I also don't like "selected". I do
think most users will understand "focus". I think a good phrase would be
"Opening a link in a new tab keeps the focus of the current tab"

I also think the help for this item should say "Select this to prevent Mozilla
from giving focus to a new tab when using "Open in a New Tab" to open a link."
or
"When using "Open in a New Tab" to open a link, this will prevent Mozilla from
giving focus to a new tab."

Comment 16

[Vedran Miletic]

retargeting

Comment 17

[Jesse Ruderman]

Both of these are better than the current text:
"When opening a link in a new tab, keep the current tab selected." (comment 12)
"When loading page in a new tab, switch to the new tab immediately." (comment 14)

I suggest:
"When opening a link in a new tab, don't switch to the new tab."

It's usually better to avoid negatives in pref descriptions, but I think it's
appropriate here, as long as the default is to switch.

Comment 18

[Jesse Ruderman]

Safari has "Select new tabs as they are created".

Comment 19

[Jo Hermans]

*** Bug 237031 has been marked as a duplicate of this bug. ***

Comment 20

[Tim Meader]

Anyone interested in a patch for this? I'll definitely change the Control text
to Ctrl (that ONLY makes sense), as for the other text, I like the text in #17,
although I might suggest:

"When opening a link in a new tab, keep focus on current tab."

Thoughts?

Comment 21

[Tim Meader]

Attachment: Patch to change the pref's text. Slightly modified from my comment

This fixes the pref itself, as well as the help docs referencing it. I went
with the text "When opening a link in a new tab, keep current tab focus" on
this first shot. I'm starting to like "Opening link in a new tab doesn't change
tab focus" even before I submit this... but I'll get everyone's thoughts.

Comment 22

[Tim Meader]

Comment on attachment 149372 [details] [diff] [review]
Patch to change the pref's text. Slightly modified from my comment

Setting to jag for review

Comment 23

[jag (Peter Annema)]

Comment on attachment 149372 [details] [diff] [review]
Patch to change the pref's text. Slightly modified from my comment

Here's Safari's text: "Select new tabs as they are created". I like that a lot
better than "When opening a link in a new tab, keep current tab focus". Back to
the drawing board I say.

Comment 24

[Tim Meader]

Agreed, the wording was a bit harsh and long winded. However, that text for
Safari indicates the opposite behavior that checking the pref in Mozilla
enables. If anyone agrees that switching to the opposite operation, the way
Safari is, makes sense, I'll make a patch for Mozilla along with Safari's text.

Thoughts?

Comment 25

[Tim Meader]

Actually, thinking about it, Safari's wording isn't quite correct (at least for
Mozilla). "Select new tabs as they are created", in Mozilla's case, would only
apply to tabs created by clicking on a link. This distinction needs to be
indicated in the descriptive text for the pref. Because, if one goes to
File->New Tab, no matter what this pref is set to, that new tab will ALWAYS take
focus.

Comment 26

[jag (Peter Annema)]

Safari behaves the same way as Mozilla, newed tabs always get selected, tabs
opened for links depend on the pref. Safari makes this distinction by having a
descriptive text below the prefs as such:

               [X] Enable Tabbed Browsing
                   [ ] Select new tabs as they are created
                   [X] Always show tab bar

             Cmd-click:  Opens a link in a new tab.
       Cmd-Shift-click:  Opens a link in a new tab and selects it.
      Cmd-Option-click:  Opens a link in a new window behind the current one.
Cmd-Option-Shift-click:  Opens a link in a new window and selects it.

Checking the "select" option swaps the text per pair (making clear that shift
does the inverse of whatever the "select" pref is set to).

I don't suggest we copy them on this. I also don't think we should take their
option text as is, but I think it's safe to use the word "select" instead of
"focus" and we don't have to be overly descriptive.

How about:

  [ ] Select new tabs opened from links

Yes, it's the inverse of what the pref means, but a little code (or these days I
think just a slight change to the .xul) should take care of that.

Comment 27

[Tim Meader]

Will do... I'll give a new patch a shot. To be honest, the main reason I'm
focusing on this is due to Firefox (though it will be nice to get the Suite
fixed too). Especially in that product, the pref "Open links in the background"
is EXTREMELY confusing under the "Browsing" option.

Comment 28

[jag (Peter Annema)]

Hmmm... Didn't Firefox want to also open new windows "in the background" (behind
the current window), possibly based off the same pref? Maybe not. You should
definitely ask them about changing the wording on the pref though.

Comment 29

[Tim Meader]

Yeah, I had mconner look over this bug, to make sure it would be applicable to
Firefox too, he seemed to be fine with your suggested change. I'm going to try
to patch both over the weekend.

Thanks.

Comment 30

[Tim Meader]

Attachment: Second try at a patch. This one reverses the purpose of the pref, along with the new wording.

Got some time today actually, so I went ahead and gave the one for the Suite a
shot. I've changed the var names to reflect the new purpose of the pref, and
I've also updated the help docs accordingly. Compiled this on Linux and it
seems to work fine (checked about:config to make sure pref was set and unset
correctly). My only caveat with this would be in the file
xpfe/communicator/resources/content/contentAreaUtils.js, there is a place where
it checks for "reverseForegroundPref" (switched from reverseBackgroundPref),
and toggles the behavior accordingly. I'm just wondering if there is anything
that switching this will mess up?  A quick check in lxr for
reverseBackgroundPref showed that it only applied to toggling things by holding
down a keyboard key combo. If that's the case, in that it is the response to
user interaction, then that should be fine. The corresponding function
(openNewTabWith) in Firefox doesn't even seem to have that
reverseBackgroundPref value in its attribute list, so I guess if and when I
create a patch for that it should be a non-issue.

Anyhow, hopefully this will get in. Thanks.

Comment 31

[Tim Meader]

Comment on attachment 149516 [details] [diff] [review]
Second try at a patch. This one reverses the purpose of the pref, along with the new wording.

Setting to jag for review.

Comment 32

[jag (Peter Annema)]

Comment on attachment 149516 [details] [diff] [review]
Second try at a patch. This one reverses the purpose of the pref, along with the new wording.

I'm not sure we should change the name of the pref, unless we provide some way
of migrating old profiles to the new pref (it'd be annoying to upgrade to the
latest Mozilla and find it's ignoring your background pref). Instead, I think
all you should do is in pref-tabs.xul add |reversed="true"| to the background
checkbox and change the text in pref-tabs.dtd.

Comment 33

[Tim Meader]

Yeah, I see now that "reversed=true" for checkboxes was fixed back on the 29th
of April, so I guess it can be done that way. I'd MUCH rather change the names
of the vars, since now they just don't make sense. But, if this will get it
actually changed I'll go ahead and do it this way. Have the patch up in a bit.

Comment 34

[Tim Meader]

Attachment: New, smaller, version, using jag's suggested method

This should be what you were looking for. Admittedly it's much simpler, and
thinking about it, I guess the pref itself isn't wrong... I just get an irksome
feeling having something set to "true" when UNchecked. Oh well, compatibility
is important.  Left in the help file changes obviously.  Setting for review
again.

Comment 35

[Tim Meader]

Comment on attachment 149543 [details] [diff] [review]
New, smaller, version, using jag's suggested method

Tested again on Linux... works perfectly.

Please commit this too if you feel it's okay. No CVS account :(

Comment 36

[[e-mail]]

Comment on attachment 149543 [details] [diff] [review]
New, smaller, version, using jag's suggested method

>+<li><b>Select new tabs opened from links</b>: Select this to make Mozilla switch 
>+to a new tab when using &quot;Open in a New Tab&quot; to open a link.</li>
Possible wording issue: I think "switch to the new tab" might be slightly more
grammatically correct here. Mind you I don't like some of the existing wording
either, for instance we never display the wording "Open in a New Tab" on any
menuitem. Nor is it just links that we can open in new tabs...

Comment 37

[Tim Meader]

"Switch to" isn't too bad... jag... your thoughts?

Comment 38

[[e-mail]]

(In reply to comment #37)
>"Switch to" isn't too bad... jag... your thoughts?
Actually I was nitpicking "a" vs. "the" :-P

Comment 39

[Tim Meader]

Attachment: Same patch, small grammar change for Neil.

All fixed ;)  Please someone commit this if they get the chance... then I can
start trying to get this into Firefox too, the place where it's needed even
more.

Thanks.

Comment 40

[Tim Meader]

Comment on attachment 149629 [details] [diff] [review]
Same patch, small grammar change for Neil.

Setting to neil for final review.

Comment 41

[Tim Meader]

Comment on attachment 149629 [details] [diff] [review]
Same patch, small grammar change for Neil.

Submitting to jag for sr.

Comment 42

[Tim Meader]

Comment on attachment 149629 [details] [diff] [review]
Same patch, small grammar change for Neil.

Trying alecf for sr, haven't heard back from jag yet. If I don't hear from
alecf, I'll just reset to jag and leave it alone.  Thanks.

Comment 43

[Tim Meader]

Comment on attachment 149629 [details] [diff] [review]
Same patch, small grammar change for Neil.

Resetting to jag for SR since he's back now.

Comment 44

[jag (Peter Annema)]

Comment on attachment 149629 [details] [diff] [review]
Same patch, small grammar change for Neil.

sr=jag

Comment 45

[jag (Peter Annema)]

Checked in, marking bug fixed.

Comment 46

[Adam D. Moss]

IMHO the 'switch to' wording is better.  The idea of 'selecting' something
(content, text) is already pretty overloaded.

Comment 47

[Jesse Ruderman]

I still think the text should be something like
"When opening a link in a new tab, keep the current tab selected" or
"When opening a link in a new tab, don't switch to the new tab"
because the increased clarity outweighs the extra length.

Comment 48

[Tim Meader]

Well, since the default behavior is not to select the new tab, the pref would be
"When opening a link in a new tab, switch to the new tab" anyhow.

I don't really like that wording though, since I think using "new tab twice in
the sentence doesn't sound all that great.

Comment 49

[jag (Peter Annema)]

Hmm, I'm actually starting to like "switch to" better than "select".

Jesse's suggested text makes sense too, if the user's assumption is that opening
something new (even in a tab) normally puts that thing in the foreground, like
happens with windows.

I think all of these texts are an (nearly equal) improvement on the old text
though. Unless y'all don't mind spending more time and effort on this (usability
testing, anyone?) let's leave it as is and see what the public reaction to this is.

Comment 50

[Tim Meader]

Yeah, I'm starting to like "Switch" better myself.  I'll create a new patch real
quick.

I'm just wondering which is preferred. Personally, I like "Switch focus to new
tabs opened from links", but then "Switch to new tabs opened from links" is
slightly more concise.

I'll just create both and jag can accept whichever (or neither ;) ) one he might
like better.

Comment 51

[Tim Meader]

Attachment: "Switch focus to...." version.

Here's the "Switch focus to..." version. Setting for review to jag.

Comment 52

[Tim Meader]

Attachment: "Switch to..." version

Here's the "Switch to..." version. Setting to jag for review.

Comment 53

[Tim Meader]

Attachment: "Switch to..." version

Would help if I pulled the tree before patching ;)

Comment 54

[Tim Meader]

Attachment: "Switch focus to...." version.

Again... pulling the tree would help.

Comment 55

[Tim Meader]

Comment on attachment 151061 [details] [diff] [review]
"Switch to..." version

Setting to jag for sr, take 2.

Comment 56

[Tim Meader]

Comment on attachment 151063 [details] [diff] [review]
"Switch focus to...." version.

jag sr take 2.

Comment 57

[jag (Peter Annema)]

Comment on attachment 151061 [details] [diff] [review]
"Switch to..." version

sr=jag

Comment 58

[timeless]

Based on the current text, I was going to suggest "Select tab when opening from
link".

this plural stuff bothers me... but the current text isn't tolerable, please
change it.

we read the item, while looking for a well known pref and decided it was
something entirely unrelated and didn't find the pref at all.

Comment 59

[Tim Meader]

First, what does this mean: "we read the item, while looking for a well known
pref and decided it was something entirely unrelated and didn't find the pref at
all."

Second, the current patch in the wings says, "Switch to new tabs opened from links"

Third, the plurals don't bother me.

Fourth, feel free to submit a patch if it bothers you.

Comment 60

[Tim Meader]

Also, the new text is MUCH more clear than the previous text. And this is almost
a non-issue in the suite anyway since it's already under "Tabbed Browsing".

That being said, I don't see why this bug, which states "load links in
background" should be reopened. At the very least the description should be
changed to reflect the text you are having an issue with.

Comment 61

[James Rome]

The "load tabs in Background" selection seems to have disappeared, and I like
using it. Now when I click a link, it always jumps to the new tab. Where dis
this option disappear to?

Build 2004101405

Comment 62

[jlarsen]

James Rome: In newest builds it is "Select new tabs opened from links".

I personally think this is a horrible choice. I stared at the Tabbed Browsing
menu for quite a while before realizing this was what I wanted to choose.

Comment 63

[Stephen Donner [:stephend] Not actively reading bugmail]

*** Bug 304677 has been marked as a duplicate of this bug. ***

Comment 64

[Daniel Brooks [:db48x]]

Comment on attachment 151061 [details] [diff] [review]
"Switch to..." version

looks good. r=db48x

Comment 65

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Did this ever land?

Comment 66

[Ian Neal]

No, it didn't

Comment 67

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Comment on attachment 151061 [details] [diff] [review]
"Switch to..." version

SeaMonkey-only patch

Comment 68

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

The patch is bitrotted.

Comment 69

[Ian Neal]

Attachment: Unbitrotted version of "Switch to.." patch (Checked in trunk and branch)

Unbitrotted version after accesskey and Mozilla->&brandShortName; changes
Carrying forward r/sr

Comment 70

[Ian Neal]

Comment on attachment 202037 [details] [diff] [review]
Unbitrotted version of "Switch to.." patch (Checked in trunk and branch)

Checking in
extensions/help/resources/locale/en-US/cs_nav_prefs_navigator.xhtml;
new revision: 1.30; previous revision: 1.29
xpfe/components/prefwindow/resources/locale/en-US/pref-tabs.dtd;
new revision: 1.11; previous revision: 1.10
done

Comment 71

[Ian Neal]

SeaMonkey-only patch

Comment 72

[Worcester12345]

(In reply to comment #71)
> SeaMonkey-only patch
> 

Does this mean the component should be changed? Or maybe a special notation under status whiteboard or a key word? Is this one finished, or is there more to come?

Comment 73

[Ian Neal]

Comment on attachment 202037 [details] [diff] [review]
Unbitrotted version of "Switch to.." patch (Checked in trunk and branch)

Checking in (branch)
extensions/help/resources/locale/en-US/cs_nav_prefs_navigator.xhtml;
new revision: 1.29.6.1; previous revision: 1.29
xpfe/components/prefwindow/resources/locale/en-US/pref-tabs.dtd;
new revision: 1.10.6.1; previous revision: 1.10
done

Comment 74

[Bill Gianopoulos [:WG9s]]

Well, if this were going to be changed, it would have been nice to at least actually make it more clear and also make it gramitacally correct.

"Switch to new tab if opened from a link" would be much better.

The pural is just wrong.  You cannot have more than one tab selected or swtich to more than one tab at the same time.  So having this be a plural IS what makes it be unclear.

Comment 75

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #74)
> Well, if this were going to be changed, it would have been nice to at least
> actually make it more clear and also make it gramitacally correct.
> 
> "Switch to new tab if opened from a link" would be much better.
> 
> The pural is just wrong.  You cannot have more than one tab selected or swtich
> to more than one tab at the same time.  So having this be a plural IS what
> makes it be unclear.

Go through the rest of the preference panels, and you'll see this is in line with the rest of the application's wording.

The plural is used _everywhere_ (e.g. messages, folders, etc) to indicate a collective, not necessarily plurality for each instance.

That said, I do see your point.  I don't see how people will get confused, though; and if they do, all of the other preference panels should be changed in a similar fashion (note that I'm not suggesting we do that).

Regardless, this is FIXED.

Verified using build 2005-12-20-04 of SeaMonkey trunk on Windows XP.

Comment 76

[Jesse Ruderman]

Continued in bug 324321.