275430 - change default for "open links from other applications" to be "a new tab in the most recent window" instead of "the most recent tab/window"

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[(not reading, please use [e-mail] instead)]

[rfe] change "open links from other applications" to be "a new tab in the most
recent window" instead of "the most recent tab/window"

in other words, change browser.link.open_external to be 3 in all.js, instead of 1

I think this is the only pref I have changed in firefox.

Let me explain why I'm requesting this change:

I usually don't know which is the "the most recent tab/window" without checking
first.  with the default value for this pref, I usually have to create a new
blank tab before I will click on a link in another application, for fear that it
will replace something I'm in the middle of reading (or submitting).

I wonder if others have the same experience?  Now that I've changed this pref, I
am one happy customer.

danm and ben, what do you think about changing the default?

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: screen shot of the pref I'm talking about

Comment 2

[Mike Connor [:mconnor]]

I'm in favour of this, myself, I'm not sure why we overwrite existing pages by
default, that seems a little suboptimal to me.  I was on hiatus during the
hammering of this patch, so I'm not sure what the rationale was, but adding a
tab to the most recent window seems like the best plan.

Comment 3

[Dan M]

What, this is your *only* non-default pref setting? Wow! Personally I set this
one to open external URLs in a whole new window. Its current default value was
chosen because it replicates the original default; the old
advanced.system.supportDDEExec pref.

Support forums are full of people repeatedly asking how to set the default both
ways. I feel certain that any choice of defaults will be wrong to somebody.
Personally I really couldn't care less what the default is, since I have my
override. I'd just like to have some assurance that the reason to explicitly
change the old default behaviour is better than the reason not to.

Comment 4

[(not reading, please use [e-mail] instead)]

danm:  as for why I'd want to change the default, it would be the reason mike
that mike said:  "we overwrite existing pages by default".

it would be a one liner to fix, but I'll leave it to the firefox leads to decide
if they want the change.

I'll add blocking 1.1 to get in onto asa's radar.

Comment 5

[Dan M]

The counterargument goes, some people are confused by multiple windows, and
maybe we should make multiple windows an explicit choice of the user. Once
(several years ago) I showed a friend how it was sometimes more convenient to
open a link in a new window, leaving the old one untouched for a later return.
To him, browsing was using IE in a maximized window, nothing more. I think this
attitude is (still!) fairly prevalent among Windows users. I have a notion that
we should leave browsing in a single window by default. But I'm not strongly
attached to either option.

Comment 6

[Mike Connor [:mconnor]]

A new tab in the most recent window avoids the issue of multiple windows.  It
also naturally exposes tabbed browsing, and avoids the potential (minor) problem
of replacing a form entry that can't be accessed via Back.

If tabbed browsing is too much of a concept to absorb, I don't think people will
be using Firefox.  The tabbed metaphor is used widely enough that I think we'll
be okay with it on by default.  Right now, context menu search always opens in a
new tab, and I have yet to see a complaint about that.

Comment 7

[Jez]

CCing self.  I shall submit a proposed patch to fix this.

Also a new bug needs filing for Seamonkey; this precise problem exists there too.

Comment 8

[Tuukka Tolvanen (sp3000)]

I'll butt in in favor of opening external links in new windows :)

re danm's comment 5: You told your friend about opening links /in the browser/
in new windows? I'd argue that is a different thing. When Joe User opens a
document from outside the app handling that document -- say, a Word file from
the filesystem Explorer for instance -- usually a new window opens associated
with the document. Surely opening a new window associated with the opened
document is the expected and understandable behavior here as well.

re mconnor's comment 6: Perhaps introducing the user to new ui features in a
prevously obscured window in response to a user action in another application is
not /that/ natural :) unlike the context menu search case where the new stuff
happens in the window the user is manipulating.

As a personal preference data point with perhaps less import on selecting a
default: I use tabs heavily but like to keep browsing contexts so to speak in
separate windows. I don't want external app links to mess with the existing
ones, with new tabs or otherwise.

Comment 9

[Jez]

Attachment: Patch to make externally-launched links open in new tab

