172718 - GUI Preference to block link targets

Status: VERIFIED DUPLICATE of bug 184994

(Camino Graveyard :: Preferences, enhancement, P3)

Description

[S Woodside]

This request is to provide a preference option to override link targets that may
be present in the A HTML tag. Basically, targets can be used to open the link in
a new window with target="_blank".

To make a long story short, I find that this is done by web developers in a
random way and there's no way to know before I click on the link what's going to
happen. I want something like this:

[x] Allow web pages to open links in a new window

in the prefs window. So I can turn it off ;-)

Comment 1

[Greg K.]

Probably won't get a GUI pref, but I imagine this may be settable in user.js
somehow.

Comment 2

[S Woodside]

I've heard other people say that the randomness of windows popping up irritates
them as well (on the list I think).

Comment 3

[kmself]

The "Customizing Mozilla" page has a preference setting which overrides targets
opening new windows:   http://www.mozilla.org/unix/customizing.html  

// Override popping up new windows on target=anything.
// This is now accessible in the prefs dialog, under Advanced|Scripts&Windows.
user_pref("browser.block.target_new_window", true);

Comment 4

[Greg K.]

Simon, if that preference works for you, you should transform this bug into a
request for GUI control of it.

Comment 5

[Greg K.]

See also bug 78037. This is probably a dup of that (and a new bug should be filed requesting 
GUI control of it in Chimera).

Comment 6

[S Woodside]

Changed name (was: [RFE] Preference to override link targets)

The user_pref:

// Override popping up new windows on target=anything.
// This is now accessible in the prefs dialog, under Advanced|Scripts&Windows.
user_pref("browser.block.target_new_window", true);

already does this, so this bug is now to add HI for that user_pref.

Comment 7

[Greg K.]

Confirming as an RFE. (I don't know if it'll get done, though.) Reassigning to
Preferences.

Comment 8

[Stuart Morgan]

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

Comment 9

[Samuel Sidler (old account; do not CC)]

I definitely agree with this. Disallowing target is a great idea and a GUI
preference is *needed*. How hard is this? As it's requested so much, what are
the possibilities of getting this in 1.0?

Comment 10

[L. H.]

Look at bug 78037 comment 65 and bug 64560. Users do not know the difference
between window.open() and target so having GUI that only half works is confusing.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #10)
> Look at bug 78037 comment 65 and bug 64560. Users do not know the difference
> between window.open() and target so having GUI that only half works is confusing.

Agreed, but the landing of Aviary's Single Window Mode on the trunk brought the
ability to catch both target and window.open calls.  That's why this bug depends
on bug 274143 (hook up new SWM from the trunk in Camino).

From http://www.mozilla.org/unix/customizing.html#prefs

// Force new windows into tabs
// (Firefox 1.0+ builds have a UI for this pref in the Options dialog)
user_pref("browser.link.open_newwindow", 3);
// Make the above pref apply only to targeted links, not window.open
user_pref("browser.link.open_newwindow.restriction", 1);

Those values need to be 1 and 0, respectively, to make all "new" window types
open in the *same/original* window and to apply to all window.open calls;
there's also some flexibility in the latter to only apply to window.open calls
that don't specify size, etc..  All the values aren't documented on that page
because there's a UI for them in Fx and the Suite, so "no one else needs to know
the behind-the-scenes stuff"

Of course, you'll have to try this in Fx, since Camino needs SWM hookup
yet...and that's not targeted until 1.0.  I'd like it sooner, but there 0.9
needs to ship and there lots of blockers already and hooking up SWM is
non-trivial to some degree as it's been explained to me.

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Duping to bug 184994 since it's in a slightly better state for dealing with exposing any potential UI variations we might want to expose (over that already landed with the initial SWM checkin).

*** This bug has been marked as a duplicate of 184994 ***