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)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
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...
Reporter | ||
Updated•24 years ago
|
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
Comment 1•24 years ago
|
||
The wording I suggested was:
Open shortcuts from _other programs using:
(*) new windows ( ) existing windows
(Multiple shortcuts will always open in new windows)
Comment 5•23 years ago
|
||
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.
Comment 9•23 years ago
|
||
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?
Comment 10•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Reporter | ||
Comment 11•23 years ago
|
||
I am turning the dependency around. See bug 35578 for why.
Depends on: 35578
Comment 12•23 years ago
|
||
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
Updated•23 years ago
|
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
Comment 13•23 years ago
|
||
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?
Comment 14•23 years ago
|
||
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?
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla1.0
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.9
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.1
Updated•23 years ago
|
Target Milestone: mozilla1.1 → Future
Comment 15•23 years ago
|
||
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 ...
Comment 17•23 years ago
|
||
See also bug 133188, "Middle Click doesn't open new windows in Tabbed Browsing
mode".
Comment 18•23 years ago
|
||
> See also bug 133188
BTW: That bug has recently been marked as a dupe of bug 101955.
Comment 19•23 years ago
|
||
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
-----------------------------------------------------
Comment 20•23 years ago
|
||
*** Bug 111539 has been marked as a duplicate of this bug. ***
Comment 21•22 years ago
|
||
*** Bug 151009 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
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.
Comment 23•22 years ago
|
||
*** Bug 163155 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
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.
Comment 25•22 years ago
|
||
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.
Comment 26•22 years ago
|
||
Eric: if You need this now try method about which i wrote in bug 163155 .
Comment 27•22 years ago
|
||
Re comment #24: see bug 155402 comment 10 for a workaround.
Comment 28•22 years ago
|
||
*** Bug 165212 has been marked as a duplicate of this bug. ***
Comment 29•22 years ago
|
||
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
Comment 30•22 years ago
|
||
jan. Look at my comment #26 . Follow the link.
Comment 31•22 years ago
|
||
<i>
> From Zbigniew Braniecki:
>
> 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
Comment 32•22 years ago
|
||
Agh. Sorry. What version you're using?
Since Moz1.1 there is almost no waty to open link in new window from external app.
Comment 33•22 years ago
|
||
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
Comment 34•22 years ago
|
||
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
Comment 35•22 years ago
|
||
jan, since you are on mac the following should work:
user_pref("browser.always_reuse_window", true); see bug 121969 comment #16
Comment 36•22 years ago
|
||
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
Comment 37•22 years ago
|
||
*** Bug 163236 has been marked as a duplicate of this bug. ***
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
Comment 38•22 years ago
|
||
See also bug 172962 (Phoenix).
Comment 39•22 years ago
|
||
*** Bug 155402 has been marked as a duplicate of this bug. ***
Comment 40•22 years ago
|
||
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)
Comment 41•22 years ago
|
||
*** Bug 187259 has been marked as a duplicate of this bug. ***
Comment 42•22 years ago
|
||
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.
Comment 43•22 years ago
|
||
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
Reporter | ||
Comment 44•22 years ago
|
||
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).
Comment 45•22 years ago
|
||
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.)
Comment 46•22 years ago
|
||
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
Comment 47•22 years ago
|
||
*** Bug 185553 has been marked as a duplicate of this bug. ***
Comment 48•22 years ago
|
||
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.
Comment 49•22 years ago
|
||
I should add to my last comment that I'm running moz on Windows XP Pro SP1.
Comment 50•22 years ago
|
||
*** Bug 186733 has been marked as a duplicate of this bug. ***
Comment 51•22 years ago
|
||
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
Comment 52•22 years ago
|
||
*** Bug 182339 has been marked as a duplicate of this bug. ***
Comment 53•22 years ago
|
||
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.
Comment 54•22 years ago
|
||
> 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 55•22 years ago
|
||
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.
Comment 56•22 years ago
|
||
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.
Comment 57•22 years ago
|
||
That fixed it for me! Thank you very, very much!
Comment 58•22 years ago
|
||
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.
Comment 59•21 years ago
|
||
*** Bug 207587 has been marked as a duplicate of this bug. ***
Comment 60•21 years ago
|
||
*** Bug 209952 has been marked as a duplicate of this bug. ***
Comment 61•21 years ago
|
||
*** Bug 213205 has been marked as a duplicate of this bug. ***
Comment 62•21 years ago
|
||
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.]
Comment 63•21 years ago
|
||
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".
Comment 64•21 years ago
|
||
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.
Comment 65•21 years ago
|
||
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.)
Comment 66•21 years ago
|
||
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.
Comment 67•21 years ago
|
||
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"
Comment 68•21 years ago
|
||
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.
Comment 69•21 years ago
|
||
*** Bug 218158 has been marked as a duplicate of this bug. ***
Comment 70•21 years ago
|
||
*** Bug 221573 has been marked as a duplicate of this bug. ***
Comment 71•21 years ago
|
||
A workaround for this is to use mozilla-starter:
http://opensource.tuxcenter.net/projects/mozilla-starter/
Comment 72•21 years ago
|
||
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?
Comment 73•21 years ago
|
||
Just to save people a trip:
mozilla-starter uses -remote functionality and works only on *NIX platforms.
Comment 74•21 years ago
|
||
*** Bug 219790 has been marked as a duplicate of this bug. ***
Comment 75•21 years ago
|
||
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.
Comment 76•21 years ago
|
||
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!
Comment 77•21 years ago
|
||
*** Bug 178396 has been marked as a duplicate of this bug. ***
Comment 78•21 years ago
|
||
*** Bug 236348 has been marked as a duplicate of this bug. ***
Comment 79•21 years ago
|
||
there is no dataloss here. you can always hit back.
Severity: critical → enhancement
Keywords: dataloss
Comment 80•21 years ago
|
||
(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?
Comment 81•21 years ago
|
||
> 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
Comment 82•21 years ago
|
||
Also, it's possible to not notice when an external link reuses a window, and
then close the window instead of hitting Back.
Comment 83•21 years ago
|
||
(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.
Comment 84•20 years ago
|
||
*** Bug 226992 has been marked as a duplicate of this bug. ***
Comment 85•20 years ago
|
||
*** Bug 250197 has been marked as a duplicate of this bug. ***
Comment 86•20 years ago
|
||
*** Bug 247951 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 87•20 years ago
|
||
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.
Comment 88•20 years ago
|
||
Can we get a more definite target milestone? "Future" is pretty ambiguous.
Comment 89•20 years ago
|
||
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
Comment 90•20 years ago
|
||
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.
Updated•20 years ago
|
Target Milestone: Future → mozilla1.8alpha6
Comment 91•20 years ago
|
||
(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?!?!!
Updated•20 years ago
|
Assignee: worcester12345 → guifeatures
QA Contact: bugzilla
Comment 92•20 years ago
|
||
Does 172962 fix this bug? Or are we still looking for more options than just a
new window / new tab in current window preference?
Comment 93•19 years ago
|
||
(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
Comment 94•19 years ago
|
||
(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!
Comment 95•19 years ago
|
||
(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.
Comment 96•19 years ago
|
||
(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?
Comment 97•19 years ago
|
||
(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
Comment 98•19 years ago
|
||
(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.
Comment 99•19 years ago
|
||
*** Bug 250284 has been marked as a duplicate of this bug. ***
Comment 100•19 years ago
|
||
(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?"
Comment 101•19 years ago
|
||
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.
Comment 102•19 years ago
|
||
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
Comment 103•15 years ago
|
||
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.
Description
•