78037 - (linkNewWindow) Ability to prevent links from opening in a new window

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, enhancement)

Description

[Tom van Wietmarschen]

Some pages set the target to _blank so the link will open in a new window, on some pages where I follow a lot of links this wastes a lot of desktop space and I'll have to close all the excess windows.

I'd like a way to prevent a link from opening in a new window similar to the middle-mousebutton to open 'normal' links in a new window.
maybe the middle mousebutten could be made to invert the behaviour of a link. 
e.g. when it's a link which should open in a new window and I press the middle mousebutton => it opens in the same window and vice versa.

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[timeless]

Doesn't belong to preferences backend.  Might be a dupe.

Comment 3

[Chris McAfee]

over to nobody

Comment 4

[Justin Kerk]

Probably the best way to do this would be to change the "Open in New Window"
right-click link to "Open in Same Window" if the link would already open in a
new window. Just my $.02...

Comment 5

[R.K.Aa.]

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

Comment 6

[Jonas Jørgensen]

Is this bug just about adding UI for user_pref("browser.target_new_blocked", 
true); ?

Comment 7

[Jonas Jørgensen]

Attachment: first attempt of a patch

Try this patch. It will add a "Make links open in new window" checkbox to
Preferences|Advanced|Scripts & Windows. It is not the ideal solution since you
won't be able to change this preference unless JavaScript is on, which you
should be ablo to, since this doesn't have anything to do with JavaScript, but
other than that, it works.

What do you think?

Comment 8

[Jonas Jørgensen]

Uhm, I just attached a patch to this bug, but I got the following error:

Attachment #66672 [details] [diff] to Bug # 78037 Created
Error calling processmail (bug id is not an integer)

Anyway, there's a patch now. Check it out! :-)

Comment 9

[Jonas Jørgensen]

Attachment: new patch

The same as before, except that now "Make links open in new window" isn't
grayed out when JavaScript is disabled.

Comment 10

[Jonas Jørgensen]

Reporter: What do you think of this solution (being able to specify in
Preferences that links should always open in the same window regardless of
target="whatever")? If this was checked in, would you still want the
middle-mouse-button-inverts feature, or would this be enough?

Comment 11

[Jonas Jørgensen]

sgehani: Bugzilla tells me you might be the right person to review this. If you
are, could you review the patch, or otherwise point me to a more suitable
reviewer? Thanks.

Comment 12

[Samir Gehani]

I think Jatin should review the wording changes and Doron should review changes
to the script prefs panel.

Comment 13

[Doron Rosenberg (IBM)]

could you attach a screenshot?

Comment 14

[Jonas Jørgensen]

Attachment: screenshot; modern; javascript enabled

Comment 15

[Jonas Jørgensen]

Attachment: screenshot; modern; javascript disabled

Comment 16

[Jonas Jørgensen]

Doron?

Comment 17

[Boris Zbarsky [:bzbarsky]]

The changes look fine, except for the phrasing.  The pref does nothing to stop
window loads targeted at nonexistent named frames and does nothing to stop <a
href="javascript:window.open()">.  So the preference will be perceived as buggy...

Comment 18

[Jonas Jørgensen]

target="foo" is blocked, but you are right about window.open.

Jatin?

Comment 19

[Doron Rosenberg (IBM)]

patch looks fine. As for window.open, you could create a new pref to make
window.open open the link in the current window (c++ fun, just like I am doing
in my my backend rewrite)

Comment 20

[Jonas Jørgensen]

Wouldn't that kinda be bug 64560? It's too complicated for me.

Comment 21

[Jonas Jørgensen]

Jatin: Any comments on the wording?

Comment 22

[Jatin Billimoria]

I suggest removing "Make" and rewording as follows:

[x] Open a link in a new window (requires restarting [browser variable])

Comment 23

[Jonas Jørgensen]

Attachment: updated with jatin's wording

r=/sr=, anyone?

Comment 24

[Keyser Sose]

Jonas might want to email some people in the module on the list
http://www.mozilla.org/owners.html For a review.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 70736 [details] [diff] [review]
updated with jatin's wording

r=bzbarsky

Comment 26

[Alec Flett]

Comment on attachment 70736 [details] [diff] [review]
updated with jatin's wording

The patch looks fine, but if we're going to make this pref more public, let's
give it a better name.

let's try to avoid the passive voice in prefs...and let's put this into a
namespace below "browser." Finally, what's a "target" in the browser world.
let's be explicit that this is about window targeting.

suggestions:
browser.block.window_target_new
browser.block.target_new_window

