Closed Bug 75138 Opened 23 years ago Closed 19 years ago

pref to open links from other apps/components in a new window or tab

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.8alpha6

People

(Reporter: Marko.Macek, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss, polish) 

Discusstion from bug 35578.

The following pref is suggested by mpt:

-----------------------------------------------------
   Open links from other applications and components:
   (*) create a new window (default)
   ( ) reuse most recently used navigator window
-----------------------------------------------------   

   Actual text to be debated, but the above is intended to be clear.

   If multiple links can be opened at once, they should always open in a new 
   window.

This would apply to:
  - opening links in mail/news
  - opening links in bookmarks and history
  - opening new links with -remote command line option (or DDE in windows, etc)
  - any other component needing to open a web page (chatzilla?)

Note: IE has this option, I'd like mozilla to have it too.

Bugs 71400, 71401 and 35578 are affected by this.

Rationale: for people that typically browse in many windows, reusing windows is
annoying and confusing and can make you lose your work. It is not very
predictable which window is "last used" when you have multiple desktops, etc...
Keywords: correctness, polish
Summary: RFE: pref: open links from other apps/components in a new window → [RFE] open links from other apps/components in a new window
The wording I suggested was:

Open shortcuts from _other programs using:
(*) new windows  ( ) existing windows
(Multiple shortcuts will always open in new windows)

->prefs
Assignee: pchen → mcafee
Component: XP Apps → Preferences
A related bug is also bug 15512
over to vishy to find an owner
Assignee: mcafee → vishy
Wasn't this the default behaviour in the builds previous to 0.9.1?
Now, when I click on a URL in another app, it opens in one of my present mozilla
windows. Previously, I was using 0.9 and clicking on links in other apps opened
a new mozilla window.
*** Bug 90453 has been marked as a duplicate of this bug. ***
*** Bug 82557 has been marked as a duplicate of this bug. ***
--> me
Assignee: vishy → blake
Target Milestone: --- → mozilla0.9.4
Having this pref is very valuable. 

It's not clear that the default shd be to use a new window though.  I think our 
installed base (communicator) has  the default as "use existing window if 
possible". what is the default in IE?
I don't see how this is any different from 35578.  I suggest this be
resolved/dup of that bug to reduce the noise and increase the focus on one bug.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
No longer blocks: 35578
I am turning the dependency around. See bug 35578 for why.
Depends on: 35578
Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room
for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work.
 If anyone disagrees with the new target, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Summary: [RFE] open links from other apps/components in a new window → [RFE] pref to open links from other apps/components in a new window
Depends on: 99945
I think using a new window should be the default behavior and unpreffable.  Are 
there really that many users who leave browser windows open when they're done 
with them and never click links in other applications unless they're done with 
their browser windows?
As I don't run Mozilla maximized, I find "open using... existing windows" to be
useful, as extra windows only serve to clutter my screen. And, reusing windows
would also allow me to avoid the time-to-create-new-window.

But, that's just my take -- and, so I think a pref would be valid. 

I know that there's no UI for this yet, but is this configurable via prefs.js to
enable this behavior in the meantime?
Target Milestone: mozilla0.9.6 → mozilla1.0
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.9
No longer depends on: 35578
Target Milestone: mozilla0.9.9 → mozilla1.1
Target Milestone: mozilla1.1 → Future
Do you really think it is a good thing to target that bug to "future" ?
As for me, I've been very annoyed with that mozilla behavior,
and lost many pages that I haven't already read.

I usually connect to the internet, download some pages, then shut down
the connection and read them. But when I get a mail with a link,
and click on it, I first think that the page hasn't been loaded,
since I don't see anything (I'm under Linux, and the page usually
loads in another virtual window), so I open the link once again,
this time in a new window. Then, I shut down the connection,
switch back to the other mozilla windows, and understand ... to late.
The only thing I can do is download again the page I lost.

