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

RESOLVED DUPLICATE of bug 75138

Status

SeaMonkey
UI Design
RESOLVED DUPLICATE of bug 75138
15 years ago
6 years ago

People

(Reporter: Maddox Belford, Assigned: Bill Law)

Tracking

({dataloss, regression})

Trunk
x86
All
dataloss, regression

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: nsbeta1)

(Reporter)

Description

15 years ago
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

15 years ago
Verified in build 2002070108 PC/Win98.

Personally, I like it working this way....
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

15 years ago
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

15 years ago
This is a bug with normal severity. 
Severity: minor → normal
Keywords: mozilla1.1

Comment 4

15 years ago
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

Comment 6

15 years ago
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

Comment 8

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

Comment 9

15 years ago
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

Comment 10

15 years ago
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.

Updated

15 years ago
OS: Windows 2000 → Windows 95

Updated

15 years ago
Blocks: 121969

Comment 11

15 years ago
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

Comment 12

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

Comment 13

15 years ago
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

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

Comment 15

15 years ago
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

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

Comment 17

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

Comment 18

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

Comment 19

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

Comment 20

15 years ago
IMO, this is a dup of bug 75138.

Comment 21

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

Comment 22

15 years ago
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

15 years ago
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

15 years ago
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

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

Comment 26

15 years ago
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)

Comment 28

15 years ago
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.

Updated

15 years ago
Blocks: 161466

Comment 29

15 years ago
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

Comment 30

15 years ago
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

15 years ago
Tep, indeed. comment 10 works fine for me.

Updated

15 years ago
No longer blocks: 121969

Comment 32

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

Comment 33

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
It's the same bug. I also saw this.

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

Comment 37

15 years ago
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

15 years ago
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 ;-).

Comment 39

15 years ago
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

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

Comment 41

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
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

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

Comment 48

15 years ago
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

15 years ago
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

Updated

15 years ago
Keywords: dataloss

Comment 50

15 years ago
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. ***

Comment 52

15 years ago
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

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

Comment 54

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

Comment 55

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

Comment 56

15 years ago
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

15 years ago
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
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 58

15 years ago
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

15 years ago
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.