sorry to block this patch over that, but there are only two other lines in
mozilla that you need to change to use a reasonable pref:
http://lxr.mozilla.org/seamonkey/search?string=target_new_blocked

Comment 27

[Jonas Jørgensen]

Attachment: change the pref name to browser.block.target_new_window

...but be warned: I did not test this patch, nor am I able to, since it
includes changes to a C++ file, a programming language for which I do not
happen to have compiler set up, since I don't write much C++ (my most advanced
C++ program ever was a program which asked the user for a number... and then
printed Hello World! on the screen that many times. But hey, it compiled!)

Comment 28

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 71027 [details] [diff] [review]
change the pref name to browser.block.target_new_window

r=bzbarsky

Comment 29

[Alec Flett]

Comment on attachment 71027 [details] [diff] [review]
change the pref name to browser.block.target_new_window

well done! thanks for going the extra mile...
sr=alecf

Comment 30

[Jonas Jørgensen]

Boris, could you check this in when the tree reopens?

Comment 31

[Boris Zbarsky [:bzbarsky]]

You mean after 1.0?  :)  That seems excessive.

I mailed drivers asking for approval for whichever milestone they want this for.

Comment 32

[Jonas Jørgensen]

> You mean after 1.0?  :)  That seems excessive.

I meant "after 0.9.9 has branched", of course. :-)

Comment 33

[Asa Dotzler [:asa]]

a=asa (on behalf of drivers) for checkin to 0.9.9

Comment 34

[Boris Zbarsky [:bzbarsky]]

As a note my r= means "I tested this and it works as advertised".

Comment 35

[Boris Zbarsky [:bzbarsky]]

Checked in on trunk for 0.9.9

Leaving open since I'm not sure this completely fixes the bug as initially
described; people should decide that.

Comment 36

[Jonas Jørgensen]

> Checked in on trunk for 0.9.9

Great, thanks! :-)

> Leaving open since I'm not sure this completely fixes the bug as initially
> described; people should decide that.

