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)
Tracking
(Not tracked)
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.
Comment 1•19 years ago
|
||
Verified in build 2002070108 PC/Win98. Personally, I like it working this way....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 2•19 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•19 years ago
|
||
This is a bug with normal severity.
Severity: minor → normal
Keywords: mozilla1.1
Comment 4•19 years ago
|
||
This also affects going to the URL from an external e-mail application like Pegasus.
Comment 5•19 years ago
|
||
-> 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•19 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?
Comment 7•19 years ago
|
||
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•19 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•19 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•19 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.
Comment 11•19 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•19 years ago
|
||
FYI: At least with 2002071204 trunk under XP, new windows are being created again.
Comment 13•19 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•19 years ago
|
||
Argh, with build 2002072108 my workaround in comment 10 no longer works.
Comment 15•19 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•19 years ago
|
||
Torben, this does not work for me on XP. :(((
Comment 17•19 years ago
|
||
Confirming that this workaround does *NOT* work under XP (I'm using trunk build 2002072204).
Comment 18•19 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•19 years ago
|
||
*** Bug 158958 has been marked as a duplicate of this bug. ***
Comment 20•19 years ago
|
||
IMO, this is a dup of bug 75138.
Comment 21•19 years ago
|
||
*** Bug 159904 has been marked as a duplicate of this bug. ***
Comment 22•19 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•19 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•19 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•19 years ago
|
||
*** Bug 160645 has been marked as a duplicate of this bug. ***
Comment 26•19 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.
Comment 27•19 years ago
|
||
you must create the file "user.js" in your profile (same place as prefs.js)
Comment 28•19 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.
Comment 29•19 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•19 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•19 years ago
|
||
Tep, indeed. comment 10 works fine for me.
Comment 32•19 years ago
|
||
*** Bug 163621 has been marked as a duplicate of this bug. ***
Comment 33•19 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•19 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•19 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•19 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•19 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•19 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•19 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•19 years ago
|
||
*** Bug 164016 has been marked as a duplicate of this bug. ***
Comment 41•19 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•19 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•19 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•19 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•19 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•19 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•19 years ago
|
||
*** Bug 169412 has been marked as a duplicate of this bug. ***
Comment 48•19 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•19 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
Comment 50•19 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.
Comment 51•19 years ago
|
||
*** Bug 174232 has been marked as a duplicate of this bug. ***
Comment 52•19 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•19 years ago
|
||
*** Bug 170254 has been marked as a duplicate of this bug. ***
Comment 54•19 years ago
|
||
*** Bug 178754 has been marked as a duplicate of this bug. ***
Comment 55•19 years ago
|
||
Is anything happening with this? It's the only thing stopping me adopting Mozilla as my standard browser.
Comment 56•19 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•18 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
Closed: 18 years ago
Resolution: --- → DUPLICATE
Comment 58•18 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•18 years ago
|
||
I really must agree - I haven't been able to get this
Updated•17 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•