"open in new tab" still loads link in foreground, in spite of pref setting

VERIFIED FIXED

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
14 years ago
7 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: mconnor)

Tracking

({fixed-aviary1.0})

1.0 Branch
fixed-aviary1.0
Points:
---
Bug Flags:
blocking-aviary1.0PR +
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

3.92 KB, patch
Ben Goodger (use ben at mozilla dot org for email)
: review+
Ben Goodger (use ben at mozilla dot org for email)
: approval-aviary+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
not sure if this would be a dup of bug 215441, b/c the description there seems
to be for older (obsolete) UI.

tested with 2004-07-15-09-0.9 on Mac OS X 10.3.4. tracy mentioned also seeing
this on Linux.

1. go to Preferences > Advanced > Browsing, and make sure the "Select new tabs
opened from links" checkbox is *not* selected. click OK (if needed) to save and
dismiss prefs.

2. [optional, bug still occurs either way] quit and restart firefox.

3. bring up the context menu for a bookmark in either the Bookmarks Toolbar or
the Bookmarks Sidebar, and select "Open in New Tab".

expected: new tab should open in the background.

actual results: new tab opens in the foreground.

note: if I do this for a link within page content, it does work as expected
(loads new tab in background).
(Reporter)

Comment 1

14 years ago
also fails if you select "open link in new tab" for an item in the History Sidebar.

Comment 2

14 years ago
This is a failure with several of our Basic Functional Tests. See
http://testrunner.mozilla.org/test.cgi?run_id=243#710 for the section that
covers these failures. 

Do we need bugs for each location this is inconsistent or can we batch them all
here?

maybe a better summary would be "Bookmarks and History opening tabs in forground
and background methods are inconsistent with links."
Flags: blocking-aviary1.0?

Comment 3

14 years ago
That's because we have two prefs:
browser.tabs.loadBookmarksInBackground (default: false)
browser.tabs.loadInBackground (default: true)
The latter is the one from Tools->Options->Advanced; it's inverted because the
label has changed to the opposite: if you deselect the checkbox, the pref is set
to true. There is no UI for the former pref.

If you want to load bookmarks in the background, you have to set the former pref
to true in about:config.

I like the current behaviour, because I usually want to load links (from Google,
forums, news sites etc.) in the background, but bookmarks in the foreground,
because I usually only open one bookmark at a time. Maybe we should add a
checkbox for browser.tabs.loadBookmarksInBackground, next to the other pref?
OS: MacOS X → All
Hardware: Macintosh → All

Comment 4

14 years ago
Maybe this bug is related:

http://bugzilla.mozilla.org/show_bug.cgi?id=251777

Comment 5

