From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5+) Gecko/20011010 BuildID: 2001101003 Okay, this would have gone under bug 20306(where the symbol in the lower left corner of the window would always open a new window), but that bug became full of crud (meaning views in opposition to mine ;) ) and it hasn't been touched in a long time. Opening a new browser window is a pretty big part of going through the web. You need to do this every time you want to go to a new place without losing what you've already got it open. However, there is no single-click way to do this that is part of the browser. I think there should be. I have experimented with what we have, I set my homepage to "javascript: window.open()", but while that used to work, nowadays it destroys the content of your current window. Perhaps we could get an optional button next to the home and bookmarks buttons (and shop and other stuff in NS6.1). Of course, we could always try to get the icon in the lower left to always open a new window (as 4.x did in Linux), but there seems to be a lot of resistance as folks like to use it to cycle through windows (which I'll never understand...).

Dup of bug 98874? Middle-clicking a link can open it in a new browser window. (GUI being implemented in bug 103349. In the meanwhile you can manually add user_pref("middlemouse.openNewWindow", true); in prefs.js or user.js "File->New Navigator Window" or Ctrl+n will open a new browser window. It's a click-and-a-drag away at worst. Right-clicking links have "Open link in new window" as context menu There are also related bug 28239 and bug 59132 WFM.

should really be marked dup of 20306 of course.. Changing severity.

When you use javascript URLs, you need to make sure the last call doesn't return anything. The function window.open() returns a reference to the newly created window object. Try this URL instead: javascript:window.open(); void 0; By the way, those work well as boomkarks (stored on the personal toolbar). I've never used a javascript: URL as my home page, but I'd imagine that would create 1 or more extra browser windows on startup.

Opening new windows is already possible with some very short drags: New window at homepage: file, new. Open link in new window: right-drag down and right (once bug 89308 is fixed). If you want a toolbar button to open a new window, you'll need to wait for bug 15144 to be fixed. Hopefully bug 20306 will be fixed by then, and the component bar buttons will work consistently. But since the component bar buttons are pretty small, it would still make sense to have "new browser window at home/blank" as an optional toolbar button.

Okay, to clarify, I'm talking about just a new window, not opening a link in a new window. The action equivalent of ctrl-N, only with one mouse click. Jesse: thanks for the tip. No extra window is opened at startup if it's set to a blank page. (also nice to see some optimism on 89308 and 20306) Dunno if this should depend on 15144. I meant that this button should go on the personal toolbar, like home or bookmarks. It could even have a snazzy icon like home and shop do. It could go on the toolbar too, though.

-> default assignee

->future, cc marlon for UE input.

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

See also bug 156916, "Make Open A new tab button available when the tab bar is closed".

Note that this is implemented in Phoenix. Nice!

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

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420