Attention all voters and people on the CC list: Do any of want anything more 
from this bug, or is it ok with you if we close it? (If you want something 
more, please speak up, if not, I'll mark this fixed if noone says anything.)

Comment 37

[franCk]

Concerning the original behaviour asked by the reporter I see an inherent flaw:
before clicking it is impossible to know if the link would open in a new window
or not.
It means you will have to click all the time on links using the right mouse
button and select in the menu... IMHO quite tedious.
OK, I'm not the original reporter, but you asked about opinion and it is just my
two cents of euro about it...

(BTW, won't it be great to know if a link opens in a different window? I mean
when we hover over the link in the status bar the URL of the link appears, maybe
Mozilla may show something like 'New window : http://foo.com' instead of
'http://foo.com' - OK I'll fill a RFE on that!)

Comment 38

[Michel Valdrighi]

franCK, I guess such a feature could use just the target element. It would then
display: "_blank: foo.html" for new windows, aswell as "mainFrame:
content2.html" for links that open in frames.
Then adding a pref that says "display link target in the status bar ?" that
defaults to "no" would be ok and unobstrusive, imho.
Just my 0.02€ :)

Comment 39

[Tony Tovar]

While you're at it, could you also work on bug 14027 ?  Maybe set this bug as
blocks(depends?) on bug 14027 ?

Comment 40

[Phillip Stewart :P]

Running 2002022703.

Clicking on the "Get New Themes" link under Preferences > Appearance > Themes
causes the page to open in the perferences window.  I'm guessing because of this
fix.

Comment 41

[Jonas Jørgensen]

> While you're at it, could you also work on bug 14027?

Sorry, but I don't have any interest in bug 14027 since I browse with
browser.block.target_new_window on.

> Clicking on the "Get New Themes" link under Preferences > Appearance > Themes
> causes the page to open in the perferences window. I'm guessing because of
> this fix.

It seems that browser.block.target_new_window causes it, yes. I suggest you file
a bug in the HTMLFrames component and assign it to [e-mail] who
implemented the browser.target_new_blocked functionality (I only renamed the
pref and added it to Preferences).

Comment 42

[Jonas Jørgensen]

Bug 130337 filed on the bug [e-mail] mentioned in comment 40.

I'm closing this as FIXED since it doesn't seem like anyone is interested in
getting anything more out of this bug.

Comment 43

[Jonas Jørgensen]

Marking VERIFIED FIXED.

Comment 44

[John Morrison]

reopening to resolve one defect from the patch made in this bug.

An entry for id 'allowTargetNew' was not made in the function 
'changeDisabledState()' so that when javascript is fully disabled,
that one checkbox still appears enabled, which is the wrong UI
feedback.

Comment 45

[Boris Zbarsky [:bzbarsky]]

Hrmm... That's an interesting quandary.  This pref has nothing to do with JS and
should be enabled no matter what the JS state is...

Perhaps this checkbox just needs to move out of the <tree> ?

Comment 46

[John Morrison]

Oops, I hadn't thought through that this one pref was not js-dependent.

Still, though, the feedback is confusing (e.g., "why isn't _that_ checkbox
also disabled? If I uncheck it _now_ will that _really_ disable new windows?")

Comment 47

[Jonas Jørgensen]

> Still, though, the feedback is confusing (e.g., "why isn't _that_ checkbox
> also disabled? If I uncheck it _now_ will that _really_ disable new windows?")

Mpt, could we have some UI design input here, please?

Comment 48

[Matthew T (active 1999-2002)]

Sorry Jonas, this is my fault. If I'd known someone was going to implement this
so soon, I'd have put the spec for bug 75371 in a more obvious place, so you
would have known what to do. Anyway, for now it's attachment 49497 [details], and what
you're implementing is the first pair of radio buttons. As Boris figured out,
they belong outside the listbox, because the listbox is `Allow scripts to:'
(please change that back), while these radio buttons apply to pages opened by
scripts *or* by unscripted A HREFs with TARGET set.

Comment 49

[Jonas Jørgensen]

> while these radio buttons apply to pages opened by
> scripts *or* by unscripted A HREFs with TARGET set.

The checkbox which I added to Scripts & Windows only applies to <a> with target
set, not to pages opened by scripts. Is the radio button meant to control both
once bug 64560 is fixed?

According to your spec, there should only be a checkbox for enabling/disabling
JavaScript in the browser. Currently, there is also one for mailnews -- should
that one be moved elsewhere, or are we completely dropping JavaScript support in
mailnews, or what?

Comment 50

[Jonas Jørgensen]

Mpt, could you please answer my questions from comment 49? Thanks!

Comment 51

[Matthew T (active 1999-2002)]

> Is the radio button meant to control both once bug 64560 is fixed?
> The checkbox which I added to Scripts & Windows only applies to <a> with
> target set, not to pages opened by scripts.

Ow. Then you'll have to implement bug 64560, or get someone else to do it, 
before this can be exposed in the UI. You can't expect the the user to care 
which computer language is being used to open the window, and it's no good 
having a pref which only works half the time. Marking dependency.

> According to your spec, there should only be a checkbox for enabling/disabling
> JavaScript in the browser.

The mail/news checkbox was moved to this panel with my agreement, after I made 
the spec (which, as you can see, is for `Navigator Preferences', not `Mozilla 
Preferences'). Anyway, it has nothing to do with this bug.

Comment 52

[Jonas Jørgensen]

> Then you'll have to implement bug 64560, or get someone else to do it, 
> before this can be exposed in the UI. You can't expect the the user to care 
> which computer language is being used to open the window, and it's no good 
> having a pref which only works half the time.

I disagree. I've seen many positive comments from end users on this feature, and
target="_blank" is used *far* more than window.open. You don't back out a
popular feature completely just because it fails 10 percent of the time.

Comment 53

[Peter Trudelle]

Sure we do, a 10% failure rate is abysmal.  Features like that may become
popular among a tiny percentage of extremely advanced users that thoroughly
understand them, and can avoid or tolerate the failures, but they'll never be
truly popular.  Can you imagine people tolerating a TV or toaster that failed
even 1% of the time?

Comment 54

[Jonas Jørgensen]

> Can you imagine people tolerating a TV or toaster that failed
> even 1% of the time?

Imagine that you buy a toaster (== Mozilla) which works perfectly. When you buy
the toaster, they tell you that you were their customer no. 1000 that month, so
they gave you a free thingie (== the ability to prevent a link from opening in a
new window) which will put butter on the bread for you after it is toasted.
Imagine that said thingie only works 90% of the time. The remaining 10%, it does
nothing, so you have to put the butter on the bread manually.

Would you tolerate that thingie? I certainly would. And when this checkbox is
converted to a set of radio buttons, there will be room for leaving a warning
saying that it might fail sometimes.

Comment 55

[Peter Trudelle]

You and I are not the target user. Most people don't tolerate things that have
such a high failure rate. Putting up a notice saying that we know in advance
that it has a high failure rate is actually worse, since everyone who sees it
will doubt all of the functionality of the product, assuming quite rightly that
vendors who knowingly leave such a problem in the product are likely to be lax
in other areas as well.

BTW, I buy toasters to toast, only to toast, and consider myself lucky if the
damn things can manage to do that one simple thing right.  The idea that simple
tools should have lots of extra options and funcationality is all too often
detrimental to accomplishing their primary task.

Comment 56

[Jonas Jørgensen]

Attachment: update the panel to match mpt's ui spec

Comment 57

[Jonas Jørgensen]

Attachment: screenshot

Comment 58

[Doron Rosenberg (IBM)]

so, do we back the ui for this feature out or not due to the 10% failure?

Comment 59

[Dan Tobias]

I, for one, don't want to see this feature backed out, though the user interface
could stand some improvement.  It's one of the things I like about Mozilla, that
I can stop sites from opening new windows... I wish something could be done
about other sorts of new windows that use JavaScript, etc., but I don't want the
baby to be thrown out with the bathwater by suppressing the whole feature
because it doesn't work in those cases.

Comment 60

[Christopher Aillon (sabbatical, not receiving bugmail)]

While I generally agree with what this patch is doing (the pref shouldn't be
mixed with the scripts pref), I do feel that leaving this visible in the UI is
wrong.  Let's fix the 10% case (actually, I don't know where 10% comes from, I
come across window.open alot more frequently than target="_new")

Backing out the UI does not mean backing out the pref.  We can still leave that
 in as a "hidden" pref for now, like we do with other things that aren't ready
for prime time, eg the favicon pref.  If you have the pref set via your prefs.js
that's fine and you can still use the feature.

Jonas, can you come up with a quick patch to temporarily back this item out of
the panel?

Comment 61

[Jonas Jørgensen]

Attachment: remove this feature from the panel

Comment 62

[Jonas Jørgensen]

Please consider: The "Open Link in New Window" feature does not work for
JavaScript links either. But we aren't planning to remove that feature
completely until we have fixed it so it works for JavaScript links as well, are
we? How come?

Comment 63

[Jonas Jørgensen]

Comment on attachment 83514 [details] [diff] [review]
remove this feature from the panel

If this feature is to be removed from the panel, we'd better do it quickly and
make sure that it happens on the branch as well, since the current UI leads to
confusion.

caillon, could you review attachment 83514 [details] [diff] [review]?

Comment 64

[Dan Tobias]

What was wrong with the proposed new UI for this feature that caused it to be
withdrawn in favor of hiding the feature altogether?  I'm strongly against
hiding the feature, as I find it to be one of the best things about Mozilla that
you can suppress sites from opening up new windows with target attributes.

Comment 65

[Jonas Jørgensen]

Dan: This feature is not being removed because of the proposed new UI. This
feature is being removed because it only works for target="foo", not for
window.open(), which will make end users wonder why it doesn't work for all links.

(Of course, only the UI for this feature will be removed. You will still be able
to turn this on manually by adding |user_pref("browser.block.target_new_window",
true);| to your prefs.js.)

Comment 66

[Dan Tobias]

If I wanted a browser dumbed down to what the "average end user" can understand,
I'd probably use MSIE... that's not what I expect from Mozilla.  Or is Mozilla
not so independent of parent corporation AOL (another big fan of dumbing things
down)?

Comment 67

[Jonas Jørgensen]

Dan, this is not being removed because it is an advanced feature; it is being
removed because it has an unacceptable failure rate. The minute someone fixes
bug 64560 so this works for window.open as well, I'll do a patch to add this back.

There's nothing we can do about this. If trudelle, caillon and mpt want this
pref removed, I will not try to argue against it anymore. I suggest you go vote
for bug 64560.

Comment 68

[Doron Rosenberg (IBM)]

Comment on attachment 83514 [details] [diff] [review]
remove this feature from the panel

r=doron - perhaps this should be removed from the branch only and kept in the
trunk?

Comment 69

[Jonas Jørgensen]

I think this should be removed from the trunk as well. The first bug report
about this feature failing for some links has already been filed :-( (bug 145418).

Comment 70

[jag (Peter Annema)]

Comment on attachment 83514 [details] [diff] [review]
remove this feature from the panel

sr=jag

Comment 71

[Jonas Jørgensen]

Adding nsbeta1, mozilla1.0 keywords. Not for implementing this RFE, but for
checking in attachment 83514 [details] [diff] [review] to remove this from the Scripts & Windows panel; if
that isn't done before 1.0, we will be flooded with bug reports like bug 145418.

Comment 72

[Jonas Jørgensen]

Temporarily changing summary to describe what this bug is currently about, i.e.
removing this checkbox from Preferences. Will change it back once that is done.

Comment 73

[Jonas Jørgensen]

Won't make 1.0.

Comment 74

[Boris Zbarsky [:bzbarsky]]

This patch has rotted and does not apply.. any chance of an updated patch that
applies?

Comment 75

[Jonas Jørgensen]

Attachment: patch which applies to the latest trunk build

Comment 76

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 87349 [details] [diff] [review]
patch which applies to the latest trunk build

r=bzbarsky, carrying over sr since this is essentially the same patch (just
whitespace/linebreaking changes).

Comment 77

[Boris Zbarsky [:bzbarsky]]

Checked in on trunk.

Comment 78

[Jonas Jørgensen]

Excellent.

Comment 79

[Jonas Jørgensen]

--> Future (since this is blocked by bug 64560)

Comment 80

[Jonas Jørgensen]

Comment on attachment 87349 [details] [diff] [review]
patch which applies to the latest trunk build

Marking as obsolete since this has been checked in.

Comment 81

[Matthew T (active 1999-2002)]

Thankyou for doing that, Jonas. While we're waiting for bug 64560, maybe 
someone could fix the current pref to work without needing a restart? :-)

Comment 82

[Jonas Jørgensen]

--> default assignee

Comment 83

[Torben]

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

Comment 84

[Chris Lyon]

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

Comment 85

[Alfonso Martinez]

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

Comment 86

[Manko]

We have a patch and r/sr. What is needed to check this in?

Comment 87

[Christian :Biesinger (don't email me, ping me on IRC)]

manko: the patch is already checked in, see comment 77

Comment 88

[Manko]

But do we have UI for this?

Comment 89

[Christian :Biesinger (don't email me, ping me on IRC)]

no, we don't, the ui was removed with the last patch (I wonder why?)

anyway, I guess the missing ui is the reason why this bug is still open.

Comment 90

[Boris Zbarsky [:bzbarsky]]

Some people decided that this feature is too confusing for our poor users and
backed out the UI rather than fixing it. Read the bug.

Comment 91

[Manko]

Maybe, item "Open in this window" in link context menu, as proposed in bug
195069, would be a lesser confusing solution?

Comment 92

[Greg Roth]

I would like to have the option to color links that would open in new windows
regardless of whether they will be or not based on my preferences. This would
let me choose to open it in a new tab if I don't want a new window.

Comment 93

[Manko]

Greg, create file userContent.css in %YourProfile%/chrome directory.

Then add in this file following CSS declaration:
a[target="_blank"] {
  ...any CSS rules here...
}

You also can add !important after CSS rule to avoid your declarations to be
replaced by CSS from web page.

For example see my userContent.css:

a[target="_blank"] {
  -moz-outline: 1px dashed invert!important;
  /* links to open in new window */
}

a[href^="http://"] {
  -moz-outline: 1px dashed #FFCC00!important;
  /* links outside from current site */
}

a[href^="http://"][target="_blank"] {
  -moz-outline: 1px dashed #FF0000!important;
  /* combination */
}

Comment 94

[David Buckley]

Guys, how about this solution to this (and bug 64560):

Have some sort of option on the context menu (maybe one that could be disabled
in prefs to prevent crowding, or maybe just have them as global prefs or something):
_Force_ open in same window
_Force_ open in new window
_Force_ open in new tab

Maybe they could all be added to an optional "force" submenu to prevent clutter?

Process would be something like:
"Normal" link) Just do relevant action
Any extra ECMAScript) Run the script, but somehow tag the script running thingy
with "I want window.open to work in X manner", so that any window.open() is
coerced into working in the desired fashion.

Suggested (easy) implementation (which should work in 99.99% of situations):
Temporarily set some global pref option to force window.open into a particular
behaviour only while the ECMAScript is running.

Obviously, this is ugly, but it's probably also a "quick fix". A more complex
fix would be nasty, I suspect, unless there's some Cool Stuff Mozilla supports. :)

Ideally, I'd at least like an "Open in Same Window" for new window links, or
something similar, because they really get on my nerves; I currently have to
fire up the new window, copy URL, and paste it back into the current.

I know my current Mozilla does not do this (Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.3) Gecko/20030327 Debian/1.3-4).

Comment 95

[Jo Hermans]

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

Comment 96

[Jon Henry]

I came across this bug while investigating the validity of bug 206831. There's a
testcase attached to that bug that I don't really know what to make of (which
only exhibits the strage behavior when the new window blocking pref from this
bug is enabled. My first instinct was to mark it invalid, but now I'm not sure
after reading this bug.

Is the preference acting as it's supposed to? He's basically trying to open a
new, blank window using window.open (since we don't have code in place to stop
that yet) and then redirect that window to a new page by submitting a form whose
target attribute is the name of the popup window and whose action is the name of
the HTML file to redirect to. What actually happens is that the new window is
opened, but the parent window is the one that gets redirected. Am I missing
something? What he's doing looks legal, so it might be a problem with this pref.
Thanks for any clarification.

Comment 97

[Jeremy M. Dolan]

Jon: I've seen what you describe on quite a few sites. I know freshmeat.net used
to (for no good reason) window.open a popup, and then load screenshots in it
with a "target=". That too resulted in the content loading in the current
window, and a blank new window. There is probably another bug open on the whole
issue that bug 206831 could be duped to.

Comment 98

[Alfonso Martinez]

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

Comment 99

[Torben]

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

Comment 100

[Boris Zbarsky [:bzbarsky]]

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

Comment 101

[michael]

I'd also like to see this feature (also in Firefox, not just regular Mozilla). 
It's very annoying when sites insist on opening in new windows, and second only
to <blink> and <marquee> as the most annoying "features" of HTML.

Comment 102

[Malte Wedel]

I just opened bugzilla, to file an enhancement request to be able to ignore
target attributes in links, if the window or frame does not already exist. Of
course this will break some sites, that rely on this behaviour, but as long it
is configurable this way in the preferences and not the default, I don't see a
problem with that.
I found this enhancement request, which is exactly about this topic, so I added
my  thoughts about this here.
I do not think, this is dependant on on bug 64560: If a site uses JS to open a
window, it usually want to be able to communicate with it, or close it again
(like a popup window :-). If a site uses target="_blank" it just tries to keep
people on their site to get more page impressions (= more ads shown and clicked)

Comment 103

[Joachim Noreiko]

(In reply to comment #4)
> Probably the best way to do this would be to change the "Open in New Window"
> right-click link to "Open in Same Window" if the link would already open in a
> new window. Just my $.02...

Is this worth opening as a separate enhancement issue? I think it is a good idea.

Comment 104

[Stefan Borggraefe]

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

Comment 105

[Felix Miata]

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

Comment 106

[Vincent Lefevre]

browser.block.target_new_window is stupid. The page shouldn't be blocked, but
opened in the current tab.

Is this bug about blocking requests with target="_new" (for instance), as the
summary and the behavior of browser.block.target_new_window suggest, or is it
about ignoring the target attribute, as some duplicates suggest?

Is it a UI bug only (since it is affected to Preferences)?

Comment 107

[Prognathous]

(In reply to Jonas Jørgensen, status whiteboard:)
> browser.block.target_new_window overrides <a>'s target attribute; the UI for 
> this is blocked by bug 64560 which will make a pref for window.open as well

How about adding the UI first, then expand it to cover window.open later?

Prog.

Comment 108

[Dan Tobias]

The UI *was* in place a long time ago in the Mozilla Suite, but it was removed
because people were apparently confused by the fact that it didn't always stop
the launching of new windows (because there are several ways of doing it, not
all of which are covered by blocking target attributes).  I disagreed with this
UI removal, since I'd rather have a window-blocking function that works
sometimes than none at all, and the UI-less version is buried in hard-to-find,
cryptic configurations over in about:config.

Comment 109

[Prognathous]

Then it's all about phrasing: "Attempt to prevent links from opening in a new
window" should probably be fine.

Prog.

Comment 110

[Paul Rubin]

Preventing links from opening in a new window is good, but the UI doesn't belong in preferences.  Most of the time, target=top is legitimate.  Just some sites are annoying and try to prevent you from leaving by targeting all their links that way.  The solution is to put "open in same tab" on the right click context menu along with "open in new window" and "open in new tab".

Comment 111

[Philip Withnall (unavailable)]

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

Comment 112

[Serge Gautherie (:sgautherie)]

(Filter "spam" on 'prefs-nobody-20080612'.)

Comment 113

[Philip Chee]

The backend preferences are already available. All that's left is the UI and that will be done in Bug 583625

Comment 114

[Philip Chee]

Front end User Interface fixes are in Bug 583625. This change will be in SeaMonkey 2.1b2 coming Real Soon Now.