155402 - URLs no longer launch in a new window when typed in from Start Button/Run bar or launched from a different application

Status: RESOLVED DUPLICATE of bug 75138

Description

[Maddox Belford]

In 1.0 and before, I was able to type in a new URL in the Start Button/Run bar,
and it would launch in a new window.  However, in the last few nightlies of
1.1alpha, this has stopped working, and the URLs launch in the same window. 
There seems to be no way to change this behaviour under Preferences.

Comment 1

[Bill Mason]

Verified in build 2002070108 PC/Win98.

Personally, I like it working this way....

Comment 2

[Maddox Belford]

I realize many people do, but if its going to do this from here on as default, I
think it may be good to put in an option like IE has: Reuse windows for
launching shortcuts.  

Comment 3

[Andrew Hagen]

This is a bug with normal severity. 

Comment 4

[Andrew Hagen]

This also affects going to the URL from an external e-mail application like Pegasus.

Comment 5

[Matthias Versen [:Matti]]

-> Xp APPS 

What Do you mean with last few 1.1a nightlys ?

Comment 6

[Andrew Hagen]

I saw this first in Build ID: 2002070204 in Windows 98. I don't think it was in
the July 1 build. Maybe someone has a different answer than this, though?

Comment 7

[Matthias Versen [:Matti]]

