324164 - Unify Single Window Mode Preferences

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

Per 308396, unify single window mode preferences in the back end such that tabs-for-external-links and tabs-for-targeted-links share the same value.

Comment 1

[Ben Goodger (use ben at mozilla dot org for email)]

P1. Must not ship another release in the inconsistent state. 

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

P1. Must not ship another release in the inconsistent state. 

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

bugzilla hates me. 

Comment 4

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Will this change mean that instead of the existing prefs:

browser.link.open_newwindow (which affects targeted links)
browser.link.open_external (which affects external links)

there will be only one pref?

This doesn't sound particularly useful - is it easier to change the backend to treat external links as a subset of targeted links?

Comment 5

[Mike Connor [:mconnor]]

bump to beta1, this needs to be worked out with gecko people, since browser.link.open_newwindow is checked in appshell for some reason, even though consumers should be controlling that now.  The pref defaults are consistent, and the prefpanel sets both, so this its just cleanup after the original implementation mess from pre-1.0

Comment 6

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #5)
> The pref defaults are consistent, and the prefpanel sets both, so this its just 
> cleanup after the original implementation mess from pre-1.0

Your comment implies that this is a UI-related cleanup, not a nuts-and-bolts cleanup. If so, is any information available on what the end results will be? 

Comment 7

[Mike Connor [:mconnor]]

Oh, no, its a nuts-and-bolts cleanup for sure!

Comment 8

[Peter Kasting]

The current UI doesn't seem to allow users to set browser.link.open_newwindow to 1 (the option to open in "the same tab/window" has disappeared).  Was this intentional or oversight?  If oversight, can it please be restored?

Also I'm curious as to comment #4 as well, since my 1.5 behavior (and desired future behavior) is that external links open in new tabs, while targeted links open in the same tab.  It seems reasonable to not expose this to the user in UI, but I would hate to see the prefs disappear.

Comment 9

[Mike Connor [:mconnor]]

It was an intentional choice.  The destructive option isn't usually the right option, and it was hidden in the interest of clarity.  As for the external vs. targeted links options, I think that it was a flaw in the original implementation to handle those separately, and I don't feel compelled to continue to maintain separate prefs for those behaviours.  Ben and Beltzner and I discussed this last fall, and agreed that setting those to different behaviours was largely a corner case, and there's always things like Tab Mix Plus to cover those corners.

Comment 10

[Mike Connor [:mconnor]]

load-balancing tabbrowser stuff to sspitzer

Comment 11

[Mike Connor [:mconnor]]

gah.  s/.org/.com/!

Comment 12

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

increasing swag, since I still need to talk to the gecko people.

Comment 13

[Mike Connor [:mconnor]]

pushing out non-critical-path bugs to b2

Comment 14

[Mike Connor [:mconnor]]

Seth, what's the status here?

Comment 15

[Boris Zbarsky [:bzbarsky]]

> since browser.link.open_newwindow is checked in appshell for some reason

It's checked because the tree owner is implementing nsIWindowProvider, and so needs to either provide a window or not.  I'd be happy to have some way of passing off this decision to the browser chrome.  Presumably we'd need a chrome impl of nsIWindowProvider and a way to register it with the tree owner, right?

Peter, the "same window" option is actually not something I would recommend using.  There are crashes that it causes, last I checked.

Comment 16

[Mike Connor [:mconnor]]

Not going to hold Fx2 on this.  As long as the preferences remain in sync as defaults, there's no significant issue in keeping the parallel prefs for one more release.

Comment 17

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

sorry for the bug spam, re-assigning bugs back to default owner if I'm not working actively on them.

Comment 18

[Simon Bünzli]

Attachment: remove browser.link.open_external

What's wrong with just removing browser.link.open_external and using .open_newwindow everywhere? This would at least fix the potential UI issue from bug 358187 while still letting extension authors recreate the pre-Firefox 2.0 state.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

Would love to take it, but won't block on it.

Comment 20

[Worcester12345]

Bummer. What happened to
"P1. Must not ship another release in the inconsistent state."?