To be exact, now I know that I have to open directly the link
in a new window using the middle button of my mouse, but it is 
very annoying for new users.

And it shouldn't be that hard to fix that bug ...
.
Status: ASSIGNED → NEW
Component: Preferences → XP Apps: GUI Features
See also bug 133188, "Middle Click doesn't open new windows in Tabbed Browsing
mode".
> See also bug 133188

BTW: That bug has recently been marked as a dupe of bug 101955.
This bug is one of two that keep me from using Mozilla as my default browser. As
I often follow many links from email for quick viewing it is very inconvienent
to have to remember to close every window I view to prevent ending up with 20 or
so open windows. This is really a bad thing on a laptop with very limited desk
space to start with.

It should be a preference with two parts;

-----------------------------------------------------
   Open links from other applications and components:
   (*) in a new window
   ( ) in most recently used navigator window

   Open links from browser windows:
   ( ) in a new window
   (*) in most recently used navigator window
-----------------------------------------------------   


It could also be done in fewer lines, but I think this way would be less clear
to end-users:

----------------------------------------------------- 
   Re-Use front navigator window for:
   [*] links from other applications and components
   [*] links from same navigator window
----------------------------------------------------- 


*** Bug 111539 has been marked as a duplicate of this bug. ***
*** Bug 151009 has been marked as a duplicate of this bug. ***
From bug 155402: shortcuts from the desktop and from Outlook Express now reuse
windows, making this bug 35578 (bad default for whether windows are reused) and
bug (lack of pref) more visible.
*** Bug 163155 has been marked as a duplicate of this bug. ***
How about adding an option to this set that lets you open links from other apps
in a new tab of the previously used browser window. This way, you don't have to
open another window up, but you also won't lose what you were working on.
Blocks: 121969
I agree with comment #24 that there should also be an option for new tab, as
well as new window, and current window.

This behavior of using the same Mozilla window is new to me since I switched to
1.1... I am sure 1.0 did open new windows.

I get co-workers / friends instant messaging me links all day long and now I
have to copy the URL, open a new Mozilla window or tab, and then paste the
URL... it's rather bothersome.

I would say that this is also one my top 3 list of bugs that I so VERY much are
fixed in near future.
Eric: if You need this now try method about which i wrote in bug 163155 .
Re comment #24: see  bug 155402 comment 10 for a workaround.
*** Bug 165212 has been marked as a duplicate of this bug. ***
I'd like to add this point to the pro/cons list:

I'm using Moz as my reference-browser when building websites.. means i'm
permanently sending open_urls from my editor (BBedit) to Moz -> in just a few
minutes i get dozends of new windows, which means not only clutter, but a
seriuos amount of time, as Moz's GUI is fairly slow on a not_top_of_the_crop Mac
(a 400mhz G3 powerbook here, dunno about the GUI speed on slower WIN/LIN systems
though..)

This is a MAJOR drag for me..

However, i'd very much ask for _some_ way to change that behaviour.. don't mind
if directly in the prefs or via a user.js entry.

THX for considering..

Jan
jan. Look at my comment #26 . Follow the link.
<i>
&gt; From Zbigniew Braniecki:
&gt;
&gt; jan. Look at my <a href="#c26">comment #26</a> . Follow the link.</i>

Zbigniew,

it might be my poor english,or some misunderstanding on someone's side, but i
understand your description in <a href="#c26">comment #26</a> as the _opposite_
of what i need.. ;) I do get new windows with every open_url.. alas i want that
other thing: <b>open_url = reuse frontmost window</b>.

Maybe i should provide infos on my setup:
(Mozilla/5.0 (Macintosh; U; PPC; de-AT; rv:1.1b) Gecko/20020722) @ MacOS 9.1
I'm experiencing this behaviour from my first Moz (0.9.8) or so on..

thx for checking in..
Jan
Agh. Sorry. What version you're using?
Since Moz1.1 there is almost no waty to open link in new window from external app.
Please please add an option somewhere:

