Closed Bug 75138 Opened 24 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.