64560 - pref to make window.open() open in the same window

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, enhancement)

Description

[Ben Bucksch (:BenB)]

(Ignoring pop-up ads (bug 29346) for this bug.)

I hate window.open(). I know my browser. If I want a new window, I do a
middle-click. If I happen to want a new window (middle-click), and the site also
wants to give me one via window.open(), nothing happens (or worse, bug 64559
occurs).

Just make window.open() work like an ordinary link. All of the command for links
should be available, and work the same. I.e. if I do a normal click on it, just
load the URL referenced in the window.open call in the current window. I should
be able to open a context menu and "Open in new window", "Copy link location"
(which will copy the link *only*, not the JS around it) etc..

I know, there is the problem in general that the onclick "script" can contain
more than the single window.open call, and open will. In practice, usually only
the window.open call interests me. (Anything else interesting would be
overloading of the action.)

Now, how to implement this? I don't know.

Comment 1

[Ben Bucksch (:BenB)]

> and open will

s/open/often/

Comment 2

[Johnny Stenback (:jst)]

Well, even if I tend to agree with you there's not really a whole lot that can
be done about this, there's just too much history behind window.open() and if we
change that half of the sites out there will break in ways people won't accept.
IMO the only acceptable way window.open can be changed is to put different
semantics behind a pref you can set if you want the "new" behavior but the
normal window.open() call in a fresh mozilla or Netscape installation must
remain as is.

Patches are welcome as always but I doubt Netscape will put any resources into
"fixing" this in the near future. And, window.open() is a *really* useful
method, the problem is that people are abusing it like crazy.

Comment 3

[Ben Bucksch (:BenB)]

> the normal window.open() call in a fresh mozilla or Netscape installation must
> remain as is.

Nothing else intended. This is an opt-in feature for users painfully annoyed by
"misleaded" webdesigners.

Comment 4

[Alfonso Martinez]

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

Comment 5

[Jesse Ruderman]

Adding a "copy real link location" command to javascript links would be about as
impossible as bug 138809.  On the other hand, making the pref "allow web pages
to make links open in new windows" apply to javascript links would only require:
* A flexible fix for bug 55696, "open link in new window" should work for
javascript links.
* A fix for bug 114461, "document.open clobbers js context???".
* Making the entire old document stay around until the javascript is finished
(bug 38486? bug 76495?) in case the window.open is followed by DOM2 copying.

I think this bug should be resummarized as "'Allow web pages to make links open
in new windows' should work for javascript links".

Comment 6

[Alfonso Martinez]

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

Comment 7

[Jesse Ruderman]

For the case where a javascript: link that opens a window and cloneNodes from
the old window into the new window, the testcase in bug 114461 shows that the
old document stays around long enough for this bug to be fixable.  There's still
the problem that the new-window link expects "document.body" to refer to the old
document, but that might not be hard to fix.

Comment 8

[Jonas Jørgensen]

"Allow web pages to make links open in new windows" has been removed (see bug
78037). Restoring original summary.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Luke Ross]

As I suggested in 172595, I'd really like a way to *temoprarily* override
window.open().  Then if you choose to override it, it becomes your problem. 
Most new windows I can stand, but there's times I'd rather it didn't at that
particular time.  A pref is a bit overkill from my point of view.  Any thoughts?

Comment 11

[Torben]

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

Comment 12

[Oliver Stewart]

Following is a copy of what was posted to Bug 103843.  It summarizes what I
personally would like in terms of behavior regarding this bug.  In short, what I
would like is a preference to block all new window requests, including those
made in Javascript, with the option to override as described below.

Also, knowing nothing about the way Javascript is implemented, the way I would
normally approach this would be to have several implementations of window.open,
which are switched out by the preference.  Each would encapsulate the behavior
described by the pref, i.e. opening a new window, opening as a normal link, etc.
 I'm guessing it's not as simple as this.  Thoughts?

--