Thanks for your continued hard work anyhow.

Comment 21

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

Comment on attachment 268626 [details] [diff] [review]
remove browser.link.open_external

simon, sorry for letting this sit in my queue for so long.  can you ask gavin, mconnor or mano to review this instead?

Comment 22

[Simon Bünzli]

Attachment: remove browser.link.open_external (unbitrotted)

Comment 23

[Worcester12345]

Need to re-up the review request. ("P1. Must not ship another release in the inconsistent state.")

Comment 24

[Simon Bünzli]

Attachment: unbitrotted [Checkin: Comment 26]

Gavin: This is simple code clean-up to match the fact that we've been trying to keep these two prefs in sync since at least Firefox 2.0. Extensions could easily add the behavior back if need be.

Comment 25

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

Comment on attachment 339974 [details] [diff] [review]
unbitrotted
[Checkin: Comment 26]

Filed bug 459313 on fixing QA companion code. We should get this in early to weed out any extensions that rely on this pref.

Comment 26

[Serge Gautherie (:sgautherie)]

Comment on attachment 339974 [details] [diff] [review]
unbitrotted
[Checkin: Comment 26]

http://hg.mozilla.org/mozilla-central/rev/9d82e9adb2ba

Comment 27

[Sergey Yanovich]

How can I get back the behavior that was working for the following:
link.open_newwindow,1
link.open_external,3
?

It was opening clicks in the same window no matter what, but external links were put into new tabs.

Comment 28

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

You can't, without an addon.

Comment 29

[Nochum Sossonko [:Natch]]

sorry about the spam, but what happened to the user-doc, did it ever get set up? (see bug 469082)

Comment 30

[Aaron Adams]

I've been sent over here from bug 469082 (thanks Natch).

And... wait. I'm confused. This was actually an *intentional* change? There's no longer any way to suppress unnecessary new windows without having destructive behaviour from external links? And now there's yet another add-on necessary to restore the sensible, long-standing behaviour I've grown accustomed to since the days of Phoenix?

You'll have to pardon my frustration, but this is beyond silly. *All* I want is control of my user experience; I don't want overzealous site owners setting target="_blank" on every link, spawning window after window or tab after tab. Now, if I want to do that, clicking links in my mail client blows away whatever I've currently got open.

This makes no sense. It's silly. It's dumb. It's "clean-up" at the expense of your users. External links should never, *ever* blow away what's already open in the browser. There's a very good reason for handling links I'm clicking *in the browser* differently from links I'm clicking elsewhere in the OS.

Back to 3.0 I go...

Comment 31

[atzaus]

I usually do not moan about changes but this one just seems silly. It makes perfect sense for a user to want to browse a single website in a single tab and not open a gazillion tabs if the website was using window.open or something else. That was the main function of browser.link.open_newwindow,1. On the other hand combining this with external window prefs does not make any sense because if I am clicking 10 news articles in my feed reader I do not want them to open in the same tab! I know this change might seem trivial to the developers but this is a seriously a big usability issue for the users and you will see more complaints when 3.1 is released. I am not saying that because of this I won't use the next release but this will affect my and probably others' browsing experience. And while you guys are adding major features within the browser us users have to look for extensions to bring back the trivial features that  existed before (like having a new tab button in the toolbar).

Please reconsider this change, I really think this should exist within the browser. 
Thanks

Comment 32

[Γριφεγ]

One problem is that open_newwindow=1 breaks a lot of sites.

The way I see it, HTML/JS/etc should have never allowed such a thing as opening a new window. And some sites are now migrating to "virtual windows" like dynamically adding a div ("lightboxes").

The question is, should Firefox allow its inexperienced users degraded experience on badly designed sites compared to IE, or should Firefox get rid of this hack and degrade experience for the more savvy users?

Which matters more? Not scaring away recent migrants from IE or keeping the mindshare? 

I think Mozilla's focus is the first, and the pro users are supposed to migrate to minority browsers or use hacky extensions. After all, Firefox can't be the new IE while also retaining the qualities of the old Mozilla.

