469082 - Setting browser.link.open_newwindow to 1 causes external links to open in the same tab

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, defect)

Description

[atzaus]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2

If you use browser.link.open_newwindow,1 in your prefs opening any external link (from a Feed Reader, IM client etc) opens in the active tab instead of opening a new one. This behavior changed from 3.1b1 to 3.1b2. In 3.1b1 a new tab was always opened for external links

Reproducible: Always

Steps to Reproduce:
1. Open an external link from an IM Client/IRC/Anything

Actual Results:  
The link is opened in the currently active tab

Expected Results:  
The link should open in a new tab

Comment 1

[Ria Klaassen (not reading all bugmail)]

This seems to work for me; it opens external links the same as normal links and follows the setting for normal links:

value 1 = open in the same tab
value 2 = open in new window
value 3 = open in new tab

Possibly an intentional change, but it's awkward to test when exactly this changed.

Comment 2

[Aaron Adams]

I can confirm this bug also exists on Mac OS X 10.5; I went straight from 3.0 to 3.1b2 and am also affected by this change in behaviour.

As per bug 172962, window/tab re-use is a release blocker because it can cause data loss — anything in the currently opened tab can be blown away when an external link is triggered.

External links should *not* obey browser.link.open_newwindow. To quote the MozillaZine KB: "Some web sites choose to open certain links in new windows. This preference lets you control where to open these links."

"These links" refers to links that *websites* attempt to open in new windows. External applications should not be affected by this setting. I don't know why this changed, but it's been consistent from the Phoenix days right up to the current beta.

I don't want to potentially be rude and set blocking-firefox3.1, but would a developer mind setting that, and changing the platform to All?

Comment 3

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Setting platform to all->all per comment 2. Also, I confirm that 3.0.4 opens external links in a separate tab while internal links reuse the same tab.

Comment 4

[Nochum Sossonko [:Natch]]

INVALID per bug 324164 see the last two comments and other comments throughout, this was intentional.

Comment 5

[Jesper Kristensen]

Attachment: Workaround add-on

This is a simple add-on to work around this bug.

(In reply to comment #4)
> INVALID per bug 324164 see the last two comments and other comments throughout,
> this was intentional.

No. This was a side effect of an intended change to the preference dialog. There has not been a comment saying that the side effect was intented. See my add-on: It implements a fix while keeping the fix from bug 324164.

Comment 6

[Mitar]

I completely agree. I do not understand why remove a preference option. I could understand to make a different default, but removing a preference option when users where using it is a wrong decision.

Comment 7

[Nochum Sossonko [:Natch]]

Since I INVALID'ATED this bug, I'll reopen it and wait for further input. Please do not spam this bug with "I Agree" comments or other useless posts. Use the Voting mechanism to show your desire for this bug.

Comment 8

[Jesper Kristensen]

Attachment: Possible fix

I have attached a possible patch.

Two things it does to fix this bug without regressing bug 324164:

1) The preference is renamed to browser.link.open_newwindow.override.external, so people having accidentally set browser.link.open_external in an older version of Firefox will not be affected.

2) There is a new value 0, which means something like "don't do anything special". This is the default value, so the preference UI will not have to handle this preference, as it did with the old browser.link.open_external. As long as this preference keeps the default value of 0, no behavior of Firefox will change.

I hope someone else will take up the fight of getting this in.

Comment 9

[Ralf]

I'm an end user, not a developer, so forgive me for my question: Can I use your patch by putting it somewhere in my profile directory or does it have to be compiled with the source code of the application? I'd really like to use it until this issue gets fixed by the developers.

Comment 10

[Elmar Ludwig]

> Can I use your patch by putting it somewhere in my profile directory

No, you would need to patch the file chrome/browser.jar in your Firefox installation (or use a chrome override in your profile).

> does it have to be compiled with the source code of the application?

No.

Comment 11

[Ralf]

Thanks for the info. Could you point me to some instructions on the web on how to do this override?

Comment 12

[Jesper Kristensen]