Comment 10

[Jez]

Attachment: Patch to make externally-launched links open in new window

Comment 11

[Jez]

Submitted a couple of patches to change behaviour to opening links in a new tab
or new window.  Needless to say that, because this is a trivial pref change,
there is zero chance of it breaking anything.

I'll try and find out which product this should in fact be filed under (all.js
is used by more than just Firefox) and get a review? .

Comment 12

[Michiel van Leeuwen (email: mvl+moz@)]

imo, this pref should live in firefox.js

Comment 13

[Jez]

Attachment: Patch to make externally-launched links open in new tab (FF only)

Comment 14

[Jez]

Attachment: Patch to make externally-launched links open in new window (FF only)

Comment 15

[Jez]

(In reply to comment #12)
> imo, this pref should live in firefox.js

OK, point taken, new patches submitted.

The next step, I guess, is to spring a bug for this problem for the Moz
Application Suite product, and fix the baheviour there too.  For now, this patch
will change the behaviour of FF and the Moz Suite will continue to get the pref
from all.js.

Comment 16

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

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

Comment 17

[Jez]

Have sprung a new bug, bug #286745, for this same behaviour in Seamonkey to be
fixed.

Comment 18

[Jez]

Scrubbed those patches for now - we may want to also change all.js at the same
time, if the Seamonkey pref patch makes it in first (as it probably will).

Comment 19

[Dan M]

I've expressed my opinion on making this tiny bug into two separate bugs in the
new one. I'd like to repeat my opinion that two unique sets of two competing
versions of the same patch is a lot of noise for one tiny bug.

Ben has already marked this bug as blocking aviary 1.1. That means he plans to
do something with the bug. He hasn't yet said which way he wants to implement
it. Let's not fill this bug up with every possible patch while we wait for his
decision.

Comment 20

[Jez]

(In reply to comment #19)
> I've expressed my opinion on making this tiny bug into two separate bugs in the
> new one. I'd like to repeat my opinion that two unique sets of two competing
> versions of the same patch is a lot of noise for one tiny bug.

That's what I said initially, but was advised to spring a new bug by Michiel van
Leeuwen on IRC.

> 
> Ben has already marked this bug as blocking aviary 1.1. That means he plans to
> do something with the bug. He hasn't yet said which way he wants to implement
> it. Let's not fill this bug up with every possible patch while we wait for his
> decision.

Right, like Ben is gonna get it done in a timely fashion.  Why the hell should
this be the attitude for every little change in Firefox?  No wonder people are
**** off with the development process.  Why do you people even pretend to
allow 'anyone' to submit, and get checked in, a sensible and working patch?

Comment 21

[Dan M]

Not every patch is sensible, whether or not it works. After six abortive
attempts, I'd be thinking of taking a step back. Further, I don't see the
advantage to posting every possible version of the patch, and then waiting for
Ben to pick. Finally, I'd appreciate it if you'd watch your language, son.

Comment 22

[Jez]

The initial 2 patches would've changed the pref in all.js, as you seemed to want
to happen.  Then I was advised not to do that.

I only posted 2 patches for convenience.  You want my preference?  Open in new
window.  Would it have been less worthy of disapproval if I'd only posted that one?

Comment 23

[Dan M]

(Summarizing an off-line discussion among all interested parties): we've decided
that all.js is still the best place for the set of four browser.link prefs. It's
probably best then to resurrect one of the first two patches and ask Ben for his
review.

Comment 24

[Jez]

OK well I've gone for the default behaviour to be 'open in new window', for
several reasons.

- It's the nicest behaviour for me personally, and what I have set at the moment.
- It doesn't risk confusing a user with tabbed browsing if they've never used it
before (indifferent though I am to the 'ignorant newbie' arguments)
- It creates a new 'browsing context', ie. window, for externally-launched links
by default.  This is probably what you want, as a link clicked in another app is
rather unlikely to relate to stuff open in a current browser window.

r?/sr? from Ben, but I've never seen him do anything on Bugzilla before.  Would
a more active peer be as good?

Comment 25

[Mike Connor [:mconnor]]

Comment on attachment 177848 [details] [diff] [review]
Patch to make externally-launched links open in new window

New tab makes the most sense, and that's what the bug summary calls for.  If
Ben was going change the bug and pick new window, he'd have changed the summary
when he plussed this.

Comment 26

[Dan M]

The problem with this bug is, everyone has an opinion. Unless someone wants to
appoint himself UI owner, how about we just allow Ben to speak his own mind.

Comment 27

[Jez]

(In reply to comment #25)
> (From update of attachment 177848 [details] [diff] [review] [edit])
> New tab makes the most sense, and that's what the bug summary calls for.  If
> Ben was going change the bug and pick new window, he'd have changed the summary
> when he plussed this.
> 

Mike,
I'm not sure it does make most sense.  I'd still be happier if it was that than
the current behaviour, however could you (as I do now) ask Ben to read my
comment #24 and rebut? :-)

Comment 28

[Mike Connor [:mconnor]]

Why does this pref live in all.js?  Seamonkey trunk doesn't respect/use this
pref at present, Its still app-specific prefs even if they add support, whether
its MAS or Firefox, so it shouldn't be in all.js at all.

Unless someone enlightens me as to why this has to live somewhere it shouldn't,
I'm just going to move these Firefox-specific prefs into the right place, make
the changes, and be done with this bug.

Comment 29

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

(In reply to comment #28)
> Why does this pref live in all.js?

Seamonkey does use this pref. See
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/navigator.js#440

Comment 30

[Mike Connor [:mconnor]]

Ok, I missed that in my lxr searching.  It didn't work when I tried it on my
local Seamonkey nightly though.  I'm still unhappy that core code depends on any
browser.* pref to be defined, but since I can still just make a choice for
Firefox without further pissing matches, I'll do that.

further note: browser.link.open_newwindow.ui should be removed, it was an aviary
branch invention, obsolete now.

Comment 31

[Dan M]

Mike, you're new to this bug. We've already figured all this stuff out and you
would be out of line moving these prefs to a different file. Why did you take
this bug from Ben? It's a highly contentious bug, and in the end Ben is the only
one with the authority to  make a decision. I'm disinclined to trust the opinion
of anyone who announces that his "makes the most sense" and I insist that
whatever decision you make, you run it by Ben before checking it in.

Comment 32

[Mike Connor [:mconnor]]

Considering that I commented on this bug two hours after it was filed, and I'm
still listed as the QA contact, the "new to this bug" thing is pretty wrong. 
Ben is simply the default assignee, if he was working on this it'd be ASSIGNED
and have a priority set.  You're also not in a position to demand that I do
anything as it pertains to Firefox.

If we leave this pref in all.js and make changes there, we're imposing our will
on Seamonkey, and forcing them to override if they don't agree, and we're also
in theory subject to the whims of whoever can r+sr changes to all.js.  Ceding
control of Firefox's user experience because of an implementation detail (core
depends on this pref being set, with no fallback) is not an acceptable situation.

The right fix, of course, is to address the dependency of core code on
browser.link.* prefs by providing a proper fallback, and splitting the prefs to
browser-prefs.js (Seamonkey) and firefox.js.  I can of course do that, I just
wasn't inclined to spend time cleaning this mess up.

Comment 33

[Jez]

Mike,

Before you go any further, bear in mind that Neil is probably going to check in
the patch to bug #286745 soon, which makes Seamonkey have its own pref for this.
 What we need to do now is put some sensible behaviour in all.js (this will no
longer affect Seamonkey for the reason stated above), either open in new tab or
new window, and if you really feel the need, add the pref to firefox.js *in
addition* to the aformentioned.

Comment 34

[Mike Connor [:mconnor]]

No, like I said, what we need to do now is make sure core code doesn't require
the presence of these prefs, and move them into app-specific places.  That's
been spun off into bug 287086, if you have valid objections to this, please take
them there.

This bug will be resolved once that one is.

Comment 35

[Mike Connor [:mconnor]]

Fixed by the checkin for bug 287086.

Comment 36

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change