Closed Bug 155402 Opened 19 years ago Closed 18 years ago

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

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 75138

People

(Reporter: Bugzillamozilla, Assigned: law)

References

Details

(Keywords: dataloss, regression, Whiteboard: nsbeta1) 

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.
Verified in build 2002070108 PC/Win98.

Personally, I like it working this way....
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.  
This is a bug with normal severity.
Severity: minor → normal
Keywords: mozilla1.1
This also affects going to the URL from an external e-mail application like Pegasus.
-> Xp APPS 

What Do you mean with last few 1.1a nightlys ?
Assignee: Matti → sgehani
Component: Browser-General → XP Apps
QA Contact: imajes-qa → paw
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?
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
Assignee: sgehani → law
Correction to my earlier post: I'm not seeing this all the time. I haven't
figured out a pattern yet.
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.
Keywords: regression
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.
OS: Windows 2000 → Windows 95
Blocks: 121969
Changing Summary to more precize. Maybe someone can do it more clearly and short?
Summary: URLs no longer launch in a new window when typed in from Start Button/Run bar → URLs no longer launch in a new window when typed in from Start Button/Run bar or launched from a different application
FYI: At least with 2002071204 trunk under XP, new windows are being created again.  
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.
Argh,
with build 2002072108 my workaround in comment 10 no longer works.
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.
Torben, this does not work for me on XP. :(((
Confirming that this workaround does *NOT* work under XP (I'm using trunk build
2002072204).
Strange, with mozilla 1.1beta (aka build 200207204) the first workaround
(comment 10) works again, but not the last (comment 15).
*** Bug 158958 has been marked as a duplicate of this bug. ***
IMO, this is a dup of bug 75138.
*** Bug 159904 has been marked as a duplicate of this bug. ***
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.
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.
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.
*** Bug 160645 has been marked as a duplicate of this bug. ***
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.
you must create the file "user.js" in your profile (same place as prefs.js)
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.
Blocks: 161466
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.
Whiteboard: nsbeta1
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.


Tep, indeed. comment 10 works fine for me.
No longer blocks: 121969
*** Bug 163621 has been marked as a duplicate of this bug. ***
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.
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 ?
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.
It's the same bug. I also saw this.

Adding Asa to CC (sorry, Asa, but this bug really needs some attention).
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.
I just installed 2002082308 trunk on XP, clicked in Outlook the bugzilla link in
the comment created by bugzilla@accessibleinter.net, 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 ;-).
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...
*** Bug 164016 has been marked as a duplicate of this bug. ***
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.
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!
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
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
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.
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.
*** Bug 169412 has been marked as a duplicate of this bug. ***
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.
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?
OS: Windows 95 → All
Keywords: dataloss
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.
*** Bug 174232 has been marked as a duplicate of this bug. ***
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.
*** Bug 170254 has been marked as a duplicate of this bug. ***
*** Bug 178754 has been marked as a duplicate of this bug. ***
Is anything happening with this?  It's the only thing stopping me adopting 
Mozilla as my standard browser.
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
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 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
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!!
I really must agree - I haven't been able to get this
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.