264395 - "Force links ... to open in: the same tab" breaks some sites

Status: RESOLVED WONTFIX

(Firefox :: Tabbed Browser, defect)

Description

[Dan M]

Bug 172962 gives the user the option of folding new windows back into the opener
("force links that open new windows to open in the same tab/window as the
link.") Despite this just being a scary and seemingly technically inadvisable
thing to do, it pretty much works. Some things however will not work.

Websites coded to pass data between the opener and opened windows obviously
won't function correctly, since the opener is gone. Sites that will experience
this problem are generally sites that treat the opened window like a dialog.
http://www.magic.gov.uk is an example. There are of course many others. Sites
with complex opening code like this

var w = window.open("about:blank")
w.location = "http://www.mozilla.org/"

won't work, again because the script aborts when the opener window is replaced.
(Note that this:

var w = window.open("")
w.location = "http://www.mozilla.org/"

does work. I was able to finagle that.)

Obviously full-on Single Window Mode has disadvantages and I hope users will
lean toward tabbed Single Window Mode, which doesn't have the same fundamental
inability. It occurs that FoSWM could be fixed if we actually opened the new
window into a new tab, presumably without showing the tab bar. Now both windows
remain open simultaneously and script should work. Close the new tab and the
window reverts to the original window/tab. Navigate away from the new tab and we
know we can close the original tab. (Generally. Multiple layers of "dialogs"
wouldn't work if we were too eager to close the original tab.)

I'm not seriously suggesting we implement this. But it is an issue with full-on
single window/tab mode, and I expect this bug will collect duplicates.

Comment 1

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

So are you suggesting a "stealth" <browser/> which is created specifically to be
referenced using window.opener, for scripts that need to pass such information?

FWIW window.opener is not set correctly anyway for when some JavaScript windows
are diverted into tabs; the Hushmail.com Mail Compose popup that appears when
you compose an e-mail breaks if diverted into a tab, because it needs to pass
data back to the mailbox page using window.opener. Would the fix for setting
window.opener appropriately be part of this bug or part of a re-summaried bug
263844?

Comment 2

[Dan M]

That *is* bug 263844

Comment 3

[David Janes]

I would imagine there are three few practical options to fix this:

1) Warn the user with a message box that some sites may fail when they select
"force links that open new windows to open in the same tab/window as the link.".
This should help push users towards tabbed Single Window mode.

2) Remove the option in the UI. If advanced users want to use this feature then
they can always set it using about:config, but at least it wouldn't trap end
users. Would simplify the updating of the online help too.

3) Set browser.link.open_newwindow.restriction to default to 2. Although this
somewhat defeats the purpose of the feature.

FoSWM is a bit scarry as it defeats the basic purpose of most non-ad popups;
i.e. to have a separate window concurrently open and visible.

Comment 4

[David Janes]

Just to clarify I meant "three practical options to fix this" above. Oops.

Comment 5

[Thomas Rutter]

The functionality to ignore target="_blank" is a very useful and very welcome
functionality until this option was expanded to also affect Javascript
window.open().  The 'ideal' situation - ignoring target="_blank" but allowing
apps that open new windows to do so - is no longer possible since this change.

I see these as two separate features - one which is wholly desirable, and
another which is unwanted.  The problem is that it is not possible to enable the
wanted feature without enabling the unwanted feature.  Adding a new option UI
called "Apply this setting to windows opened by Javascript too" which is off by
default would solve this, but obviously would be impractical for 1.0.

I think that rolling back to the previous behaviour - of blocking
target="_blank" but not window.open() - would be best at this stage.

Comment 6

[Thomas Rutter]

Hidden tabs could potentially cause confusion.  Also, many Javascript
applications require
- Communication between the existing window and the new window
- Both windows visible and usable at once (windows created with window.open()
are not modal)
- Multiple new windows open
- Being able to close the new window, but have the existing window remain

Created bug #264993 which is similar to this bug but doesn't advocate hidden tabs

Comment 7

[Dan M]

Hidden tabs would seem to solve all the objections in comment 6 except "both
windows visible at once," which is of course contrary to the point of exercising
the pref in question, anyway. Comment 5 has nothing to do with this bug; it
belongs in bug 172962. However Thomas to my knowledge you hold a minority
opinion. Moreover, see bug 172962 comment 155.

Comment 8

[Dan M]

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

Comment 9

[David Janes]

I agree with comment 5, except that the mechanism to do this is already in place!

I think this is a very easy change. What should happen (IMVHO) is that "force
links that open new windows to open in the same tab/window as the link."
(browser.link.open_newwindow.ui) should be removed from the UI and left to
advanced users who know the implications.

This should be replaced by an interface for browser.link.open_newwindow.restriction.

This has the following options:

 * 0: divert window.open()
 * 1: don't divert window.open()
 * 2: divert window.open() without features (as in window size, toolbars etc.)

(0 is the current default, although some changelogs mention 2 as being the default).

This shouldn't be too difficult to implement. Requesting blocking.

Comment 10

[David Janes]

I tried to make a patch for this, but couldn't get browser.link.open_newwindow
to set correctly.
If someone tells me where to change this I should be able to get a patch working.

Comment 11

[Dan M]

  1) David, you won't get a UI change approved for Firefox 1.0 at this late stage.
  2) Monitoring of user forums has convinced me that the distinction between