"open a new window by default when clicking on a link in an email"

it is a big hassle for me to click on a link, and get one of my old browser
windows get logged out from a web applications i was using...

Thanks
Zbigniew Braniecki wrote:

> Agh. Sorry. What version you're using?
> Since Moz1.1 there is almost no waty to open link in new window from external 
> app.

As i said above:
(Mozilla/5.0 (Macintosh; U; PPC; de-AT; rv:1.1b) Gecko/20020722) @ MacOS 9.1
and i _do_ get new windows no matter who sent the open_url call.. my HTML
editor, the system itself (by clicking internet location files), other apps.. 

any help appreciated..
Jan
jan, since you are on mac the following should work:
user_pref("browser.always_reuse_window", true); see bug 121969 comment #16
Hi Torben,

> jan, since you are on mac the following should work:
> user_pref("browser.always_reuse_window", true);

thanks for the hint.. it does work here. Alas it would be nice if Moz was
capable of distinguishing open_url calls coming from the Finder/System (when
clicking a InternetLocationFile) and calls from a HTML Editor.. while i'm now
happy, that windows are being reused when coding HTML, the reuse is not very
cool, when clicking those ILFs, where one would normaly expect/want a new
window. I dunno about WIN or Linux, but on the Mac, apps _can_ distinguish those
calls, as a sample UA who does that i could name iCab for example.. but i guess
this is rather low priority, and if generaly not possible on other Systems, a
feature that will probably never see the light.. ;)

Again, thanks for your advice.. Moz suits me better now.

greets,
Jan
Blocks: 153533
*** Bug 163236 has been marked as a duplicate of this bug. ***
Blocks: 167407
Summary: [RFE] pref to open links from other apps/components in a new window → pref to open links from other apps/components in a new window
See also bug 172962 (Phoenix).
*** Bug 155402 has been marked as a duplicate of this bug. ***
Another vote for an option to "Open in New Tab".  Presumably this would be in
the most recently used window.

I've come to like tabbed browsing, but the obscurity of how to use them is
probably an obstacle to their adoption (I know it was for me - I had to do some
searching on mozilla.org to find controls to switch between tabs: ctrl-pageUp
ctrl-pageDown, now I like this better than alt-tab to switch windows)
*** Bug 187259 has been marked as a duplicate of this bug. ***
I really don't understand why this is targeted as future and is only an 
enhancement.

I've downloaded Mozilla several times and then gone back to IE, because I 
cannot be in a situation where my pages vanish when new ones are opened.  I 
frequently open several pages at once, open them from an address bar and open 
them from other apps.  Having my information vanish into the ether isn't 
acceptable, so I'm forced back to IE time and time again.

Other people have indicated the same thing, so it's obviously not just a minor 
enhancement - it's a show-stopper for some of us.
Since bug 155402 has been marked as a duplicate of this (I do not agree, see bug
155402 comment 28), I am raisng the severity to normal and adding dataloss keyword.
Severity: enhancement → normal
Keywords: dataloss
It is my opinion that the Summary of this bug should be changed to:

"open links from other apps/components in new window"

in other words, this should be the default, not a pref (bug 155402 comment 57)
this should apply every time when the links is opened from another window
(including bookmarks manager).
I agree.  Thinking about it, dataloss is always a bug UNLESS that's the
behaviour that's been explicitly stated (by a preference or other deliberate
user action).

However, since it's also possible that external links could open new tabs, the
summary should really be rephrased as follows:

"Links from other apps/components should not overwrite existing data."

  (Whether external links open in a new window or new tab would be managed by
other preferences / bugs.)
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
*** Bug 185553 has been marked as a duplicate of this bug. ***
This is a serious issue for me.  I cannot use a browser which will not open new
links in either a new window or a new tab.  I've been using 1.2 up until
yesterday when I upgraded to 1.3b.  This workaround worked for 1.2:

