[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?
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.
Version: 1.0 Branch → Trunk
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.
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.
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.
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.
14 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1+
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.
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.
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? .
imo, this pref should live in firefox.js
(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.
OS: Windows XP → All
Hardware: PC → All
Summary: [rfe] change "open links from other applications" to be "a new tab in the most recent window" instead of "the most recent tab/window" → change "open links from other applications" to be "a new tab in the most recent window" instead of "the most recent tab/window"
*** Bug 271583 has been marked as a duplicate of this bug. ***
Have sprung a new bug, bug #286745, for this same behaviour in Seamonkey to be fixed.
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).
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.
(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?
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.
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?
(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.
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 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.
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.
(In reply to comment #25) > (From update of attachment 177848 [details] [diff] [review] ) > 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? :-)
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.
Assignee: bugs → mconnor
(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
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.
Status: NEW → ASSIGNED
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.
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.
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.
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.
Fixed by the checkin for bug 287086.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Summary: change "open links from other applications" to be "a new tab in the most recent window" instead of "the most recent tab/window" → 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"
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
You need to log in before you can comment on or make changes to this bug.