target="_blank" and javascript:open links is lost on the average user. The
...open_newwindow.restriction pref is therefore an advanced user's option
happily excluded from the unextended pref dialog.
  3) If I may put words in your mouths, you and Thomas simply want "open windows
into the same tab" to apply by default only to target="_blank" windows. (Though
Thomas wants it also for new tabs.) I agree this will make websites in general
work better, though this is a partial fix depending on patterns of common usage.
There is after all little technical reason why target="_blank" windows wouldn't
also refer to their openers.
  4) Because of point 3, you're doing your platform a disservice by attempting
to combine point 2 with this bug.

Though I have no user data to back up this assertion, I believe that people who
want to throw the switch to always open new windows into the current window
would throw that switch because they want only one window. A class of exceptions
unpredictable to the average user will dilute the desired experience more than
it will provide increased website compatibility. A UI allowing for control over
the exceptions is an advanced user's UI; the kind of user that installs
extensions, or knows about about:config.

I feel that the quick fix outlined in comment 9 will cause confusion, and is a
partial fix at best. For now I think we're fine with the current state of
affairs. I think most users who have thought to throw the one-window,one-tab
switch will understand when it causes problems and know to reverse it for the
duration of their visit to the problematic website.

The hidden tabs proposal seems a much more elegant and functional solution than
the later proposals in this bug. But I don't expect it to be implemented. The
later proposals seem like a step backward to me, though they have the advantage
of being simpler to implement.

Comment 12

[David Janes]

I tend to agree, this should perhaps be looked at post 1.0 as nothing'll happen
before then anyway.

Maybe the best option (at least for now) is to warn the user before setting
FoSWM, or at least put a caveat in the documentation.

Comment 13

[chris hofmann]

need to look at post 1.0

Comment 14

[logan]

The window.open() + target="_blank" bit is reminiscent of bug 174266, except
there's no empty popup. Just when I was getting used to that being fixed, along
comes another. Arrr! :)

Comment 15

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

I chose to expose the pref controlling the types of JavaScript popups diverted
into tabs in TBP because I knew that despite the "advanced" nature of the
feature, as well as the number of problems and crashes it exposed, that it would
at least be useful to some Firefox users.

Considering that the entire native UI has been disabled for Fx 1.0 because of
the problems it has caused, I wonder whether or not I should follow suit and
reevaluate the options that I have exposed in the TBP dialog.

Comment 16

[Dan M]

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

Comment 17

[Alex Bishop]

Judging by what http://blogs.msdn.com/ie/archive/2005/05/26/422103.aspx says,
IE7 will behave similiar to Firefox with browser.link.open_newwindow.restriction
set to 2. Which seems sensible to me.

Comment 18

[Jesse Ruderman]

This pref has been removed from the Options window, but it's still available as a hidden pref.  See bug 341553.

Comment 19

[Jared Wein [:jaws] (please needinfo? me)]

Forcing links to open in the same tab causes lots of issues that are too hard or impossible to fix. We don't have plans to revisit this feature, and so this bug doesn't have any likelihood of being fixed.

Comment 20

[Stephan Sokolow]

Could you at least give me some advice on how difficult it'd probably be to fix this particular bug and what reference materials I might want to use if, sometime in the next year, I find the time and willpower to make this my first patch (or extension) for Firefox?

Comment 21

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Stephan Sokolow from comment #20)
> Could you at least give me some advice on how difficult it'd probably be to
> fix this particular bug and what reference materials I might want to use if,
> sometime in the next year, I find the time and willpower to make this my
> first patch (or extension) for Firefox?

The fundamental idea behind forcing links to open in the same tab breaks how some parts of the web work. Some websites expect to be able to interact with pages that they spawn. When the original page gets replaced by the new page, this line of communication is removed.

I don't think is anything that can work around this issue.

Comment 22

[Stephan Sokolow]

I'm not so sure. I didn't really have time to re-read and think on the existing comments here, but I've only encountered three situations where the current behaviour is flat-out broken with no workaround short of disabling it or temporarily using another browser:

1. User clicks a javascript: link or form button which expects to open a new window and communicate with the current one via the opener reference.

(eg. The intended workflow in the Django Admin's "add new record" buttons on foreign key fields.)

2. User clicks a javascript: link or form button which expects to open a new window because the server-side technology breaks the back button.

(eg. If you click a PDF download link on http://osap.gov.on.ca/ for printable forms and it doesn't open in a new tab/window, attempting to reload the previous page with the back button fails unless you go back to the top of the site and log in again to reset the stored session state in the underlying mainframe app)

3. User clicks a javascript: link or form button which expects to open a new window and then navigate the current one.

(eg. Opening help or an ad in the popup and then navigating the current window to the item you've requested)

While not the BEST solution if #3 opens an ad, a perfectly good compromise for all three situations which should make sense to users advanced enough to enable the feature is to make middle-clicking possible on buttons and javascript: links.

Now, I'm not saying it should FORCE a new tab like it does on regular links. (That'd be far too complicated when executing arbitrary javascript)

Rather, middle-clicking a button or javascript: link should grant just that action an exception to the single-window/tab navigation policy. (Basically, a variation on how the ad blocker ensures that only user-triggered popups are allowed)

That way, the browser still obeys the user first and foremost (which is the goal of single-window link handling) but the user has the capability to request an exemption in situations where a new tab is desired using the same mechanism already understood to trigger new tabs elsewhere.