14 years ago
(In reply to comment #3)
> That's because we have two prefs:
> browser.tabs.loadBookmarksInBackground (default: false)
> browser.tabs.loadInBackground (default: true)
> The latter is the one from Tools->Options->Advanced; it's inverted because the
> label has changed to the opposite: if you deselect the checkbox, the pref is set
> to true. There is no UI for the former pref.
> 
> If you want to load bookmarks in the background, you have to set the former pref
> to true in about:config.
> 
> I like the current behaviour, because I usually want to load links (from Google,
> forums, news sites etc.) in the background, but bookmarks in the foreground,
> because I usually only open one bookmark at a time. Maybe we should add a
> checkbox for browser.tabs.loadBookmarksInBackground, next to the other pref?

Why not let the option in tools --> options ... --> advanced set both the
preferences. This is how the default user would use the function. If someone
wants to customise the browser to let browser.tabs.loadBookmarksInBackground and
browser.tabs.loadInBackground act in a different behavior, they can do so via
about:config.

Adding another option to preferences would lead to less accessibility with a
loss of functionality as result.

Comment 6

14 years ago
> This is a failure with several of our Basic Functional Tests.

Just because there's a test covering it doesn't mean that the current behavior
is wrong or that fixing it is important.

> Do we need bugs for each location this is inconsistent or can we batch them 
> all here?

"Fixing" this bug everywhere (or almost everywhere) would be pretty easy thanks
to the patch from bug 246719.  Search lxr for
browser.tabs.loadBookmarksInBackground.

> Why not let the option in tools --> options ... --> advanced set both the
> preferences.

I agree with Steffen that the current default behavior makes sense.  The reason
for opening tabs in the background is to let you continue reading/clicking
links.  That reason doesn't apply when you're opening bookmarks.

We should not simplify prefs at the expense of making our default behavior worse.

Updated

14 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0-

Comment 8

14 years ago
(In reply to comment #6)
> I agree with Steffen that the current default behavior makes sense.  The reason
> for opening tabs in the background is to let you continue reading/clicking
> links.  That reason doesn't apply when you're opening bookmarks.

That makes no sense at all. I can be reading some page and decide I want to open
a slow loading bookmark or bookmark group in the background while I continue
reading my page just as easily as deciding I want to open a link from that page
in the background.

Sure there are subtle contextual differences. I'm coming at this from a "tab"
perspective, not a "link" perspective. Ctrl clicking gives me a background tab.
Ctrl shift clicking gives me a forground tab. I don't care what the source
link/bookmark/history item/menu item/image/whatever was, by pressing ctrl, I'm
asking it to open in a tab and respect my tab opening preference. 

Consistency makes sense for all of these "link-like things".  What users expect
when pressing ctrl and left click (or enter) is that a new tab will be created
and populated and that it will respect their preference for whether or not tabs
are focused or not focused.

This bug matters. We're launching a new browser feature on a population that's
never seen it (hopefully hundreds of millions of IE users) and they won't be
thinking that a link in a web page and a _link_ in their "Links Toolbar" are
different things and should behave fundamentally differently. 
Flags: blocking-aviary1.0- → blocking-aviary1.0?

Comment 9

14 years ago
(In reply to comment #6)
> > This is a failure with several of our Basic Functional Tests.
> 
> Just because there's a test covering it doesn't mean that the current behavior
> is wrong or that fixing it is important.

Except that we explicitely created the test to serve as the specification
because there is no specification. If the test/spec needs to be updated, then
we'll do so but I wouldn't have created the test with that expected results
unless I first considered what the proper result would be.

Comment 10

14 years ago
(In reply to comment #3)
> That's because we have two prefs:
> browser.tabs.loadBookmarksInBackground (default: false)
> browser.tabs.loadInBackground (default: true)
> The latter is the one from Tools->Options->Advanced; it's inverted because the
> label has changed to the opposite: if you deselect the checkbox, the pref is set
> to true. There is no UI for the former pref.
> 
> If you want to load bookmarks in the background, you have to set the former pref
> to true in about:config.
> 
> I like the current behaviour, because I usually want to load links (from Google,
> forums, news sites etc.) in the background, but bookmarks in the foreground,
> because I usually only open one bookmark at a time. Maybe we should add a
> checkbox for browser.tabs.loadBookmarksInBackground, next to the other pref?

I am using the Mac version with 10.3.5 (0.9.3) and would expect the setting to
open a new tab within the current window when selecting a link from an external
application (such as email). Safari does this correctly. Would like to see the
same action in Firefox.

Comment 11

14 years ago
Jody, that's bug 172962, which will hopefully be fixed before 1.0.

Updated

14 years ago
Flags: blocking-aviary1.0? → blocking-aviary1.0+
(Assignee)

Comment 12

14 years ago
Man, I wish I'd read this bug before the conference call.  This behaviour has
been around since at least 0.5, when I started using Phoenix, changing this now
would be insane.  I've read lots of feedback and had the debate many times,
especially when we added the pref to control how bookmarks worked.  I still
believe this is the best for users.

The debate with UE design is always confusion vs. usability.  If making a user
learn the difference between a bookmark and a link in a page results in a better
overall experience for the user, then we should ease that transition, not dumb
down the interface.  Firefox is about smart defaults, and being more usable. 
Dumbing things down to avoid user confusion at the price of better overall UE is
bad.

At most, I'd say have a visible pref for bookmarks as well, with the same
current defaults.

Comment 13

14 years ago
IMO it's still a big mistake not to include the explicit "Open new tabs in
background" pref box now.

Comment 14

14 years ago
This bug has localization impact because it either involves changing the meaning
of an existing pref or adding a new pref.
Flags: blocking-aviary1.0PR?

Comment 15

14 years ago
Created attachment 156470 [details] [diff] [review]
Patch that makes loadInBackground apply to UI links

I'm not convinced that this is the right thing to do, but here's a patch.

Untested.

Updated

14 years ago
Whiteboard: [have patch]

Comment 16

14 years ago
I tested the patch and it works.

Comment 17

14 years ago
So you want to make me suffer because new users may not understand the
difference between links and bookmarks? That's definately not the right thing to
do :)

Let's just add a checkbox for browser.tabs.loadBookmarksInBackground. That would
make everyone happy. And it's trivial to do, see bug 255932.

Comment 18

14 years ago
This isn't about dumbing down. It's about consistency. Users expect ctrl+click
to behave the same whether it's on a bookmark, a history item, a link in a page,
or a personal toolbar item. Users expect ctrl+shift+click to have the same
behavior in each of these cases. It's geeks that want to treat all these like
they're different features, but they're not, they're all links that the user
clicks on or ctrl+clicks on to open or open in tabs. IE calls the bookmarks
toolbar the "link toolbar" because most people think of all of these things at
links. It's only geeks like us that try to make a distinction and want
specialized behavior for each of these "link" clicking behaviors.

Also, just because we have some particular (and hacky) backend pref breakup here
doesn't mean we want our frontend to be inconsistent.  

Comment 19

14 years ago
Including two checkboxes would not prevent us from making the defaults consistent.

Comment 20

14 years ago
> Including two checkboxes would not prevent us from making the defaults consistent.
I have no problem with setting both prefs to true by default, with or without
adding UI for browser.tabs.loadBookmarksInBackground, as long as I can still set
them the way I like. I'm in favour of adding a checkbox though.
So we seem to agree that we do not want to remove prefs, we may want a third
pref for from-history loading, and we simply want the same default value for all
prefs.  We could add UI, but it's not required by power-users who've spoken up here.

/be

Comment 22

14 years ago
trying reconstucting history of this there are comments in 
and http://bugzilla.mozilla.org/show_bug.cgi?id=175629#c6 
http://bugzilla.mozilla.org/show_bug.cgi?id=175629#c6 
that apply.

Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
So what was the decision here? What am I supposed to do again? I forgot. 

Comment 24

14 years ago
I believe we want consistent behavior with all new tabs from "links" opening in
the background with a pref for power-users to break the consistency and have
their bookmark-launched new tabs load in the foreground.
Right, a UI pref so people can change the default for bookmarks -- but no
changes to any of the default prefs we've shipped, this close to 1.0.

/be
(Assignee)

Comment 26

14 years ago
Heh, the last two comments totally contradict each other.

I'm in complete agreement with Brendan in not changing the prefs, or the
defaults we've been shipping with since at least Phoenix 0.5.  Trying to argue
about the mindset of a typical user and what's consistent or not doesn't belong
in the run-up to a 1.0.  It belongs in a 0.7 or 0.8 cycle.

Removing have patch status whiteboard bits, since the patch we have doesn't do
what we want, and taking to create a proper patch, should be up in four hours
(need to run out right now).

Also minusing for 1.0, since this is really a l10n impact bug.
Assignee: bugs → mconnor
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Whiteboard: [have patch]
Either Asa misremembered, or I misread him to agree with what I recalled from
the meeting.  We very clearly reasoned that we cannot change defaults at this
point. We also reckoned that there ought to be UI for both prefs.  Period, end
of story.

Mconnor, thanks for taking this!

/be
(Assignee)

Comment 28

14 years ago
Created attachment 158154 [details] [diff] [review]
Adds UI for the loadBookmarksInBackground pref
(Assignee)

Updated

14 years ago
Attachment #156470 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Attachment #158154 - Flags: review?(bugs)
Attachment #158154 - Flags: approval-aviary?
Comment on attachment 158154 [details] [diff] [review]
Adds UI for the loadBookmarksInBackground pref

but do you also need to set the default value of the bookmark pref to match the
other one? 

and does this need to land with some combination of jesse's patch for the
history sidebar?

Comment 30

14 years ago
Brendan's right. I was wrong. The idea is to have the pref so we can change it
(from inconsistent to consistent) if we find out that inconsistency here is a
bad thing. The default behavior will remain inconsistent for now. We'll educate
users that this isn't about how tabs behave, it's about how these various
link-like things behave and they shouldn't expect them to be consistent.
Comment on attachment 158154 [details] [diff] [review]
Adds UI for the loadBookmarksInBackground pref

r+a=ben@mozilla.org
Attachment #158154 - Flags: review?(bugs)
Attachment #158154 - Flags: review+
Attachment #158154 - Flags: approval-aviary?
Attachment #158154 - Flags: approval-aviary+
(Assignee)

Updated

14 years ago
Keywords: fixed-aviary1.0
confirmed pref added on Windows Firefox Branch 2004-09-10-08-0.9 and Mac Firefox
Branch 2004-09-10-07-0.9
(Assignee)

Updated

14 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
verfied on FF trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.