user_pref("advanced.system.supportDDEExec", false);
user_pref("browser.always_reuse_window", false);

In 1.3b, however, these settings seem to have no effect.  Is there a new
workaround?  I'm not so much concerned with the preference option that this bug
requests as I am concerned with having a usable browser.  Please don't send me
back to IE.
I should add to my last comment that I'm running moz on Windows XP Pro SP1.
*** Bug 186733 has been marked as a duplicate of this bug. ***
Updating summary to also indicate tabs (as part of a possible pref).  Also
because I'm just about to dupe bug 182339 to here.
Summary: pref to open links from other apps/components in a new window → pref to open links from other apps/components in a new window or tab
*** Bug 182339 has been marked as a duplicate of this bug. ***
This bug is causing me to have to uninstall Moz 1.3 and go back to a previous
version.

It would be great if there were a preference which could be set. But default
should be to open in a NEW window. If not, some people lose work in the window
that gets written over.

As I use my browser as part of my work, the current behavior is unacceptable and
I am unable to use the browser in this state.


> user_pref("advanced.system.supportDDEExec", false);
> In 1.3b, however, these settings seem to have no effect.

It works for me with build 2003032408 under XP.
Comment number 48 solved the issue for me. The two lines given must be added to
the file user.js. It is still working in version 1.3 (on Windows XP SP1). You
may need to create the file user.js.
re: bug 75138 comment 54

This issue seems to be a bit of a quirky one.  I upgraded to 1.3, but the
problem persisted.  I poked around in the registry for a while and noticed that
under HKEY_CLASSES_ROOT\http\shell\open there was a key for ddeexec.  Once I
removed this key, everything worked perfectly.

It seemed as if mozilla was under the impression that ddeexec was already off
(as it was, see bug 75138 comment 48), but the OS had different information. 
Somehow, the two need to sync up.

The behavior I've been seeing has been very strange.  Clicking links from apps
opens pages in a new window.  I also open apps by
Start->Run->http://mozilla.org<enter>.  This usually reuses a window.  Perhaps
it is these two different types of invocation that have been causing my problems.
That fixed it for me!  Thank you very, very much!
Blocks: 205426
When an app opens a browser window, can the browser get the name of the app or
process?