(In reply to comment #11)
> Thanks for the info. Could you point me to some instructions on the web on how
> to do this override?

Use the add-on instead of the patch

(and don't use bugzilla for support)

Comment 13

[Ralf]

The add-in didn't work for me. I'm using the updated Tab Mix Plus now. I don't see another way.

Comment 14

[Martin von Gagern]

(In reply to comment #8)
> I have attached a possible patch.

I really like that patch, and would love to see it included!

I'm not affected by the "open in same tab" issue, but I used to open external links in new windows and internal links in new tabs, so my favorite configuration became unavailable by the advent of bug #324164 as well.

As a consequence I opened bug #509664 to request not only a solution to the "same tab" case, but a reintroduction of the full former flexibility. It seems to me that your patch will give me just that. Rebuild of my FF pending...

So if this patch here gets solved by including that patch, then bug #509664 gets solved along.

Just as a thought: Wouldn't it make sense to have some special treatment for the case of browser.link.open_newwindow.override.external=0 and rowser.link.open_newwindow=1? As external links opening in the same window is probably rather rare, it shouldn't be the default behaviour, even if it is configured for internal links. If some user really wants that setting for external links as well, he is free to set browser.link.open_newwindow.override.external=1 as well.

Comment 17

[kuro68k]

I created an extension which fixes the problem as well as adding opening tabs relative to the current tab:

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

Comment 18

[Aaron Adams]

Your work on that extension is appreciated, Paul.

Unfortunately as I mentioned in another thread, I STRONGLY prefer not to use extensions; I'm a Web developer, and thus need to be reasonably assured my browser's "standard" behaviour is not being impacted by add-ons.

(Also just noting bug 477746 was a duplicate of this bug as well. It's currently listed as a duplicate of a duplicate.)

Comment 19

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

So, I'm having trouble understanding what's happening here. Comment 1 seems correct, as per bug 324164 the new set of values for browser.link.open_newwindow are behaving correctly.

MozillaZine KB may say that third-party applications always open in new tabs; it's wrong. We don't design the browser to what outdated documentation specifies.

If you want to create a value of 4 that acts differently for external applications, I'd consider that patch, but that's a different bug than this one, which is claiming that we're behaving incorrectly.

RESO WONTFIX.

Comment 20

[Aaron Adams]

Okay, great; it's intended behaviour.

Now, how do we discuss whether the intended behaviour is silly? I must be missing the wizardry behind ever, *ever* allowing an external app to destroy data within your own app.

That's what browser.link.open_newwindow = 1 now does; it allows an external app to destroy the browser's current page at any time. If you were working on something in that tab — too bad.

Potential data loss = bad design. Wouldn't you agree?

Comment 21

[kuro68k]

Careful Aaron, you know what the solution to browser.link.open_newwindow = 1 destroying data is: remove browser.link.open_newwindow :(

I'd go further and say it's more than just a problem with that preference. It's a flaw in the entire design of tabs now. By trying to consistency the intelligent and sensible behaviour has been lost.

It reminds me of ISO9000 certification. It doesn't matter if you screw up, as long as you screw up consistently.

Comment 22

[Jesper Kristensen]

(In reply to comment #19)
> If you want to create a value of 4 that acts differently for external
> applications, I'd consider that patch, but that's a different bug than this
> one, which is claiming that we're behaving incorrectly.

Hi Mike.

Could you please take a look and comment in bug 515410?

Comment 23

[Aaron Adams]

To be perfectly honest, I *would* rather see the preference disappear than remain in its current form; as it stands now, it's both useless and destructive, and I can't see why it was left there at all.

Since there's no changing a Mozilla developer's mind once it's been made up, I'll go ahead and agree that browser.link.open_newwindow should have two options: new tab or new window. And there should be another preference to suppress target="_blank" behaviour.

Cleanup achieved, consistency attained, no functionality eliminated, everybody happy.

Comment 24

[John Darrow]

It appears that what's going on here is that the developers mindset is strongly tied to the fact that this is all one code path which they want to treat as one mode (e.g. see the title of bug 324164, "Unify Single Window Mode Preferences", which was the change which led to the situation which is being complained about here), whereas as far as the users are concerned, there are two _completely separate actions_ which lead into that codepath: 1. clicking on an internal link that includes "target=_blank" within an existing browser session, and 2. having an external application send the browser an "open this URL" request.

For the users, myself included, it is entirely desireable to have _separately configurable options_ for what happens in each of those two cases.  Simply adding one more choice to the single option isn't sufficient because not everyone wants the same configuration for these: I, for example, want internal links to open in a new tab, and external links to open in a new window; many others want the internal links to reuse the current tab ("Single Window Mode") but still want external links to use a new tab; some want internal same tab, external new window.  These are only a few examples from what is at least a 3x3 matrix of combinations.

To echo again, while in the developer mindset this was a unification, as far as the users are concerned this was a _regression_, as, where there were previously two separate configuration options which _users were making good use of_, there is now no way for those users to get back their desired behavior without installing a hacky extension (with all the caveats thereof).

Comment 25

[John Darrow]

(Another note to the "well, just live with the extension" mindset: often, this kind of hack extension also brings other baggage with it tied to its creator's particular usage pattern; for example, the addon 13626 also brings the "tabs open relative" behaviour, but I don't like that, I like my new tabs to always open at the end.  Thus, while said extension may "fix" the issue for people who also like that particular behaviour, it doesn't meet the general case.)

Comment 26

[kuro68k]

John makes a good point about how things look from the user's side.

It seems obvious really - as a user, I want to control when new tabs and windows are opened. I don't care if a web developer specifies "target=_blank", I will make that decision myself thanks. That's one of the things I like about FF - you can "take back the web" and not be subjected to the whims of the web sites you visit.

On the other hand, obviously I don't want other programs to be able to destroy my data and tabs. Unfortunately Windows programs can open URLs in a browser whenever they like, even if I didn't click anything. Even when I do click something, I'm clicking it to "open" the link, not "loose my current data/page and do not save".

Comment 27

[PimpUigi]

So basically they aren't going to fix this?

I really want to go back to the old way of doing things...
External links need to open in a new tab, while links that designate new window should open in the same tab.

Comment 28

[kuro68k]

I can't see any reason at all why the old about:config preference could not be re-enabled. Someone should submit it as a patch.

Comment 29

[PimpUigi]

I've set the browser.link.open_newwindow (to 3) preference in my about:config in case the line ever works again.

I sincerely hope that in the future that I can set browser.link.open_newwindow back to 1 in the future.

I hate left clicking links only to have them open in a new tab.
That's what I have middle click for...

Comment 30

[Emil Ivanov]

(In reply to comment #19)

> If you want to create a value of 4 that acts differently for external
> applications, I'd consider that patch, but that's a different bug than this
> one, which is claiming that we're behaving incorrectly.
> 
> RESO WONTFIX.

Bug 515410 requests just that. So I hope this will be reconsidered.

Comment 31

[Travis Evans]

Comment 2 and Comment 20 hit the nail on the head--this is not just a mere annoyance.  It is *data loss* waiting to happen.  It already happened to me.  I recently upgraded to Firefox 3.6.8; upon upgrading, there was no big window or anything conspicuous warning me of the change and its consequences.  Just earlier I was working on a form, then took a brief break and opened an unrelated link in an external application, which before has always opened in a new tab.  I checked the tab, closed it, and later looked for the tab containing the web form.  Where in the heck is it?!  I never knowingly closed it.  Took me quite a while to figure out that the form was in the tab I had closed thinking it was a different tab.  Guess what?  Upon undoing the close and hitting Back, everything I had done on the form on that page was completely gone.

It is generally considered poor usability practice to suddenly change well-established behavior that users have become accustomed to.  It is even less acceptable to silently change it in such a way that users expecting the old behavior are likely to experience data loss as a result.

I do hope that all the developers who agreed to the “preference unification” are prepared for the potential barrage of users being greeted with similar data loss as their first introduction to this change.  I doubt that a first impression like this will do much to promote user acceptance of the change, nor encourage users to continue upgrading Firefox in the future. ;-)

Comment 32

[Marooned]

With the new Firefox 50, great fix by Jesper Kristensen stopped working and the bug reappeared. External links opens in current tab instead of the new one. Any known and working fix/workaround for the new FF?