Ideally, the solution to this would always allow an option to override the
blocking/redirecting behavior.  For example, one could always right-click on a
link and choose, "follow link allowing new windows," to allow whatever
javascript is present in that link to execute, creating a new window if
window.open is called.   Additionally, I would like the option in this case to
allow me to specify whether the link will open into a new window (for those
cases where navigation requires it) or a new tab (the common case) - while
retaining the ability to have most new window requests open into the existing
window/tab (or into new tabs, if that's what I've requested).

Comment 13

[Oliver Stewart]

Clarification: by "block" above, I mean "turn into a normal link."  Sorry for
the possible confusion.

Comment 14

[Shark Daddy (Jonathan L.)]

So... you want a pref that says 'disable window.open'? This might work, but I
think it'd be better to have the opposite of a normal context menu's 'Open Link
in New Window' so that window.open links are have an 'Open Link in Same Window'.
Right?

Comment 15

[Felix Miata]

Just like Netscape 3!!!

Comment 16

[Oliver Stewart]

Well, that would be useful too, for those who normally don't mind new windows to
be opened but want a particular link in the same window.  In my case, I use one
browser window for everything, and never want another window opened for
anything, unless I specifically authorize it (the only time I can think of that
I'd want to do this is for a site that has a particularly useful or necessary
navigation page that only is useful when open concurrent to some other page).

So, my biggest desire is to have window.open() still work, but not actually open
the new window, but rather follow the link in the same window, and do this for
all links unless I specify otherwise.

In other words, have a pref like "Allow links to open new windows," which, when
unchecked, would translate the behavior of window.open() to that of a normal
link - opening in the same window/tab - while still having the option in a
context menu of allowing the javascript to do whatever it wants, or to redirect
the window.open() to open a tab, to handle the case where a page wants to open a
navigation window or something which is actually useful as another window.

Comment 17

[Jesse Ruderman]

Oliver: you don't need special context menu items for overriding the pref
temporarily.  "Open Link in New Window" and "Open Link in New Tab" will work
fine once bug 55696 is fixed.

Comment 18

[tyl2]

I think that Open Link In Same Window is different from In New Tab. They're both
useful, and should both exist.

Netscape 3...

Comment 19

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 20

[Vaclav Dvorak]

This might actually also be a way to solve the opposite problem - see bug 55696
comment 37.

Comment 21

[Gérard Talbot]

I agree that window.open() might be an useful method and that people have been
abusing it like crazy during years [and still today abusing it] but overall,
they badly code links and window.open() calls. I have looked around a lot and I
can't find a single online tutorial on window.open() calls without errors,
mistakes or carelessness regarding accessibility and usability.

For whatever it's worth, I've done some tests on links opening new windows and
the results is crystal clear: pseudo-protocol "javascript:" links are the worse
for Mozilla.

http://bugzilla.mozilla.org/attachment.cgi?id=149849&action=view

Not included in these testing is the returned info when one examine the link
properties of such links. Mozilla will inform the user in the Link Properties
window that all links without a target attribute will open in the same window
when it's not the case, when all these links open a new window.

I think "javascript:" pseudo-protocol links are the worse for many reasons.
Regarding this bug, if it was possible to desactivate javascript for links only
and hope that consequently links would open in the same window, the result would
be devastating: no document would be loaded since the href value is not a
genuine uri to begin with but javascript code.
I personally think mozilla.org should add the pseudo-protocol "javascript:"
links into its evangelism agenda because it sure is defeating the freedom of the
user (with his prefs) and the versatility+customizability of good browsers like
Mozilla.

My 2 cents

Comment 22

[tommi uimonen]

The pref should have the possibility to open new windows to new tabs instead.

At least now I use middle click as 'Open in new tab' and that works for
javascript also (they open in new tab instead of new window)

Comment 23

[tommi uimonen]

> At least now I use middle click as 'Open in new tab' and that works for
> javascript also (they open in new tab instead of new window)

Correction. Quick test shows that javascript won't open to new tab. 

But at least non-javascripted new window openers could be mapped to "open in new
tab"

Comment 24

[Gérard Talbot]

> The pref should have the possibility to open new windows to new tabs instead.
> 

Bug 184994, bug 105547 are exactly about this.

Comment 25

[Tooru Fujisawa [:arai]]

setting browser.link.open_newwindow pref to 1 should work