yes, that is what i thought. (
It's no real bug... 

from bug 154238#c13
>There is one minor *change* in behavior (not sure it would qualify as a
>regression):  when the shell uses DDE to open a new file or window, that
>happens in the most-recently-used browser window, instead of opening a new
>window.

-> Law

Comment 8

[Andrew Hagen]

Correction to my earlier post: I'm not seeing this all the time. I haven't
figured out a pattern yet.

Comment 9

[Eugene Savitsky]

Saw this on 2002070104. It was not present in  20020626xx build. Very annoing -
I open many links from mail (not moz, but The Bat!) and coz this I lost many
info in already opened links. Not really lost, but I was confused where it gone.

Adding regression keyword.

Comment 10

[Torben]

I found a workaround: in user.js put: 
user_pref("advanced.system.supportDDEExec", false);
Removing the correspodening line from all.js (see bug 154238#c34) may also work,
I haven't tried.
The OS-field should be changed since this occurs on both win95, 98 and 2000.

Comment 11

[Eugene Savitsky]

Changing Summary to more precize. Maybe someone can do it more clearly and short?

Comment 12

[Jason Bassford]

FYI: At least with 2002071204 trunk under XP, new windows are being created again.  

Comment 13

[Jason Bassford]

Correction to comment 12.  As with comment 8, the behaviour appears to be
somewhat random - at least I can't confirm a pattern.  After reporting that
links opened in new windows again, this stopped happening.  I've seen new
windows a few times since, but opening in the same window at least as often, if
not a bit more.

Comment 14

[Torben]

Argh,
with build 2002072108 my workaround in comment 10 no longer works.

Comment 15

[Torben]

I found an other workaround which seems to always work:
user_pref("browser.always_reuse_window", false); in prefs.js/user.js (from bug
121969 comment #16).
I think this should be set as default.

Comment 16

[Eugene Savitsky]

Torben, this does not work for me on XP. :(((

Comment 17

[Jason Bassford]

Confirming that this workaround does *NOT* work under XP (I'm using trunk build
2002072204).

Comment 18

[Torben]

Strange, with mozilla 1.1beta (aka build 200207204) the first workaround
(comment 10) works again, but not the last (comment 15).

Comment 19

[Bill Mason]

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

Comment 20

[Jesse Ruderman]

IMO, this is a dup of bug 75138.

Comment 21

[Bill Mason]

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

Comment 22

[Steve Peterson]

I'm seeing this consistently on 2002072808 on Win2K SP2, launching URLs from Eudora.

My first preference for launching links would be to open a new tab in an
existing window and raise the window's focus.  2nd preference would be to open a
new window.

Comment 23

[Frank Burleigh]

So as of yesterday's builds we see this reuse behavior on XP and on NT on links
clicked from Outlook.  Does mozilla.org accept that this is a regression that
ought to be corrected?  If not, the potential workarounds might not be good,
since those can be changed, too.

Comment 24

[Justin D. Morgan]

While solving this bug, why not go ahead and make this feature customizable. 
Add a choice for the three possible behaviors:

1. Reuse windows (open one if none exist).
2. Open the link in a new tab of the current window.
3. Open the link in a new window.

This would make everyone happy and provide for the utmost in customizability. 
Who knows, this bug might actually turn into choice #1.

Comment 25

[Alfonso Martinez]

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

Comment 26

[manojd]

Comment#15 & comment#10: Where is "user.js"? I don't see it anywhere under my
"Documents & Settings" or Mozilla installation directory. Am running Mozilla 1.1
Beta (Build 2002072104) on Windows 2000. Thank you.

Comment 27

[Matthias Versen [:Matti]]

you must create the file "user.js" in your profile (same place as prefs.js)

Comment 28

[Torben]

Re comment #24: a pref would be bug 75138, new tab instead of window is probably
bug 104204.
IMHO this bug is about fixing the regression introduced while fixing bug 154238.

Comment 29

[Eugene Savitsky]

Any new here? 

I need to do more work as usual using moz now. First, when I need to open a link
from my mail client I do:

1) switch to moz
2) open a new window
3) switch to mailer

This is instead of just clicking on the link.

I also lost many times URLs I needed. :(

Can we raise the priority of this bug?

Nominating for nsbeta1.

Comment 30

[Steven Bush]

In Daily Build: 2002080604, Win98

I found that following the instructions in comment #10 was successful in
changing the behavior, though the instructions from comment #15 had no effect. 
However, after following comment #10's instructions, external links are now
opening in new windows successfully.

You may want to give that a try.

Comment 31

[Eugene Savitsky]

Tep, indeed. comment 10 works fine for me.

Comment 32

[Alfonso Martinez]

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

Comment 33

[Frank Burleigh]

This regression is way annoying.  I was listening to a seminar in an embedded
media player in a browser window whose content designer had given no sizing or
menu controls.  I clicked a link in Outlook, and Mozilla reused *that* browser
window.  So I lost where I was and couldn't read the new material, either.  I've
recently had other cases where Moz focusses its mail window if one is open,
which might be related if not the same.

If we're counting, there are several of us here who would rather you create a
new window *by default.*

I also think the summery doesn't do justice to the annoyingness of this behavior
since it's user action is narrow, specific and exclusive.

THanks.

Comment 34

[Peter Lockhart]

yesterday I had a link which I clicked in OE, launch in the print preview window
I had open :)
Shouldn't this bug be a 1.1 release blocker ?

Comment 35

[Steve Peterson]

More interesting behavior related to this.  Not sure if it's a separate bug or
another manifestation of this one.

Using 2002072808 on Win2K SP2.

Steps to reproduce:

1.  Download a file from a site.  At this point there should be two windows --
the browser window and the download status window.  Make sure the download
status window has the focus.

2.  Do a "minimize all".  Both windows should hide.

3.  Now go to Eudora and click on a link.

4.  The download status window raises, but the browser window does not.

5.  If you manually raise the browser window, the link shows in the current window.

Expected behavior:  browser window with new content is raised.

Comment 36

[Eugene Savitsky]

It's the same bug. I also saw this.

Adding Asa to CC (sorry, Asa, but this bug really needs some attention).

Comment 37

[Bill Mason]

Today I noticed in build 2002082308 that URLs I launch from the Start button or
from my e-mail now open in a new window instead of using existing windows.  And
I haven't tried any of the previous workarounds suggested, so it appears that
the browser's default behavior has flipped again.

Comment 38

[Frank Burleigh]

I just installed 2002082308 trunk on XP, clicked in Outlook the bugzilla link in
the comment created by [e-mail], and did not get a new
window but instead the reuse of the already-open window.  Then I tried typing a
uri in Run and also got reuse (hence reusing the browser holding the part of
this comment I had already written but happily moz kept the form's contents ;-).

Comment 39

[Jason Bassford]

It's been opening in a new window *most of the time* for me for the past couple
of weeks.  But, sometimes, it will still open in the same window.

Previously, it would open in the same windows *most of the time* and, sometimes,
in a new one.

I still have no idea what's causing one behaviour over the other.  However, it's
most likely behaviour (now) is to open in a new window.  But it's still not
100%.  Very confusing...

Comment 40

[R.K.Aa.]

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

Comment 41

[jlbryan]

For me, since 1.1, going to a URL from an external e-mail ALWAYS reuses an open
window.  The only thing random about it for me is which window (of the several I
might have open) it reuses.

This 1.1 reuse behavior is bad.  I am a research lirbarian, and it's causing me
to lose data while I'm searching online catalogs, indexes, or otherwise using forms.

Thanks for listening.

Comment 42

[Scott Johnson]

Don't forget to <a
href="http://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=155402">vote
for this bug</a> if it's such a problem for you.  Thanks!

Comment 43

[manojd]

Workaround from comment#10 works for me too - thanks to author of comment#27 too
for helping create "user.js". My platform - Win 2K, & Mozilla/1.1 (date code no
longer appears in title bar, but Help/About says "Gecko/20020826").

There is a caveat, however, to creating "user.js". If I simply copy "prefs.js"
to "user.js", Mozilla cribs about a bad character in startup file when a Mozilla
window is closed. It doesn't like "#" as first character in "user.js" - though
that is the first character in "prefs.js". Things worked once I put "//" in
front of it.

Whole of my "user.js" is now:
---- begin
//# Mozilla User Preferences
// This is a generated file!

user_pref("advanced.system.supportDDEExec", false);
---- end

Comment 44

[stephen roberts]

Scrolling through the comments, I tried out comment #10 and it seems to work
just great! Haven't had an overwrite since I re-loaded after the fix.

One question: I found the file prefs.js in 2 locations

Application Data\Mozilla\Users50\default\z291vtpo.slt
Application Data\Mozilla\Users50\default\z291vtpo.slt-new

I put the "fix" for user.js in both directories just to be safe. I just wanted
to point out the strange spare directory in case others try the user.js fix.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721

Comment 45

[Carl Smotricz]

For me, on W2K and Moz 1.1 build "Gecko/20020826", I can confirm this has been
happening consistently when I followed SlashDot links from Eudora.

Comment#10 has helped me too, many thanks Torben!

My 2c:
- Disabling DDE is a kludgy workaround which sacrifices some (less used)
functionality. A true fix would be a real boon!
- My own preferred solution would be for the first DDE call to open a new window
(regardless of any already open windows) and successive DDE calls to open new
tabs in that same window.
- Since this is probably not everyone's preferred way to do it, customizing this
stuff (if only from *prefs.js) would probably be better yet.

Comment 46

[Kev Swindells]

My 2c worth
I also find this bug extreamly annoying, and the original way of Mozilla working
(opening each link in a seperate window) was what made me stick with Mozilla
long enough for me to get to like it.

If this bug isn't sorted soon i will be contemplating switching back to internet
explorer.

I would prefer a new window for each link (i don't like tabs as i use ALT-TAB to
switch between windows), but the three options suggested above someware (reuse,
new window, new tab) would be far far better and keep everyone happy.

Comment 47

[Alfonso Martinez]

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

Comment 48

[Tim Hunt]

I think that this merits a dataloss keyword. I keep losing windows containing
information I still need, and then have to go and find them again.

Comment 49

[Eugene Savitsky]

The work around does not work for me for last 5 days after I installed build
from 18(?) september. Is this only me or all sees this?

How can we get more attentsion to this bug?

Comment 50

[Kev Swindells]

If user.js is over written with each build then the 23002091014 build implements
this properly.  The second stable release only did this when it felt like this.

If not, do the suggestion in no.10 and that will sort it.

Comment 51

[Matthias Versen [:Matti]]

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

Comment 52

[Torben]

Does anyone following this bug build moz them self/have access to MSVC++ ? If so
could you try to change this line in nsNativeAppSupportWin.cpp
const char ddeexec[] = "\"%1\",,-1,0,,,,";
to
const char ddeexec[] = "\"%1\",,-1,-1,,,,";
(see bug 154238 comment #13) and see if this fixes this bug.

Comment 53

[Torben]

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

Comment 54

[Bill Mason]

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

Comment 55

[Andrew Ducker]

Is anything happening with this?  It's the only thing stopping me adopting 
Mozilla as my standard browser.

Comment 56

[stephen roberts]

Confirming that as of 20021130 on Win2K, this issue is back.

It _was_ working with 1.2.1 (or at least I hadnt noticed it :-), then I had to
drop and reload 1.2.1 and its back.

I checked all user.js and prefs.js files in all directories and they all had the
fixes from comment #10 and comment #15

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

I dont care what opening a new link does (new window or new tab) so long as it
doesn't override my current window :-(

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

Comment 57

[Jesse Ruderman]

Links from other apps now work the same way as links in mail messages.  That's a
good thing (internal consistency) and not a regression.  The remaining problem
is that links from both mail messages and other apps recycle windows, leading to
frustration and potential dataloss.

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

Comment 58

[zanezane.net]

Well, I tried every work around but noone seems to work for me (rv:1.0.2)
Gecko/20021216). 

I fully agree with Justin @ comment 24, that would be good.

This bug is EXTREMELY ANNOYNG, I keep on loosing data!! Please Mozilla Crew,
relase a fixed version quickly, I think many of us are waitning for this bug to
be fixed!!

Comment 59

[Thomas Østergaard]

I really must agree - I haven't been able to get this