A lot of people tend to use "New Window" a lot as opposed to replacing the window when you click on a link. This is a request to have a preference that allows swapping the mouse and keyboard actions used to trigger a new window/replace window when following a link for those who do it more often than not.

this is not a bug....this is by design...

What is by design? The fact that a pref isn't provided?

Adding sujay to ensure my comment above gets through.

adding RFE to summary

Does that means it's ok to reopen?

reopening...

Clearing Invalid resolution due to reopen of this bug.

We have right-mouse context menus for opening a link in a new window, and a plain click-on-link will replace the current window. That's what 4.x did, not sure we need another pref here. 4.x/unix has middle-mouse opening a new window, maybe we could implement that for windows as well.

The issue is really about the fact that for some people, the most natural action is not on the most natural UI vector. Using button 3 would be nice for Win users that can support it, but even for a lot of Linux users, this means simultaneously pressing both buttons, not to mention Mac users.

spam: in my testing realm, so reassigning qa contact to me, en masse.

Another option would be "always open in same window" to go with "always open in new window" and "do what page says".

How about this: - Click = do what page says, unless overridden by prefs - Shift-click = open in new window (instead of save as) - Ctrl-click = open in same window - Context menu: include "open in same window" and "open in new window". the option that would have been triggered had the left mouse button be used would be bold, although whether the link had a the target= property might also be indicated.

This could be done as part of bug 12056. See my 03-24 comments on that bug.

I'd like the following semantics for Click: - if the page says to open in _new or _top or frame, do it. - otherwise open location is specified in prefs (same or new window) It's probably a bad idea to override the page in the Click function. Ctrl/Shift+Click should open in same/new window. Opening from mail, bookmarks, history, ... should have a *separate* pref to open in a new/existing window. (There are some other bugs already filed on this, like bug #35578)

Move to "Future" milestone.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

Yes, please implement this! I think in at least four out of five times I open a link in a new window, so I really would like to make this the default. Also, I'd like to make "new navigator window" in the "open web location" dialog the default instead of "current navigator window". Or is there already a bug filed about that? Changing component to Prefs since I don't think Browser-General is appropriate.

i don't mind if there's a hidden pref for this --but i really wouldn't want to have clicking a link to open a new window as the default. recommend wontfix for the default aspect.

My preference, FWIW, is some way to disable ALL automatic opens of new windows. I don't give a damn about the web designer's preferences.

dclose@stratasource.com, I think the hidden pref from bug 56296 does what you want, at least for target= (I don't think it handles javascript window.open()). If the pref this bug is asking for is added to the prefs panel, it would make sense to also add the pref from bug 56296 in the same panel. Perhaps the two prefs could be combined: When I click on a link: o Always open in the same window (use ctrl+click to open in new window) o Always open in a new window (use ctrl+click to open in a same window) o Use settings from webpage [default]

See also bug 35578, which would introduce a related pref determining whether a link clicked in MailNews, AIM, etc. reuses an open Navigator window or opens a new one.

Now that the tabbed browsing feature is here, other possible options would be to open all links in a new tab, or to open all links that call for new windows in new tabs instead.

trudelle to triage

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

This might be unnecessary once bug 89308 (context menus onmousedown) is fixed. Opening a link in a new window would then be a single right-click with the mouse moving down and to the right several pixels during the click.

My Twopenceworth IE 5.5 (sorry to swear) introduced an option that was called "reuse windows for opening shortcuts" which I turn off. I find it annoying that if I click on a link in an email that link is opened in one of the windows I am browsing in, which was looking at a completeley different site / newsgroup

I'm with Dave Close (Comment #19) on this one. If I had wanted a new window, I would have middle-clicked, or right-clicked and used the menu.

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

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

Shift+Click -> Save link target as Ctrl+Click or Middle-Click -> New target (tab or window based on prefs) Right-Click + Context Menu -> User has complete choice WORKSFORME

Hb, I think you're misunderstanding what this bug is about.

I did and changed the summary from "Preference for open link in new window to be default action." Status back to KaiRos mass-UNCONFIRM-20090614

Ten years after, mice usually have three buttons - and we have prefs for handling its behaviour. Even for MacBooks extensions exist to use 3-finger-tap as middleclick, so there's no use anymore adding this complexity. Also, this could probabaly be done as an extension. => WONTFIX

Pierre, which options do you want for a left click?