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

VERIFIED FIXED in Future

Status

SeaMonkey
Tabbed Browser
--
trivial
VERIFIED FIXED
16 years ago
9 years ago

People

(Reporter: Troels Tolstrup, Assigned: jag (Peter Annema))

Tracking

({fixed1.8})

Trunk
Future
fixed1.8

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 8 obsolete attachments)

(Reporter)

Description

16 years ago
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"
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

16 years ago
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.
cc'ing jatin for additional phrasing suggestions.

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1

Comment 3

16 years ago
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
(Assignee)

Comment 4

16 years ago
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).
#1 "open tab in background" in comment 4 sounds fine to me.

jatin/marlon/mpt?
Summary: tabbed browser prefs text "load links in the bacground" misleading → tabbed browser prefs text "load links in the background" misleading
(Assignee)

Comment 6

16 years ago
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

16 years ago
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

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

Comment 9

15 years ago
Shouldn't this be UI?

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

Comment 10

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

Comment 11

15 years ago
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.
QA Contact: sairuh → pmac

Comment 12

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

14 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future

Comment 17

14 years ago
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

14 years ago
Safari has "Select new tabs as they are created".

Comment 19

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

Comment 20

13 years ago
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

13 years ago
Created attachment 149372 [details] [diff] [review]
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

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

Setting to jag for review
Attachment #149372 - Flags: review?(jag)
(Assignee)

Comment 23

13 years ago
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.
Attachment #149372 - Flags: review?(jag) → review-

Comment 24

13 years ago
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

13 years ago
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.
(Assignee)

Comment 26

13 years ago
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

13 years ago
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.
(Assignee)

Comment 28

13 years ago
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

13 years ago
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

13 years ago
Created attachment 149516 [details] [diff] [review]
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.
Attachment #149372 - Attachment is obsolete: true

Comment 31

13 years ago
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.
Attachment #149516 - Flags: review?(jag)
(Assignee)

Comment 32

13 years ago
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

13 years ago
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.

Updated

13 years ago
Attachment #149516 - Flags: review?(jag)

Comment 34

13 years ago
Created attachment 149543 [details] [diff] [review]
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

13 years ago
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 :(
Attachment #149543 - Flags: review?(jag)
(Assignee)

Updated

13 years ago
Attachment #149543 - Flags: review?(jag) → review?(neil.parkwaycc.co.uk)

Comment 36

13 years ago
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...
Attachment #149543 - Flags: review?(neil.parkwaycc.co.uk) → review+

Comment 37

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

Comment 38

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

Comment 39

13 years ago
Created attachment 149629 [details] [diff] [review]
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.

Updated

13 years ago
Attachment #149543 - Attachment is obsolete: true

Comment 40

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

Setting to neil for final review.
Attachment #149629 - Flags: review?(neil.parkwaycc.co.uk)

Updated

13 years ago
Attachment #149629 - Flags: review?(neil.parkwaycc.co.uk) → review+

Comment 41

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

Submitting to jag for sr.
Attachment #149629 - Flags: superreview?(jag)

Comment 42

13 years ago
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.
Attachment #149629 - Flags: superreview?(jag) → superreview?(alecf)

Comment 43

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

Resetting to jag for SR since he's back now.
Attachment #149629 - Flags: superreview?(alecf) → superreview?(jag)
(Assignee)

Comment 44

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

sr=jag
Attachment #149629 - Flags: superreview?(jag) → superreview+
(Assignee)

Comment 45

13 years ago
Checked in, marking bug fixed.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 46

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

Comment 47

13 years ago
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

13 years ago
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.
(Assignee)

Comment 49

13 years ago
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

13 years ago
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

13 years ago
Created attachment 151059 [details] [diff] [review]
"Switch focus to...." version.

Here's the "Switch focus to..." version. Setting for review to jag.
Attachment #149516 - Attachment is obsolete: true
Attachment #149629 - Attachment is obsolete: true

Comment 52

13 years ago
Created attachment 151060 [details] [diff] [review]
"Switch to..." version

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

Updated

13 years ago
Attachment #151059 - Flags: superreview?(jag)

Updated

13 years ago
Attachment #151060 - Flags: superreview?(jag)

Comment 53

13 years ago
Created attachment 151061 [details] [diff] [review]
"Switch to..." version

Would help if I pulled the tree before patching ;)
Attachment #151060 - Attachment is obsolete: true

Comment 54

13 years ago
Created attachment 151063 [details] [diff] [review]
"Switch focus to...." version.

Again... pulling the tree would help.
Attachment #151059 - Attachment is obsolete: true

Comment 55

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

Setting to jag for sr, take 2.
Attachment #151061 - Flags: superreview?(jag)

Comment 56

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

jag sr take 2.
Attachment #151063 - Flags: superreview?(jag)

Updated

13 years ago
Attachment #151059 - Flags: superreview?(jag)

Updated

13 years ago
Attachment #151060 - Flags: superreview?(jag)
(Assignee)

Comment 57

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

sr=jag
Attachment #151061 - Flags: superreview?(jag) → superreview+

Updated

13 years ago
Attachment #151063 - Flags: superreview?(jag)

Comment 58

13 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 59

13 years ago
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

13 years ago
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

13 years ago
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

13 years ago
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.
*** Bug 304677 has been marked as a duplicate of this bug. ***
Attachment #151061 - Flags: review?(db48x)
Comment on attachment 151061 [details] [diff] [review]
"Switch to..." version

looks good. r=db48x
Attachment #151061 - Flags: review?(db48x) → review+
Did this ever land?

Comment 66

12 years ago
No, it didn't
Comment on attachment 151061 [details] [diff] [review]
"Switch to..." version

SeaMonkey-only patch
Attachment #151061 - Flags: approval1.8rc2?
Attachment #151061 - Flags: approval1.8rc2?
The patch is bitrotted.

Comment 69

12 years ago
Created attachment 202037 [details] [diff] [review]
Unbitrotted version of "Switch to.." patch (Checked in trunk and branch)

Unbitrotted version after accesskey and Mozilla->&brandShortName; changes
Carrying forward r/sr
Attachment #151061 - Attachment is obsolete: true
Attachment #151063 - Attachment is obsolete: true
Attachment #202037 - Flags: superreview+
Attachment #202037 - Flags: review+

Comment 70

12 years ago
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
Attachment #202037 - Attachment description: Unbitrotted version of "Switch to.." patch → Unbitrotted version of "Switch to.." patch (Checked in)

Updated

12 years ago
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago12 years ago
Resolution: --- → FIXED

Comment 71

12 years ago
SeaMonkey-only patch
Flags: blocking1.8rc2?

Updated

12 years ago
Attachment #202037 - Flags: approval1.8rc2?

Updated

12 years ago
Flags: blocking1.8rc2?

Comment 72

12 years ago
(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?

Updated

12 years ago
Attachment #202037 - Flags: approval1.8rc2? → approval1.8rc2+

Comment 73

12 years ago
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
Attachment #202037 - Attachment description: Unbitrotted version of "Switch to.." patch (Checked in) → Unbitrotted version of "Switch to.." patch (Checked in trunk and branch)

Updated

12 years ago
Keywords: fixed1.8
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.
(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.
Status: RESOLVED → VERIFIED

Comment 76

12 years ago
Continued in bug 324321.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.