If so, then I would like to see this implemented as "open new tab in window
named `app_name'".  Then if I opened fifteen links from application
"mailreader", the result would be a single new browser window with fifteen tabs
in it.  Links opened from another application would create another new window
with multiple tabs.  Links opened by browsing would not be affected.

There would be a couple of issues to resolve, such as name clashes with
javascript window.open commands -- e.g if an application named "_blank" tried to
open a link.  But I'm sure these could be ironed out.

Seems to me this approach would: (a) limit the number of new windows to
something reasonable, (b) make intelligent use of tabbed browsing; and (c)
prevent dataloss.

*** Bug 207587 has been marked as a duplicate of this bug. ***
*** Bug 209952 has been marked as a duplicate of this bug. ***
*** Bug 213205 has been marked as a duplicate of this bug. ***
re:bug 75138 comment 56

You seem to understand the logic of this much more than I do, as I am merely a 
user. I'm not sure if this would help, but I think I may have identified 
the "quirky-ness" of this problem.

I personally experience the problem with this bug when I browse from the 
Windows address toolbar and that is when dataloss occurs.

When I first installed the new version of firebird it worked correctly, but 
BREIFLY. I think I may have an explanation why this happened, and why it 
stopped functioning properly.

(Again all of this is speculative, so bare with me if my assumptions are 
incorrect.) When I browse with IE, using the Windows address toolbar, it has a 
function where, if you go to a new page it will open up a new browser window, 
with the new URL. This is how it should work. Additionally, if I go back to the 
same URL, it will maximize the window that is already opened with the same URL.

For example: Lets say I open “cnn.com,” then “theonion.com,” 
then “mozilla.org” - I will have 3 pages open. BUT, if instead (for the third 
page) I go to cnn.com again, it WILL GO BACK to cnn.com and only 2 pages will 
be open, with cnn.com maximized. (This is the part of the functionality that 
I’m not sure of, but I think it works this way.)

Could this logic affect this bug? When I installed the new version of Firebird, 
it appeared to work correctly for a while. (I would browse from the Windows 
address toolbar and new windows would open correctly.) Then, if I typed in a 
URL of a page which was already open, it maximized that page (instead of 
opening up a new one) BUT from then on the dataloss continued. ALL new pages 
ONLY opened up in the same window, and this is how the bug appears to everyone 
now. Dataloss occurs because it is reusing windows.

Could the logic that allows for IE to maximize URL’s that are open, be 
affecting the logic in Firebird and thus causing this bug?

[IF THE LOGIC THAT I AM STATING HERE IS INCORRECT, PLEASE STRIKE THIS POST FROM 
BUGZILLA, SO AS NOT CAUSE FURTHER CONFUSION.]
I use the previously mentioned options
  user_pref("advanced.system.supportDDEExec", false);
  user_pref("browser.always_reuse_window", false);
in both my prefs.js and user.js (to be sure Mozilla reads it...).

It works most of the time, but not all the time...

Sometimes Mozilla go back to be reusing old windows, which is a pain. I have no
explanation of when or why it happens. 

It also happened some minutes ago, but then I tried to log off (Start | Log off)
and logged in again, and then it worked again as it should: I got new windows
when I launched URLs from the command line. 

I use Mozilla 1.4 - "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4)
Gecko/20030624".
I, too, have the settings mentioned in comment 63 and still experience the
"window reuse" behavior periodically.  I have tracked this down to the windows
registry.  Something (I think it's mozilla) is changing the registry.  Comment
56 details the changes that are made.

As mentioned in comment 56, removing these items from the registry restores the
preferred behavior.  The main problem here is that something keeps putting this
data back into the registry. If moz is doing it, it needs to stop doing so.
In reference to comment 64, as far as something changing the Registry, whoever
is experiencing (and debugging) this might want to run "Regmon", a utility at
SysInternals:

http://www.sysinternals.com/ntw2k/source/regmon.shtml

The free version will watch Registry access; the for-pay version ($44) will also
write a log file.  (There may be other utilities available that do logging for
free as well; this is the one I'm familiar with, and I'm not associated with
them in any way.)
Windows NT and later can audit selected registry activity in the security event log:

http://windows.about.com/library/weekly/aa112899.htm
http://www.microsoft.com/TechNet/prodtechnol/winxppro/proddocs/regedit_audit_key.asp
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/datacenter/regedit_audit_key.asp

The information in the log is not very human readable (e.g., you get process ID
but not program name), but maybe it could be of use. I have now activated
auditing for the HKEY_CLASSES_ROOT\http\shell key and subkeys on my machine to
see what happens.
I made the changes:

user_pref("advanced.system.supportDDEExec", false);
user_pref("browser.always_reuse_window", false);

after going to about:config and it doesn't seem to make any differance under 
1.5-Alpha release.  Not having links open in their own window is extremely 
irrating, and is the only reason Mozilla isn't my default browser in Windows 
2000.  Can a setting be put in place, similar to that of IE, which says "Open 
shortcuts in new windows" or "Open links in new windows"

re: comment 67

Hans, adding the setting that you mention is what this bug is all about.  If you
want it added, please send in a patch.  At the very least, *please* vote for
this bug.

That being said, check out comment 56 for a workaround.
*** Bug 218158 has been marked as a duplicate of this bug. ***
*** Bug 221573 has been marked as a duplicate of this bug. ***
A workaround for this is to use mozilla-starter:
http://opensource.tuxcenter.net/projects/mozilla-starter/
I know this is not a productive comment, and I also know most of you are
developing Mozilla for free, but Microsoft probably is ROFL because in over 2
1/2 years you didn't solve such a simple bug (and the target for it is still in
the future).

THIS PROBLEM IS REALLY ANNOYING!
IT AFFECTS USABILITY VERY MUCH!

A LOT OF PEOPLE ON WINDOWS DON'T SET MOZILLA AS THE STANDARD BROWSER BECAUSE OF
THIS.

WHEN I ADVOCATE/INSTALL MOZILLA PEOPLE LAUGH AT ME BECAUSE OF THIS BEHAVIOR.

What can be done to speed up this process?

And why this bug depends on 99945 if 99945 is older than this bug?
Just to save people a trip:
mozilla-starter uses -remote functionality and works only on *NIX platforms.
*** Bug 219790 has been marked as a duplicate of this bug. ***
Possibly helpful to programmers for bug 75138 & 99945:

- Not a complaint; thought this might be useful information. -
It appears as if this bug does not occur the first time the application is 
launched.

For the last 3 updates of this browser I have downloaded the latest version and 
installed. It works properly [without dataloss] the first time around, by 
opening new windows every time I enter one in the “quicklaunch toolbar.” 

Then, for whatever reason, after I close Phoenix/ Firebird/ Firefox, and 
relaunch it, dataloss begins to occur. The 2nd time (and ever after) when I 
launch a new link, it replaces the page that is open. 

I found it strange that this occurred exactly the same way every time I 
reinstalled the program. Hope it’s helpful.
I don't know how to add this to Firefox without duplicating it. It should be
listed in Firefox for Mac OS X as well!
*** Bug 178396 has been marked as a duplicate of this bug. ***
*** Bug 236348 has been marked as a duplicate of this bug. ***
there is no dataloss here.  you can always hit back.
Severity: critical → enhancement
Keywords: dataloss
(In reply to comment #79)
> there is no dataloss here.  you can always hit back.

Might there be dataloss if the previous page was generated by a form POST, such
as an order-submit?
> Might there be dataloss if the previous page was generated by a form POST,
> such as an order-submit?

Absolutely.  There are some things that you can't go back to by clicking Back. 
Reinstating keyword.
Keywords: dataloss
Also, it's possible to not notice when an external link reuses a window, and
then close the window instead of hitting Back.
(In reply to comment #82)
> Also, it's possible to not notice when an external link reuses a window, and
> then close the window instead of hitting Back.

Exactly - I have often done that.
*** Bug 226992 has been marked as a duplicate of this bug. ***
*** Bug 250197 has been marked as a duplicate of this bug. ***
*** Bug 247951 has been marked as a duplicate of this bug. ***
Depends on: 172962
Product: Core → Mozilla Application Suite
Mozilla is AWESOME!  
I agree with #24  Whole hartedly.
I am not about to mess with my registry to see if #56 can help me.
Registry stuff really needs to be automated to prevent the likes of me from
really screwing my system up. Perhaps the browser could check for this registry
entry and correct it on startup? 

Please upgrade severity.  Bug 75138 is a MAJOR Nuisance Data Loss Issue. I have
lost several hours on it.
Needs to be upgraded to MAJOR. It DOES meet the definition.
 Also has several DUPLICATES.  Also needs to be retitled.
May I suggest the keyword OVERWRITES.

Great job Everyone it sounds like we are close to a solution!
This gets my vote.

Allowing consistantly remembering of input in the back button situation OR AFTER
AN ERROR IN SENDING would help too! but that would be a different bug that i am
not up to tracking down and reporting as a bug at this moment.
Can we get a more definite target milestone? "Future" is pretty ambiguous.
sure, if you work on the bug, you can pick a target milestone. what'll it be?

note that this is nontrivial given the number of available entrypoints.
Assignee: firefox → worcester12345
Sorry, I am not a programmer if that is what you meant. I only do the testing of
builds for the programmers. We kind of work together if you know what I mean. If
you meant something else for me to do to move this forward to getting fixed, I'm
open for further clarifications.
Target Milestone: Future → mozilla1.8alpha6
(message mostly duplicated in https://bugzilla.mozilla.org/show_bug.cgi?id=35578)

Given that the Mozilla Foundation once intentionally posted a version which
loaded bookmark groups into the existing window/tab set, with no option to
choose another behaviour, I am concerned that this may not be seen as a bug, but
a feature.

So yeah, I'm panicking :-)

(I'm one of those who sets the default bookmark group preference to "Add tabs"
as soon as I configure a fresh installation.  The alternative is anathema!  :-) 

Quite obviously, this is all based on personal habits and working styles, but
ideally, I'd like to be able to choose whether Mozilla does one of four things
upon loading an EXTERNAL link on a PER APPLICATION basis (in order of preference): 
	a. load the first link in a new window and all subsequent links in tabs of that
new window, or
	b. load all links in new tabs in the frontmost window, or 
	c. just load all links in new windows (the previous default [not that I was
ever able to choose!] behaviour), or
	d. replace the last used window with the link's content (the current default).

As a web developer, I often have the need to reload a single page in the same
window over and over again, while working in BBEdit or another external text
editor.  This contrasts entirely with what I want to happen while surfing for
headlines with NetNewsWire.

My arguments for the "new window, then new tab per link" functionality are based
on how I (and, I suspect, many others) use RSS newsreaders and web-enabled PDF
documents etc.  I want to be able to load any number of articles from
headlines/links I've chosen and then switch to the browser to read them at my
leisure.  Previously, Mozilla would spawn a separate window per link, which
quite clearly negated the power of tabbed browsing, but at least I could easily
pick among them using OS X 10.3's lovely Exposé feature.

Currently, I can only load one at a time via clicked links.  Cool for web dev.,
as I've said, but choice is the key thing here.

If I could set up a list of applications (in Mozilla's Prefs) from whom links
were to be loaded in one specific fashion and have the rest of my apps conform
to another setting, then can Nirvana be far behind?

This has been around since 2001?!?!!
Assignee: worcester12345 → guifeatures
QA Contact: bugzilla
Blocks: majorbugs
No longer blocks: majorbugs
Does 172962 fix this bug?  Or are we still looking for more options than just a
new window / new tab in current window preference?
(In reply to comment #92)
> Does 172962 fix this bug?  Or are we still looking for more options than just a
> new window / new tab in current window preference?

Since noone have requested anything more for three months, I'm closing this bug.
Any additional work is probably better filed as new bugs anyway.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(In reply to comment #93)
> (In reply to comment #92)
> > Does 172962 fix this bug?  Or are we still looking for more options than just a
> > new window / new tab in current window preference?
> 
> Since noone have requested anything more for three months, I'm closing this bug.
> Any additional work is probably better filed as new bugs anyway.

What??? Just because nothing has happened in a few months does not mean a bug
should be closed. There are plenty of other bugs open which have not been
touched in a longer period of time!
(In reply to comment #94)
> (In reply to comment #93)
> > (In reply to comment #92)
> > > Does 172962 fix this bug?  Or are we still looking for more options than
just a
> > > new window / new tab in current window preference?
> > 
> > Since noone have requested anything more for three months, I'm closing this bug.
> > Any additional work is probably better filed as new bugs anyway.
> 
> What??? Just because nothing has happened in a few months does not mean a bug
> should be closed. There are plenty of other bugs open which have not been
> touched in a longer period of time!

I agree.  I have half a mind to reopen it myself, but as I'm not a Mozilla
developer or tester, I think that would be presumptuous.
(In reply to comment #94)
> What??? Just because nothing has happened in a few months does not mean a bug
> should be closed. There are plenty of other bugs open which have not been
> touched in a longer period of time!

The reason for closing the bug wasn't that there was no activity for a few
months. Comment 92 asked "Does 172962 fix this bug?". In the few months that
followed no one commented to say "no". Hence --> closed. If you think this bug
should still be open, what is it that you still want done here?
(In reply to comment #96)
... If you think this bug
> should still be open, what is it that you still want done here?


For starters:
(In reply to comment #45)
> I agree.  Thinking about it, dataloss is always a bug UNLESS that's the
> behaviour that's been explicitly stated (by a preference or other deliberate
> user action).
> 
> However, since it's also possible that external links could open new tabs, the
> summary should really be rephrased as follows:
> 
> "Links from other apps/components should not overwrite existing data."
> 
>   (Whether external links open in a new window or new tab would be managed by
> other preferences / bugs.)



Bug 172962 left a lot of unanswered questions and room for improvement. I hope
some of the improvements can make it in. The sooner, the better. Then again,
this stuff is old, and 172962 was Firefox where this one is the suite (should it
be core?). Anyhow, since you asked:


https://bugzilla.mozilla.org/show_bug.cgi?id=172962#c168

https://bugzilla.mozilla.org/show_bug.cgi?id=172962#c186

parts of:
https://bugzilla.mozilla.org/show_bug.cgi?id=172962#c190

https://bugzilla.mozilla.org/show_bug.cgi?id=172962#c199

https://bugzilla.mozilla.org/show_bug.cgi?id=172962#c224

https://bugzilla.mozilla.org/show_bug.cgi?id=172962#c228





(In reply to comment #97)

>> ... If you think this bug
>> should still be open, what is it that you still want done here?

[snipp a lot of references but no wording of what needs to be done]

AIUI you want to change the default value of a pref and change the wording in
the preferences, both of these issues are better filed as separate bugs.
*** Bug 250284 has been marked as a duplicate of this bug. ***
(In reply to comment #98)
> (In reply to comment #97)
> 
> >> ... If you think this bug
> >> should still be open, what is it that you still want done here?
> 
> [snipp a lot of references but no wording of what needs to be done]
> 
> AIUI you want to change the default value of a pref and change the wording in
> the preferences, both of these issues are better filed as separate bugs.


There were a lot of unanswered questions and unresponded to comments. Since you
asked, here they are in order:

"I think we need to create a sticky for the option
browser.link.open_newwindow.restriction.  :)
...
Might it be better to have 0 as the default for this option?  It seems that when
people choose to have all windows open in a a new tab, they MEAN all windows. 
This is confusing when some windows don't follow this."



"Is there a new bug regarding 3)? Or is there now an option to open links
from external apps in the background?"


"Tabbed Browsing
(...)
  [ ] Switch to new tabs opened from links
  [ ] Switch to new tabs opened from bookmarks or history
(...)

But to me, even that is confusing. I propose that the confusion lies in the fact
that the preference is an on/off toggle, but the statement contains two verbs
(switch and open) which makes it harder to parse. By reversing the preference so
that it describes a single action, it becomes much easier to understand: 

Tabbed Browsing
(...)
  [ ] New tabs from links open in background
  [ ] New tabs from bookmarks or history open in background
(...)"



"I don't know if this was missed or not, but I wanted to reiterate that I second
the option to make 0 the default."




"> Might it be better to have 0 as the default for this option?  It seems that when
> people choose to have all windows open in a a new tab, they MEAN all windows. 
> This is confusing when some windows don't follow this.


Was there ever a bug made up for this option?"

Since clicking a url in an email launches another window I am no longer logged onto the site in the first window. Rediculous. I am switching back to Mozilla-broken (Explorer) until you guys offer this as a user-switchable option. Shouldn't have upgraded to 1.5. My old one was working fine until you broke it.
Is there a regression with this? I posted in another bug, but maybe it goes here.

Bugzilla Bug 72361
ctrl+click/middle click a bookmark should open it in new window/new tab
Component: XP Apps: GUI Features → UI Design
Solved by bug 172962. File new bugs if problems arise with URL handlers described in comment 56
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.