Comment 33

[Chris Ilias [:cilias]]

(In reply to comment #29)
> sorry about the spam, but what happened to the user-doc, did it ever get set
> up? (see bug 469082)

We're waiting for bug 457027 to be pushed to the production server (should be some time next week), then we will be able to update <http://support.mozilla.com/kb/Options+window>.

Comment 34

[Chris Ilias [:cilias]]

user-doc-complete 
http://support.mozilla.com/kb/Options+window?bl=n#tabs_options

Comment 35

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I believe we have to update at least one testcase on Litmus to cover the new behavior?

Comment 36

[Jesper Kristensen]

I would like to propose another solution for this bug.

I upgraded from 3.0 to 3.1b3pre today, and the first thing I noticed was that Firefox was erasing my tabs.

My solution preserves the cleaned up preferences code done by the current patch, but without causing the regression mentioned here and in bug 469082. The regression is fixed by adding three lines of code to browser.js. Please consider this:

In browser.js:4315, replace this:

aWhere = gPrefService.getIntPref("browser.link.open_newwindow");

With this:

if (aContext == Components.interfaces.nsIBrowserDOMWindow.OPEN_EXTERNAL &&
  gPrefService.getPrefType("browser.link.open_external") == gPrefService.PREF_INT)
  aWhere = gPrefService.getIntPref("browser.link.open_external");
else
  aWhere = gPrefService.getIntPref("browser.link.open_newwindow");

If browser.link.open_external is not defined (which it is not by default), browser.link.open_newwindow will be used instead.

Please consider fixing this regression.

Comment 37

[Aaron Adams]

#32, what sites are broken by open_newwindow=1 and open_newwindow.restriction=2? Sites that pop up supplementary controls always specify their size, and pop-ups of that variety are still honoured by those settings.

I completely agree with your point; the browser's native behaviour should respect what those outdated, poorly-designed websites expect to happen. When a window specifies its size or layout, it should be launched as a new window. It's ugly, it sucks, but that's what should happen, or the user will get confused.

It's not those awful JavaScript pop-ups that are the issue here, though; it's the newly introduced inability to suppress target="_blank" behaviour, where a link is indiscriminately opened in a new, untargeted window. Suppressing *those* new windows can't break a website; it simply contains the website to its own window/tab.

I would argue that when most links open in the current tab, but some links on some sites open in new tabs for no apparent reason to the end-user, well, THAT'S confusing.

It's even confusing to me; that's why I've always changed the setting in my about:config. I'm no "pro user" and I have no "hacky extensions," I just happen to think target="_blank" behaviour is in the exact same category as pop-unders. It's sneaky and annoying, and the browser that saved me from that is the browser I adopted. It's a feature, not a bug.

Comment 38

[Jesper Kristensen]

(In reply to comment #37)
> #32, what sites are broken by open_newwindow=1 and
> open_newwindow.restriction=2?

(This might be off topic)

The problem with open_newwindow.restriction is that it does not split the links into target=_blank vs window.open, but into target=_blank + window.open (without features) vs window.open (with features). Any redirection of a window.open into the same tab might break the site, since the parent/child references are broken. An example is my home banking. It uses JavaScript like this (pseudo code):

var otherSite = window.open("https://othersite.com/");
otherSite.doLogin(loginTicket);

Which breaks when the window.open is readirected into the same tab.

But that is a bug with open_newwindow.restriction, which cannot be set to a good value.

Comment 39

[Aaron Adams]

Good to know. So all we really need is a simple method for suppressing the opening of new windows/tabs via target="_blank".

Comment 40

[Boris Zbarsky [:bzbarsky]]

Note that the prefs _used_ to be separated.  I combined them at some point, by putting all the targeting code in a single place.  The fallout was as you observe, for the simple reason that <a target="_blank"> calls window.open() internally.

Comment 41

[Boris Zbarsky [:bzbarsky]]

Oh, and the upshot was that target=_blank targeting didn't work the same as window.open() targeting in various ways, and both were buggy, and would tend to get out of sync with each other.  That's why the targeting code was consolidated.

Comment 42

[Maksymilian Bon]

I agree with  #36.
Current code leads to situation when opening link from external application causes different effects depending on whether firefox is already started or not.
Now its confusing because:
 - firefox running -> opening link from extrenal application replaces active tab
 - firefox not running -> extrenal link opened in new tab

It occurs with following setting:
browser.link.open_newwindow;1
browser.link.open_newwindow.restriction;2

Overriding current tab is very irritating, and doing this or not depending on the state of forefox process is irritating even more. Please resolve this. Otherwise there is no more elegant way to browse in single window.

Comment 43

[Stefan Breunig]

(In reply to comment #28)
> You can't, without an addon.

Can someone point me to a simple addon that achieves this? By simple I mean "not TabMixPlus".

(I still don't get why you made the "open in same tab" feature completely useless though. Opening an external link requires you to open a blank tab beforehand, it gets ridiculous once a friend IMs 2-3 links. A website shouldn't control my tabs.)

Comment 44

[Simon Bünzli]

What you can achieve without an add-on (and please continue the discussion in that thread): http://forums.mozillazine.org/viewtopic.php?p=5440185#p5440185

Comment 45

[Jesper Kristensen]

(In reply to comment #43)
> Can someone point me to a simple addon that achieves this? By simple I mean
> "not TabMixPlus".

See attachment 371285 [details].



And why can't developers give a simple yes/no reply to my comment 36 where I suggest fixing this issue in a way that does not involve backing out this bug?

Comment 46

[kuro68k]

Can anyone explain why this was broken in 3.5? The bug should be re-opened until it is fixed.

Comment 47

[kuro68k]

I agree, this should be re-opened. Clearly a lot of people liked the old functionality (just see the number of threads and replies on the forums).

Comment 48

[kuro68k]

(In reply to comment #45)

> See attachment 371285 [details].

This partially works.

Go to about:config and create browser.link.open_external as an integer value, set it to 3. The set browser.link.open_newwindow to 1. External links now open in a new tab, internal links open in the same tab.

Unfortunately, it is not compatible with Tabs Open Relative :(

Comment 49

[Matt Maurano]

I just upgraded to 3.5 and got stung by this change. I finally tracked it down to this bug and am rather surprised that this was intentional. I don't mean to belabor the discussion, but this bug seems the place most likely to attract positive attention.

I (like some of the commenters above) had been using browser.link.open_newwindow=1 to constrain most clicked links to the same tab, regardless of what the web designer asked for, but with browser.link.open external=3 so that external links opened in new tabs. It's the behavior most consistent with the back/forward paradigm. I don't ask for this behavior to be the default, but it seems reasonable that firefox should accommodate it, as it has in the past.

Comment 50

[kuro68k]

(In reply to comment #49)

That's the crux of it really. The preference should be re-instated and honoured. If that isn't possible for some reason (might break default settings or something) then new replacement preferences should be added.

Please re-open the bug.

Comment 51

[Martin von Gagern]

Adding yet another scenario I used before and seriously miss in my first 10 Minutes of using FF 3.5. I had open_external=2 and open_newwindow=3. The rationale is that I like to keep related stuff in different tabs of a single window, whereas different topics end up in different windows, often on different workspaces.

With my old setting, a new window opened from withing FF, be it through a _blank link or through JavaScript, used to open as a new tab in the same window, as it clearly is related. A link I happen to click on in any application, on the other hand, is not related to any of the pages I'm browsing, so it should open in a new window. I was really happy with that setup.

I can understand the wish to avoid feature overload for the inexperienced user. But providing limited access through the config dialog while keeping additional features available through about:config has been a good path in the past, and should work as well for this item.

I guess I personally will write a wrapper script which adds the -new-window argument to the command line unless -new-tab has been specified, and set that script as my $BROWSER. This aproach is rather hackish, though, so I, too, would ask for this bug to be reopened and vote for browser.link.open_external to be revived in some form.

Comment 52

[Emlyn]

(In reply to comment #51)

This is exactly what I used before FF3.5, it seems to me such an obvious setting, I can't believe that it is no longer possible.
I don't want a proliferation of windows while browsing, so I want new windows to open in tabs, but when an external program launches a link, it should open a new window: there is no way to know which existing window (if any) to open it in, and it is really annoying to be dragged to a different desktop just because I happen to have a window already open there.
I understand not wanting to confuse new users, but please give those of us who want it the ability to set this as we like it.

Comment 53

[Mitar]

I cannot understand why a preference option was removed. I could understand that the default changed but there should still be a way to specify how the user wants to open external links. For example, for me, opening external links in a new tab is a great annoyance as I use multiple workspaces/desktops/spaces and I want Firefox to open a new window in the active workspace/desktop/space and not in a tab in some other window I have to hunt down through multiple workspaces/desktops/spaces.

Comment 54

[Ralf]

I would also like to see this bug reopened. The current behavior is *very* annoying and almost makes me want to downgrade to 3.0. Despite of the web designers intentions I would like to open all links in the current tab (browser.link.open_newwindow=1) except of course those from external applications, which should be opened in a new window (browser.link.open_external=2). Having external applications open links in a random window as a new tab (default setting) is very confusing for the end user. There needs to be a differentiation as it was clearly explained in the comments above.

IMHO both options should be available through the options menu: 
* Open links that are requested to be opened in a new window in [the current tab] | [a new tab of the active window] | [a new window]
* Open links from external applications in [the current tab] | [a new tab of the active window] | [a new window]
I don't think this would be asking too much intelligence from the end users.

Also I'd like to point out, that the target attribute was deprecated for a reason. Therefore I'd make it the default setting to open all links in the current tab despite of what the target attribute says. I know it's radical. Don't hate me. ;-)

Comment 55

[Nickolay_Ponomarev]

I don't think the comments in this bug are read by currently active UX people, so adding comments to this bug will not lead to any changes.

It doesn't seem that there was an answer to the objections from the development team, so I think that there's a chance you'll get it if you post a summary of the objections and the request for clarification in mozilla.dev.apps.firefox.

Comment 56

[John Darrow]

I'm adding to the chorus of others: the loss of the ability to set different behavior for an external-app-opened link vs. a "_blank"/window.open() link opened within a current browser session is a HUGE regression.  My own usage is like that of #51 and #52, and I should _not_ have to track down and load some sort of huge tag-arranging extension to get back what was a deliberately chosen by me via about.config behavior in previous versions.

If the comments in this bug are not currently being read by the active UX people, then someone with access to them needs to drag them back to it, and quick.  Otherwise, there WILL continue to be numerous openings of (duplicate) bug reports for this regression by people who don't know this was a deliberate change.

Comment 57

[Martin von Gagern]

I've created bug #509664 for those who want the old behaviour back.

So instead of (or in addition to) posting a "me too" here, you can vote there.
I personally wouldn't want to vote for the bug here, which removed the functionality in the first place, as I'm not sure how taht would get interpreted.

I also hope that a new, unclosed report will get developers to take notice of this issue.

Comment 58

[Ralf]

Thanks for opening that bug. I voted there and removed my vote here as you suggested.

Comment 59

[Aaron Adams]

The functionality that was lost to this "cleanup" is to be discussed and voted upon in bug 469082; bug 509664 was already closed (not by myself) as a duplicate.

Comment 60

[kuro68k]

FAIL.

Sometimes I think FF succeeds despite the main developers, rather than because of them. As usual user feedback is ignored and genuine issues written off as not being part of the latest brilliant new UI "enhancement" Moz came up with.

Anyway, as per the standard solution to all UI regressions, here is yet another add-on created specifically to bring back the old, sensible and non-destructive behaviour:

https://addons.mozilla.org/en-US/firefox/addon/13626

I have noticed something about FF. Every time there is a new major version number bump, I have to install more add-ons and more css hacks. I wonder, is it is possible to not break things for very large numbers of users next time please? We all like new features, but unless there is some security issue old ones should no be taken away.

Comment 61

[Jeff Walden [:Waldo]]

I recommend acquiring the humility to consider the possibility that you might be wrong; intuition does not always make for the correct choice when designing user interfaces.  Try the new setting for a week or two, then switch back to your preferred setting and give it a shot.  Also consider that what may be right for you may not be right for users in general.  Finally, have you ever described any piece of software as "bloated"?  That comes of death by a thousand cuts, not by big things easily trimmed.

Also worth considering: a little detachment goes a long way in avoiding poisonous arguments which may be worse than the original problem itself.  There are much more important things in the world about which you can get this worked up, with better cause, than these little changes in your browser.

Comment 62

[kuro68k]

Jeff, your attitude is I'm afraid the exact problem I am talking about. I did try it for a few weeks, and it was incredibly annoying. I often ended up destorying a tab I had open, sometimes when I hadn't even clicked anything (e.g. a program opening a web site during an (un)install). The default settings are not much better, and the loss of control over how tabs work in a program I use every day is a "little change" for me.

I'm not sure what you mean with the "death of a thousand cuts" comment. Perhaps you mean that by keeping all these extra preferences in it would bloat the code. The modifications would actually be pretty small, and besides my own point was that FF is getting more bloated for long time users because we keep having to install more and more add-ons and hacks. As you say, there are much bigger and more productive targets for reducing program size than removing a few lines of code for some preferences. It wouldn't affect the UI either as they are all hidden in about:config.

I have looked in to contributing code to FF myself. I even installed Ubuntu in a VM to get a reasonable development environment, but lack of documentation is making it hard to figure out what needs to be reverted. On top of that it seems like a lot of work for something which will be rejected anyway, and an add-on was easier.

Tell you what, if you can guarantee that a patch which restores the removed preferences and behaviour while not affecting the new model and of good quality will be accepted I'll make an effort to create one.

I'd like to make another suggestion too. Why not create a better web site for discussing new features and changes with user. The current developer pages clearly are not working, and never get much publicity. A better site where people can comment and developers really, genuinely listen would solve a lot of problems. I'd set one up myself but to work it would need official backing and promotion. Something like a front page link and RSS feed.

Comment 63

[Aaron Adams]

"I recommend acquiring the humility to consider the possibility that you might
be wrong; intuition does not always make for the correct choice when designing
user interfaces."

Consistency doesn't always make for the correct choice when designing a UI either, Jeff; and consistency is the only motivation behind this change.

Comment 64

[Martin Wildam]

**** happens - I noticed that change now wondering, why my setting does not work any more. :-(((

I had it set this way for good reasons and now the option has been removed...

Comment 65

[BoffinBrain]

If I could vote against this, I would.

It's a shame I always end up finding out about these things after getting frustrated with Firefox and having to search for a reason.  At least Moz had the 'courtesy' of linking to this bug where the about:config documentation is found, so I can find out why Firefox now behaves stupidly, and without a way of letting me revert back.

However, it would have been more courteous to ask people whether they wanted to keep it, first.

This kind of consolidation decreases usability and doesn't improve performance or maintainability in the slightest.

I agree with comment #60

Comment 66

[vsync]

This needs to be re-opened. Leaving the preference (especially as a hidden pref) does not harm anyone.  On the other hand, destroying it as you have done causes harm.

Example:  I use multiple windows, one for each task.  I use tabs for different pages within each task or related window.  When I click a link in my instant messenger it's not related to any of them.  Yet Firefox picks a random window to open it in.  This violates the principle of least surprise.

I couldn't agree more with comment #65:

"It's a shame I always end up finding out about these things after getting
frustrated with Firefox and having to search for a reason.  [...] Firefox now behaves stupidly, and without a way of
letting me revert back."

Comment 67

[sunk818]

I want links I click on from third-party applications to open in the current tab. Using 3.6 causes me to close unmanageable number of tabs after some use.

Comment 68

[Dash]

Removing this functionality was a bad idea.

If you want this functionality restored then I would suggest voting for Bug 509664.

(Not that community/user votes ever lead to anything being done in this project)