Closed Bug 251770 Opened 20 years ago Closed 20 years ago

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

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Version:
1.0 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: mconnor)

References

(
URL
)

Details

(Keywords: fixed-aviary1.0)

Attachments

(1 file, 1 obsolete file)

Adds UI for the loadBookmarksInBackground pref
3.92 KB, patch
bugs
: review+
bugs
: approval-aviary+
Details | Diff | Splinter Review 
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).
also fails if you select "open link in new tab" for an item in the History Sidebar.
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."
URL: http://testrunner.mozilla.org/test.cg...
Flags: blocking-aviary1.0?
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
(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.
> 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.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
(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?
(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.
(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.
Jody, that's bug 172962, which will hopefully be fixed before 1.0.
Flags: blocking-aviary1.0? → blocking-aviary1.0+
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.
IMO it's still a big mistake not to include the explicit "Open new tabs in
background" pref box now.
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?
I'm not convinced that this is the right thing to do, but here's a patch.

Untested.
Whiteboard: [have patch]
I tested the patch and it works.
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.
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.  
Including two checkboxes would not prevent us from making the defaults consistent.
> 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
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. 
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
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
Attachment #156470 - Attachment is obsolete: true
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?
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+
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
Status: NEW → RESOLVED
Closed: 20 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.

Attachment

General

Creator:
Created:
Updated:
Size: