Open Bug 18808 Opened 25 years ago Updated 1 month ago

New windows/tabs should inherit current page, back button/go menu history

Categories

(Core :: DOM: Navigation, enhancement, P5)

Product:
Core
Component:
DOM: Navigation
Type:
enhancement

Tracking

()

Milestone:
Future

People

(Reporter: CodeMachine, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: helpwanted, Whiteboard: DO NOT COMMENT, WE KNOW PEOPLE WANT THIS)

Attachments

(2 files, 1 obsolete file)

Fixed code from Tab History addon that works good with Fx 4.0
1.31 KB, text/plain
Details
This works way better than the 1st code I've posted as Paul Hater.
2.99 KB, text/plain
Details 
Nav used to automatically inherit the list of previous pages when you spawned a
new window.  Then it disappeared for some reason, and it seems to have continued
like this in Moz.  It is quite useful and would be really nice to have.
Ack! I like the general idea, but, for me, that could be up to hundreds of
items in the back button/go menu history, depending on how the tree grew.
Normally with NN 4.7 I will spawn at least dozens of browser windows and view
anywhere from one to dozens of pages in each, before getting the sense that
it is time to reboot a few days later (most windows have been closed in the
meantime, but usually at least a few from the first day are active).
(Anytime I do that it is time to file bookmarks, etc, so it happens no more
often than necessary). There would need to be some sort of FIFO limit placed on
the size of the history stack in each browser window to keep this from getting
unwieldly. Stack and fifo at the same time - ouch.
The go menu in nav 4 already had a 10 limit I believe, and back already works
forever.

It should be possible to do some sort of sharing of URL lists to reduce the
memory usage of new window.
Assignee: don → german
not sure I agree with the original bug here.
Over to german for UI look.
*** Bug 22721 has been marked as a duplicate of this bug. ***
I'm not sure about having all of the old page's history appear in the
newly-spawned window's history lists for one reason: even for users
used to hypertext navigation, it is useful to have the history of a
browser window rooted so that there is a known point to return to.
For users unfamiliar with hypertest navigation, this can be essential,
but even for old hands, it is possible to lose track - "Which of these
titles was that page again?".

If this proposal prevails over no action and an alternative presented
in bug 22788 "RFE: Spawned windows should inherit previous page in history"
where only the referring page is preloaded into the new window's Session
History, IMHO the page first loaded into the spawned window should have a
distinctive appearance on both the Go menu and the Back-button and
Forward-button drop-down menus, so that the user can see where he or she
started in that window, as a reference point.
I have never had a need to go to a "root", so I can't speak for others.

Novice users "unfamiliar with hypertext navigation" rarely use more than one
window, so if a new window opened (eg a page opened a link in a new window) they
would start using the new window solely.  Hence inheriting the entire back
history is better for them too.

The issue of which back history a specific page was in is certainly there, but
it's there no matter whether you have a new root, unless you want to do
something like display your new root somewhere special.  If you want to do
things like this, the history provides the ability a lot better than hunting and
pecking through multiple windows.
I also can't recall ever trying to get back to a root window. On the other hand,

since I switched to Navigator 4, I frequently find myself opening multiple

windows to read several pages on a large site, accidentally closing the parent

window and losing all my history.



To me, at least, picking out a location in a longer history list is much easier

and more forgiving than having to remember which of 6 Slashdot or CNN pages is

the parent window.
Let me put this in no uncertain terms.  I constantly lose productivity through
the lack of this, and I'm sure many others do too.  History does not make up for
the loss of this, since it is essentially a unknown entity (which I have to
spend time opening), whereas I remember my windows.  It is a lot easier to just
open up a back menu.

If you want it the way it is for some unknown reason (and noone has explained
one to me that holds other than the touchy-feely "I like it better that way")
then there has never been a better case for a pref.

Bug #22788 and bug #23926 are partial solutions, but they are not solutions, and
I still will not be able to browse properly.

I should point out that my concern is with "Open Link In New Window" and the
like, and NOT with "Open New Nav Window", which can do what it likes, as far as
I'm concerned, if it would make ppl happier about this RFE.
(slightly disagreeing with matt) I'd like Ctrl-N to inherit history, too.  An 
example of why: say I have this bug open, but want to open bug number 99999 
because someone mentioned it in the page (but bugzilla didn't make a link).  In 
IE, I can do that very quickly: double-click bug number, copy to clipboard, 
ctrl-N, alt-D, end, ctrl-shift-left (to select the id of this bug), paste.  In 
Mozilla, I currently have to either type http://bugzilla.mozilla.org/ into the 
address bar or ctrl-L (neither of which is completely keyboard-accessible at 
the moment), or do multiple copies (the entire URL of this bug, then the new 
bug number).  It would be nice if mozilla also opened the current URL in the 
new window, but I could live with having to hit alt-back from my start page.
*** Bug 32549 has been marked as a duplicate of this bug. ***
I like this -- I frequently get caught out when I close the wrong window and lose 
a valuable window history, too.

The only potential problem with this is that if in maximized mode on Windows, the 
user might not realize that a new window had actually opened -- especially if the 
Windows taskbar was hidden. (Previously, the change in appearance of the Back 
button from enabled to disabled would have given a clue, but if this RFE was 
implemented it wouldn't.)

Perhaps this could be resolved by special-casing bug 17149 not to inherit 
maximized status for new windows -- but that might be too annoying. (Any other 
suggestions?)

I also use this feature when I've gone to a site with multiple links and I 
click on one which turns out to be a long load.  While I'm waiting for it to 
load, I'll often ^N to get a new window at the current spot with the same 
history, back to go to the page with the links and click another one to have it 
loading at the same time (all of this, assuming I'm in IE--in Opera, I 
use "Duplicate Window" instead, which does the same thing).  If we're concerned 
about new users, perhaps the "Duplicate Window" alternative would be a better 
option--that way "New window" comes up new, but we can choose to do what we 
want.
Ideally, new windows would inherit history but also give some kind of 
indication to the user that "there might be another window open that you can go 
to instead of pressing back".  Several less-than-great ways to do this would be 
to change the back button appearance or to add an extra history item.  (Should 
there also be an indication as to whether the old window is still open and 
still on the same page?)
> (Any other suggestions?)

Yeah, write "This is a new window, the previous one still exists." on the status
bar.  It's about as good as the current "disable back button" behaviour.
Sorry for being so thick-headed, but when would you display that message on the 
status bar?
This feature ( back button/go menu history) works only on per window base, as 
current 4.x does.
For users who need to see every previous page they viewed, they will have to use 
the history feature. 
mark this one as WON'TFIX.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
With due respect, I don't understand the logic of the answer.  I'll call it an
enhancement if you'd like, but saying that it won't be done *because* it hasn't
yet been done seems considerable circular!
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Both features are done in the way we think fits most of users' needs. You can 
keep the discuss open. However, due to other high priority features, I am 
setting this one to later milestone for future investigation if time permits.
Target Milestone: --- → M30
The message on the status bar would appear once the window opens, until you do
something.

shuang, please use the Future milestone rather than WONTFIX, LATER or M30.
Target Milestone: M30 → Future
IE5 has this feature and I must say i find it ***VERY*** handy. I use it daily, 
at least. I've been meaning to file an RFE on this for some time, never got 
around to it, and just noticed this open bug today. Adding a vote (thats 6...).

IE5's implimentation: ctrl+N pops up a new window, your current page is loaded 
in that window automatically... this is handy as well. instead of the useless 
blank window netscape gives you (well, my homepage is about:blank...), IE5 
basically clones your session, allowing you to split it up, take differant 
paths. Once the new window is loaded, the path is permanently forked. The 
histories aren't shared, as was suggested here. This is ideal, IMO.

There was another bug somewhere that talked of a tree-like history menu for the 
sidebar, which might be cool, but is a huge RFE project. Just doing the IE5 
implementation would be good enough for me, but the folks pondering the tree-
history might be interested in integrating with this new window fork.

Does Target furture mean after mozilla-5.0 ships? This really is a severe 
usability enhancment, and for the (not unreasonably large) ammount of work 
required, I think it should be done M19-M21ish.
Just remembered where this comes in handy...

I was surfing around bugzilla with IE5 today, and was went to go file a bug 
report. I got a few minutes in to seting all the enter_bug.cgi widgets just so, 
and realized I needed to refer to something in the bug i was just at. So i hit 
CTRL+N, and alt+left arrow a few times, and im back there.

How would I have even done this in netscape, without history inheritance? I 
can't go back from the first window, or i lose the 95% done bugzilla filing. I 
have to open up a new window, and try to get back to where I was. Maybe i can 
look under the go menu from window 1 and get the page's <title>, but i don't 
dare release the mouse button on it.

There are many other situations where this is very useful, but its one of those 
things that you cant think of unless you catch yourself doing it. The usability 
enhancment is so wired into me, i'm able to enhance my browsing power with it 
and not even realize that what im doing would be a huge pain in netscape 
4.7/mozilla. Trust me on this one ;)
I think there's no chance of Netscape doing this for N6.  Your best bet is to
try to get enough other people to vote on this to wake some people out of their
dream world.
Status: REOPENED → ASSIGNED
This happens with IE browsers too. You don't have to copy every feature of an 
IE broswer, and especially not the bad ones
Granted.  But it would be ok to copy one of the spectacularly good ones :-).
Alternatively, you can do a ctrl-N (opening a new blank window),
ctrl-H (opening the history) then drag the page from history
in the newly opened window. Not very convenient, but a workaround
none the less..
This is a very useful feature - Opera 3.60 has something similar, in its
duplicate window command, and I use it frequently, particularly when I want to
be able to explore another part of a site without having to go back up a few
levels then open a new window from there.

IE5's version of this feature has one major problem IMO - it duplicates the
current window by default, i.e. new window opens up the current URL again.  If
the current window is the 'order confirmed' page of an e-commerce site, there's
a risk that your order could be re-submitted, which is hardly a good default
behaviour (though I've not tried this, being too chicken...).

I suggest NS6/Mozilla should implement this feature as a new 'duplicate/clone
window' command - this will only be used by experts, and would open the new
window on the current page, with full history.  The default New Window command
should just open the current window on the configured home page, as with NS4,
which will be less surprising to newbies.
Just don't resubmit form data? Shouldn't be hard.
Better yet, just load it from cache. Then it's not resubmited. If memory and
disk cache are disabled, prompt the user, explaining the situation. IE5 does
this, I believe, when you go reload a CGI page.
I miss having this feature a great deal, and another poster commented that alt-N
(open a new browser window) should also inherit the 'back' button history.  
That sounds goo to me too, I would also want that!
I think 43 votes is quite enough :-), so reassigning this RFE from a UI person to 
a programming person. Also adding helpwanted.

To summarize: When a browser window is the active window, any command which opens 
a new window (whether `File' > `New', or `Open Link in New Window', or Ctrl+N, or 
whatever) should clone the properties of the existing window. These properties 
include:
* URI (except for `Open Link in New Window')
* Back/Forward history (except that `Open Link in New Window' loses Forward
  history)
* maximized/non-maximized state (unless opened as TARGET="_whatever" or by a
  script, in which case the window should always be non-maximized, like it is in
  MSIE)
* horizontal and vertical scroll position
* keyboard focus
* DOM state (e.g. contents of form elements)
* character encoding
* user-selected style sheet
* chrome state, e.g. toolbars shown/hidden (except where otherwise specified by a
  script).
Sufficient for this bug to be FIXED would be to inherit only the URL and the 
Back/Forward history; separate bugs could then be filed for the other items where 
needed.

The command should never result in anything being reloaded, regardless of cache 
settings (just like Save, Print, etc should never result in anything being 
reloaded). If information is not available from the cache, error pages and/or 
proxy icons should be shown where appropriate instead.

If I've missed anything, post your errata here.
Assignee: german → don
Status: ASSIGNED → NEW
Keywords: helpwanted
QA Contact: don → sairuh
this sounds like something for History, yes? please lemme know if not.
Assignee: don → radha
Component: XP Apps → History
QA Contact: sairuh → claudius
Summary: Spawned windows should inherit back button/go menu history. → [RFE]Spawned windows should inherit back button/go menu history.
Ouch. *Please* add a preferences setting or something to turn the feature off.
Or better, to turn off the "back" button at the "root URL".  Also insert a fat
"--parent window's history--" line at the proper place in the history menu.  I
agree the new feature'll be nice sometimes, but I vastly appreciate the old way.

As for File/New..., I sure won't want the default to inherit whatever I've had
to do to my window in order to decipher some weird WWW page I just visited. I'm
even unsure I'd want it in the majority of my "visit URL in new window" clicks.
Due to search engines & so on, I often go _from_ horrible pages _to_ nice ones.

Hm. Maybe you could _name_ the inheritable settings, and add a prefs setting
with a list of which ones to inherit?  That could even be expanded someday to
say which _preferences_ settings should be inherited and which ones shouldn't.
Sorry, I should have added:  Like everyone else here I _do_ pine for a way to
clone a window, with URL and all (though without the "Back" button:-).
Just as long as a way to open an unencumbered window remains.
First of all, as one of the primary instigators of this issue, thanks for 

listening! I really appreciate that Netscape is taking a second and a third look 

at this.



Now, I hate to keep complaining but -- I think it's overkill to extend this to 

opening a new window. To me, clicking on a link to open in a new window should 

fork the window history into two equal streams. Creating a new window, on the 

other hand, should do that -- open a new window with no bias towards any 

existing windows. (To be precise, I'm endorsing a return to the behavior in 

Netscape < 4.0.)



If this plan is what's used, some possible refinements are:



* If "Navigator Starts With:" is set to Blank Page, new window opens a blank 

page with no history or URL. Opening a link in a new window would still retain 

the history (maybe subject to a preference).



* Only one round of inherited history per window, to keep history from becoming 

huge and all-inclusive.




> I really appreciate that Netscape is taking a second and a third look at this.

They're not.

> Only one round of inherited history per window, to keep history from becoming
> huge and all-inclusive.

I can imagine a data structure which could share session histories between 
windows (forking the history for individual windows, where necessary) so that the 
history didn't become huge. It wouldn't be a linked list, exactly, or a tree ... 
more like a seaweed. (If you're thinking of implementing this, e-mail me and I'll 
write up some pseudocode.)

But assuming a never-crashing Mozilla on a never-crashing OS, we'd still need a 
pref for how long the Back/Forward history should last before gradually expiring 
(see also bug 21521).

I dont see how anyone can have any objection to this feature (Re: Mr. Furuseth's
comments). Why bother with a preferance not to inherit the history, just don't
click the back button if you don't want to.

I've really never heard of anyone wanting to turn this great feature off in IE5.
The reason I don't want to inherit the "Back" button is that I tend to save each
task/subject to a separate window.  I don't want "Back" to take me from one task
into another, and later confuse me about how far I've come in which task.
With 8 windows, "just don't click the back button" translates to "always stop
and think before I click the Back button".  I can, of course, but it's much
nicer to have the browser think for me.
(The same goes for a history without the "--parent...--" line I mentioned, but
I don't imagine that's a very controversial idea:-)
I've notice a related problem: a new window (spawned with button2 or the context
menu) doesn't propagate the referer. For example, take a page with a W3
validator link (http://segment7.net/main.html) and click on the link with
button1, then with button2. This should be fixed regardless of what happens to
the back button history. Should a separate bug be filed, or does another bug
already exist for this one?
that problem is probably related to GetURI. It's from this month and is in 
bugzilla.
MSIE has a nice feature that new windows have exactly the same page/ back button
history, etc as new windows. If you are even logged into a server, the new
window will be too. I would definately like to see this feature in Mozilla.
Shouldn't the bug be Spawned windows should be on same page as former window and
contain same back/forward/go button info?
Brian: we know, that's why someone filed this bug.  Personally, I want my new 
windows to be NEW.  What everyone here wants is a clone window feature.

I propose that if we do force this junk onto the average user that the text 
"New Window" be replaced with "Clone Window" to accurately describe what we are 
doing.  Yes that means File>&New window will have to do what I want, but ctrl-n 
could mean {clone}navigator window (it shouldn't, but you could stretch the 
meaning).
That sounds good. Either give them the choice of File>Clone Window as you said, 
or give them the choice of what New Window means in preferences. I think the 
former would be better as it would give them the choice each time they spawn a 
new window. Sometimes - I want a clone window, but other times I just don't 
care. If the page I am at is really large, then I would probably want it to 
spawn to my home page.
Depends on: 36269
I'll reiterate here that "New Window" and "Open Link In New Window" are
different things.
s/New Window/Clone Window/g;+Context.
"Open Link In New Window"=>"Open Link in Cloned Window"

A new window isn't new if it is tainted.  

German: you never answered the question, any comments?
jglick?
Cloned windows should get data from cache, not on-line, like IE.
Decreases loading time.

Open link in new window is different than a new cloned window. Open link in new 
window means that you open the link you right click on in a new window, while 
opening a cloned window means opening a window exactly identical to the current 
one, with the same location, links, form data, etc. They are two different 
animals - and shouldn't be mixed up: ie - there would be open link in cloned 
window. What would be the point? Then you would still not be on the current 
page. The whole point of the open cloned window would be, for instance, if I am 
navigating my registration information, or an online quiz for my school, and I 
want to go back and look at a previous quiz (via my back button) without 
changing the contents of the current window (and risking losing my quiz). 
Therefore, I clone the window and click back - boom I went to the previous page 
without losing my quiz. If I had clicked back and then clicked a link, I would 
have lost my quiz and would have lost all my information. Of course, online 
quizzes are not the only use for this. Currently, when I know I am going to be 
in a situation like that, I use MSIE.

Therefore, the new netscape should have an extra option in the File Menu - 
"File>Clone Window". Wouldn't it be as simple as making a copy of the Window 
Class or whatever?
Maybe i wasn't clear.
lets tyr to parse a few strings
a) "Open link in New Window"
Create a "New Window"
browse to the selected link in that window.
b) "New Window"
make a new window.
c) "Clone Window"
make a window that has all of the attributes from the old window.
d) "Open link in Cloned Window"
Clone this Window
browse to the selected link in that window.
I guess open link in cloned window could come in handy, but why not just clone 
the window, then click on the link in the cloned window? I guess it might save a 
step, as long as it doesn't make the right click menu too large.
Timeless, I understand what you're trying to say, but "new window" means new
window.  Nothing more.  It says nothing about that window, including whether it
has initial or cloned content.

Brian, open link in new window saves a lot of time since you can middle-click on
links in quick succession.  Opening new windows manually would take a lot longer
due to window reload, user reorientation, etc.
"Open link in cloned window is different than "Open link in new window" for the 
following reason:

If you click open link in new window - it will make a window with no forward or 
back history and then just open the document. 

If you click open link in cloned window, it will copy the forward and back 
history. Actually, I think the forward history would be erased but the back 
history would stay in tact, along with any info you entered in on forms in 
those pages. Timeless defined these correctly.

Cloned window means identical - ie just as if you were still in the same window 
(history, etc). Link in cloned window means clone the window and then travel to 
the link on that new window. Yes, open link in cloned window would save time, 
but would take up space on the right click menu. Therefore, it might be better 
to just let people clone the window and then click the link from that cloned 
window. They would still have the option of opening the link in a new window.
Yes, open link in new window doesn't say whether it is cloned or not, but if 
people saw an option to clone the window, they would assume it is a fresh 
window. 

Alternatively, people could have the choices:

a) "Open link in Empty/Fresh Window"
Create a "New Window"
browse to the selected link in that window.
b) "Empty/Fresh Window"
make a new window.
c) "New Window"
make a window that has all of the attributes from the old window.
d) "Open link in New Window"
Clone this Window
browse to the selected link in that window.
IMHO browser should only include options "New Window" and "Open Link in New
Window" in context sensitive menu and an option in preferences whether "New
Window" means "Open empty window without history" or "Clone current window
including history and form values". This is because those who want to open link
in a new window without history are (usually) the same ones who want new windows
to open as empty. Perhaps some "Advanced" theme could include both options in
context menu though. And clone should really clone the window - that is, no
online access during operation.

Mozilla already has ctrl+1 for "open a new browser window to my homepage", so 
IMO the ctrl+n shortcut could be stolen for "clone window" (which is what IE 
does with ctrl+n).  This doesn't solve the "open link in new window" vs. "open 
link in cloned window" problem, though.
IE also has shift+left mouse button as shortcut for "open link in new window". 
How about if we copy that (at least in windows version) and add ctrl+left mouse 
button for "open link in cloned window". I would prefer same mappings in *nix.

attn: MPT [lookup bug number?]
ctrl-1's behavior is already defined as a way to alternate among open navigator 
windows (yes it will make one new window, but its main focus was window 
switching).

Therefor until that behavior is defined I *highly* object to any claims that 
ctrl-1 is a valid alternative.  I want ctrl-n to be a NEW CLEAN window. </rant>
Yeah, I'm just a Bugzilla gofer, I am. Feh.
* modifier+click to open in a new window is bug 12056. As specced, all modifier
  keys are taken for things which are considerably more useful than
  distinguishing between cloned windows and fresh windows. Sorry.
* Whether or not the component bar icons (and by extension, I guess, the items in
  the Tasks menu) should always open new windows, or just switch between existing
  windows, is bug 20306.

And by the way, if you think ordinary users will understand the difference 
between a `new window' and a `cloned window', I would respectfully suggest that 
you're dreaming.

How about we add the option to Clone Window and New Window and then give them 
the ability in preferences to remove either of those from their menu if they 
don't want them instead of fighting over which one to include. If menus are 
customizable, then it would be really easy to remove the one you don't want.  In 
short, lets include both options instead of fighting over which one to include. 

BTW - is it possible to edit the menubar (add or remove items) no matter what 
skin you have loaded? 

In preferences, Matthew, it can explain what each of those mean.

I don't like the option to choose what new window does in preferences, because 
sometimes I want a new window, while sometimes I want a cloned menu. As clone 
window will probably be slower, people might want to be able to choose. 
*** Bug 61719 has been marked as a duplicate of this bug. ***
stop fussing around; this is obviously an important issue to many people. Please
implement this feature soon (0.6 or 0.8) and give the people what they (and I
too BTW) want.
A little harsh but well said.
I see the utility of keeping the parent's history in the new window, but I am 
another that likes to keep my new windows "rooted" at the document I open them 
at.  When I'm cruising Slashdot and see a link to site XYZ in a story, I will 
open XYZ in a new window because I want to look around XYZ.  When I'm done at 
XYZ I'll go back to the original window.  That's the way I work, because that's 
the way I think.  
That said, I agree this needs to be a pref setting, or an additional bit of 
functionality.  I think timeless has it exactly right - "Open Link in New 
Window" and "Open Link in Cloned Window".  Paralleling this you can have Ctrl-N 
(a new window, just as it works now) and Shift-Ctrl-N (a cloned window), or 
whatever.  This is much simpler than marking an item in the Go menu, or trying 
to beep the user when backing up past his "original" location in the window.  
Just choose the behavior you want, and things work "normally" from there for 
everybody.
I pictured an option in the Preferences dialog for a app-wide selection on how
new windows are treated. I don't see many people expecting both "new" and
"cloaned" windows mid-browseing session. One option causes new windows to be
rooted to the link where they are opened (current implementation). The 2nd
option would allow new windows to be cloans of their parent windows complete
with back-forward buttons (like IE). This preference would influence both the
File -> New Navigator Window (Ctrl-N) as well as the right click -> Open Link in
New Window.

Adding a "Open Cloaned Window" both in the right click menu and the File menu
just seems too kludgy to me as well as potentially confusing to non-power users.
trivial points:
a) meta+shift+n=composer
b) I'm rewriting the context menu. In my rewrite there is space for the extra 
cloned menuitem. I will play w/ it.

wrt the file Menu, we could easily add File>New>Clone Window. imo This does not 
seriously increase the complexity of the menu structure.
I for one would like both new window and cloned window functionality at once.

Like Tim Larson, mostly I want to explore a new site from a window rooted at 
the document with which it was opened.  Sometimes, however I need to explore in 
a way that will each window to go back up my history and follow new branches.  
This can be really useful for slow loading sites that require a form submit to 
get to the top level page you're interested in.  Sites like that are annoying 
to browse with only one window open at a time.  I haven't found a simple way to 
open multiple instances of the top-level document without going through the 
form submit procedure again.  Cloning a la MSIE is the obvious answer.

Casey's suggestion of an app-wide pref is fine, but I think it should enable or 
disable the additional option of cloning, not toggle between cloning and non-
cloning.  This way the default setup can still hide the potentially confusing 
options, but the end user has the most choice.
Exactly. In summary of what you said: To save what is in in the cgi forms while
checking something on a previous page/s link really quickly. I really need this
- especially working on bugzilla ;-)
BTW chris- people that implement things are really busy and can't always do what
you need right away. I think it is unfair to timeless and others to do say "It
should be done now", they do the best they can - I came to this alightnement
from a scolding I recieved.
 
> b) I'm rewriting the context menu. In my rewrite there is space for the extra 
> cloned menuitem. I will play w/ it.

Rewriting how?  Alec, ben, jag and I already have some plans for this, so 
please talk to us before we duplicate effort.

> wrt the file Menu, we could easily add File>New>Clone Window. imo This does 
> not seriously increase the complexity of the menu structure.

"New Clone Window" means nothing to me, and I suspect that's the case for many 
other people as well.
Brian/NeTdEmOn:  Ooops - I didn't mean to be ambiguous.  I would like to be able 
to do both of the following things: open new windows with blank history and open 
new windows with the current window's history.

I didn't mean to sound like I want it right away.

Actually, the scenario you describe is not exactly what I was thinking of, but 
another good reason to have cloning.  My example is related to some online 
discussion groups I follow on sparklist.com.  You have to click a form submit 
button to get the list of messages posted, so I can't just Open New Window from 
the login page to get several copies of the main discussion page.  Since the 
site is so slow I really want multiple windows so I can load messages in one 
thread while reading another.  The only way I can see to get multiple main pages 
in this situation without reloginning in is to open a new cloned window (what I 
do when using MSIE) or opening a link to a message in a new cloned window.
> "New Clone Window" means nothing to me, and I suspect that's the case for many 
> other people as well.

How about one of these:
File > New > Window like this one
File > New > Window on this page

If you like, the current "New window" function could be one of:
File > New > Empty window
File > New > Window to my homepage

For opening links, we should have (at least) all of the following:
Open link in this window (history preservation doesn't apply)
Open link in new window
Open link in new window, preserving history
Open link in (the TARGET of the <a> tag, IF not one of the above - might be a
named frame or a named existing window - history preservation doesn't apply)

(I've written this before, but I can't remember whether it was in bugzilla or a
newsgroup, or which bug it referred to, and the "preserving history" is new. The
point is that it should be possible to open in the same window even if the link
specifies otherwise, but that's another bug)

That's only one new item in the "New" submenu, and one new item in the context
menu (where, with my proposed scheme, there could be three items anyway).
s/Clone/Duplicate/

File>New>Duplicate Window

'File>New>Blank Navigator' sounds good.
I think 'File>New>Window at homepage' is rather useless. either the user likes 
to use their home page, so 'File>New>Window' should go there, or they don't. If 
they don't like to go home, then they can spend the extra few seconds to 
Go>Home or click the home button.

wrt overiding target. You should be able to drag the url onto its frame and 
have the url load into that frame.  However if you don't use a mouse this is 
_hard_.

<context>Open Link Here

<context[image]>Show image here

I think i like that phrase. If people prefer "Open Link in place" and "Show 
image in place" please speak up now.
I like the extended context menu idea and "Here" seems to work better than 'in
place' for me (but have not user tested it). Can we have somebody from
pubs/information design comment on it? Verah?

Talking about the defaults though, I would rather not duplicate everything as
mtp suggested. I would rather honor the browser startup prefs. I saw user being
very annoyed by IE duplicating the current URL from the referrer window,
especially when they were on a modem and it took a while to bring up the page.

I agree with mpt's earlier statement that the back button should alway have the
session history on per window basis,to give a clue that this is a new window. I
also believe that users who noticed the differences between the diff. types of
hsitory have this behavior engrained and use it as a navigation clue. I believe
the Go menu is not as loaded with meaning, but for consistency reasons I would
choose to implement it the same way as in 4.x. 
so it sounds like this is either a WONTFIX or we need to rephrase the summary of
what needs to be done here..
alecf, I don't believe WONTFIX is an appropriate resolution. There is someone 
who might be willing to do this in the future. Its just that right now that 
people are probably too busy. If no one wants it you can assign it to me - I 
might do it in the far future.
*** Bug 36269 has been marked as a duplicate of this bug. ***
Summary: [RFE]Spawned windows should inherit back button/go menu history. → [RFE]Spawned windows should inherit current page/back button/go menu history.
Why does this bug depend on a bug that has been marked a duplicate of this?
Someone forgot to clean up, is all :-)
No longer depends on: 36269
Blocks: 36269
nav triage team: not a beta stopper.
Keywords: nsbeta1-
German, Vera's gone.

We shouldn't confuse the majority of users by having new inexplicable menu 
items for this, just to placate some advanced users who like having `root 
pages' and are afraid of the Back button taking them too far. (We, uh, have a 
Forward button ...)

We already have radio buttons for what new windows should do -- When Navigator 
starts up, display:
( ) blank page
( ) home page
(*) last page visited

All that is wrong is that at the moment, `last page visited' inherits the page, 
but not the contents of the Go menu or anything else about the page (such as 
the scroll position). That is counterintuitive and should be fixed. The same 
applies to where a link opens in a new window, whether this was my choice or 
the author's -- I shouldn't be prevented from going Back just because I happen 
to be in a new window.
Mpt: Good observation. I think we should have one option for when the browser 
first loads, and one for when the browser is already loaded and one is opening 
a second window, third, etc.
--------------------------------------------
When Navigator starts up, display:
( ) blank page
(*) home page
( ) last page visited

When new windows are opened and Netscape is already open:
( ) blank page
( ) home page
(*) last page visited
--------------------------------------------

As normally I want the home page to load at startup, but never after that. When 
I want to go back to my homepage later, I usually just type in the url or click 
the home button.


I agree with boberb, except that "When new windows are opened and Netscape is 
already open" should be "When a new Navigator window is opened from another 
Navigator window" and "last page visited" should be "current page".
I agree with Jesse, except I think that "When a new Navigator window is opened
from another Navigator window" should be "Lukewarm babies ripen in the sunlight
of the eternal dawn"

Erm, so if i open a new navigator window from messenger based on jesse's 
strings what happens?

Replace Netscape w/ Mozilla in NeTDeMoN - Brian Bober's comment and get mpt to 
sign off.
mpt you're right, the pref is already in there.
agree with the later comment that it should say "Current page" rather 
than "Last page visited".
However I am not in favor of making the prefs any more complex than they 
already are by splitting this one into 2 as suggested by netdemon. This is a 
space issue for that panel and a complexity issue for the majority of Netscape 
users.

Users need some way to choose whether new windows go to blank/homepape (like in 
ns 4.x) or clone the current page and maintain history (like in ie).  That can 
either be done with a pref or with extra menu items...

Some advantages of using a pref: 
- IE and Nav4 users can both continue using Ctrl+N and get the behavior they're 
used to.
- Possible to include "blank" without cluttering menus too much (users who are 
concerned with performance or bandwidth usage are likely to want new windows to 
go to about:blank).
- Would force "toolbars" (the scrolling listbox with checkboxes for toolbar 
buttons) in the main prefs panel for Navigator to be moved to a new panel, 
where there would be enough room to use it without scrolling.

Some advantages of adding extra menu items and keyboard shortcuts:
- Users can choose what they want each new window to do.
Alec Flett's suggestion is the best of all those I've seen in this bug so far.
Mass moving all Navigator bugs to the Nav team.
Assignee: radha → vishy
I think that this is one of the salient Huge Wins that IE has
over Mozilla.  I think that there should be a feature that 
implements what IE does when you say "New Window" in IE.  This
DOES NOT have to replace the current "new window" in Mozilla.
A prefs option to do so would be kewl but not necessary.
46 votes and counting for this one, guys!!  It CAN'T be that
hard.  (have to break out the source and hack it in myself...)
Y'all have good copy constructors on your windows, right?! :)

learn the codebase, dude. There are no copy constructors in XPCOM.
Feel free to submit a patch.
I've never looked, but I would assume that they use something a little more 
agressive than copy constructors
Alec, you missed the point gehlhaar made. This feature is clearly very important
to many users. The votes and CC list proves it beyond ANY doubt. Whatever
taskmanager/projectmanager at Netscape has been deciding to ignore this bug
since November 1999 should reconsider or be replaced. Sometimes the will of the
people must outweigh the will of the programming "elite" (and we ARE eternally
grateful for you efforts).
Ok, lets all calm down and be a little more constructive :) If there are no 
copy constructors and that is what is needed, then this bug should depend on a 
bug "Add copy constructors to whatever" . Peter, I don't think someone will be 
replaced because they have a different opinion than you, although I really 
would like to see this feature...
it's not a copy constructor issue, I think we were both just being flippant.
I'm not objecting to the importance of THIS bug, but in the grand scheme of
things, I have WAY more important stuff to work on, that's why this is Futured.
*** Bug 74191 has been marked as a duplicate of this bug. ***
*** Bug 83057 has been marked as a duplicate of this bug. ***
What can be more important than 54 votes, 6 dupes and 24 CC's? Please reconsider
giving this bug some attention - especially sine the latest builds (2001-05-29)
are very stable.

At least please add the *keywords*: nsCatFood, mostfreq and mozilla0.9.2

Actually, bug 36269 is even more what we want. I suggest everyone on this CC
list also CC themselves to that bug and also vote for it (bug 36269 - [RFE] New
window open should display current page not homepage).
Acutally, I want neither. I'm plenty happy with the current behavior and hate 
the fact that IE always wants to reload the page I'm viewing.  But I guess I'm 
not finicky enough (hence the CatFood keyword).  6 dupes isn't really enough 
for mostfreq and I think that keyword may be obsolete (see 
http://bugzilla.mozilla.org/duplicates.cgi).
Keywords: nsCatFood
This bug may have only 6 dupes, but there currently *only five other open bugs* 
in the entire Bugzilla database with more votes then this one. Clearly, a lot of 
people want this.

Getting the new window to display the home page is easy; just click on "home". 
But getting the new window to inheret history is currently impossible. Whether 
or not this is the default behavior, it should at least be made possible.
In weighting the "irritation factor" of a bug, votes should be considered
instead of duplicates in the instance where there are more votes than
duplicates. To do otherwise is to encourage interested persons to file
duplicates instead of voting for bugs.

How about making it a simple Prefs option:

  New Window Displays:
    [ ] Home Page
    [ ] Current page without full history
    [ ] Current page with full history

(maybe worded better for non-technical types).  This
would satisfy everyone, including those pushing for
bug 36269.
Keywords: nsCatFood → nsCatFood-
 _Programmers pay attention to:________________________________________
| [ ] votes                                                            |
| [ ] duplicates                                                       |
| [ ] the mostfreq keyword                                             |
| [ ] whiny comments about votes, duplicates, or the mostfreq keyword  |
| [ ] whiny comments about how great feature {x} is in another browser |
| [ ] stupid nsCatFood nominations                                     |
| [/] patches                                                          |
+----------------------------------------------------------------------+

It's quite clear what this bug is asking for, no further clarification is
necessary, the bug isn't assigned to anyone who is going to implement it, and
Santa Claus isn't going to do it. So if you don't have a patch to implement the
feature, please shut up and stop spamming this bug with useless comments. Thankyou.
Sorry, i have many talents and skills, but writing patches isn't one of them.
Consider it a special favour to you all that i'm not even attempting to write
such patches. My contribution to Mozilla is thus necessarily limited to
reporting bugs, testing, and designing test cases, so that's what i do. It's
rather insulting to tell non-coders that their input isn't appreciated. (And
what else does "shut up" mean?) If no attention is given to dupe counts,
mostfreq keywords, and votes, then why have such features been made available to
us in the first place and why shouldn't we expect them to be given due
consideration?

You who write the code and fix the bugs are the objects of our eternal devotion.
We only ask that you give us humble testers and reporters a little respect in
return.
I believe votes and such are definitely considered by various entities, both
individual but mainly corporate, that might churn out code.

But complaining ad nauseam about how important this bug is will do nothing
beyond what the votes did other than fill up people's email boxes and annoy
them.

It is clear at this point that no entities are willing to work on this yet -
hence someone stepping up and coding it is the only way it will get done.  So I
suggest that people stop banging their head against the brick wall just because
they don't have a sledgehammer.
No longer blocks: 36269
Depends on: 36269
*** Bug 93387 has been marked as a duplicate of this bug. ***
May I suggest a compromise? First, let me explain the problem. Currently, new
Mozilla windows created by either Ctrl-N or "Open in New Window" do exactly the
same thing. They open the home page without any back/forward history. Keeping
identical functionality between these two commands would be useful for the sake
of consistency. 

This bug report wants two changes. First, copy the back/forward history of the
parent window to the child window. Second, start the child window at the same
URI of the parent window. 

Copying the back/forward history to child windows would be helpful to everyone
who ever opens new browser windows (most experienced users). The memory and
performance cost of doing so would be minimal. Anyone intelligent enough to
handle opening new windows can handle the back/forward history of the parent
window in the child window.

The second suggestion is more problematic. Many times, starting the child window
in the same URI as the parent is very helpful. This is particularly the case
when you want to use the child to surf additional pages on the same site the
parent is in. Other times, however, this would be very bad. For example, if the
parent window is currently on a huge html page, or a page that was only created
as the result of a lengthy CGI query, the child window might be effectively
useless for a long time until the page reloads. This frequently happens to me I
use IE. Expecting the page to not reload in the child window is asking for too
much. I don't know if it's even technically possible for CGI pages. 

Finally, many users have home pages that are especially useful launch sites for
all their web surfing needs. For example, many experienced web surfers maintain
their own personal home pages filled with links to sites they use often, for
example. Thus, starting a child window on the home page makes sense.

So what's the compromise? Simple. First, start all child windows at the home
page URI, as specified in preferences. Second, copy the back/forward history of
the parent window to the child window. Third, insert the current URI of the
parent window as the most recent entry under the "back" history of the child
window. I call this proposal, "duplicate history, new window." 

If "duplicate history, new window" becomes the standard, and a child window
needs to be on the same URI as the parent for some reason, that can be achieved
by simply clicking on the back icon.

Experienced users will very quickly see what is happening. At very little cost
in resoures, they would have a more convenient experience. Novice users who have
gained some experience and are trying "open in new window" or Ctrl-N for the
first time will not have any trouble adjusting. 

Did I miss something? My apologies to the appropriate parties if this suggestion
was redundant or repetitive.

andrew's compromise has many flaws.

0. The outline of the current behavior isn't correct ... eg, It's possible to 
set mozila to load a blank page instead of the homepage 

1. Copying the back/forward history to child windows would be helpful to 
everyone who ever opens new browser windows (most experienced users).
!WRONG

2. The memory and performance cost of doing so would be minimal.
!WRONG
3. Anyone intelligent enough to handle opening new windows can handle the 
back/forward history of the parent window in the child window.
This assumes that anyone would *want* this behavior. which is !WRONG

> Did I miss something?
yes :-(
> This assumes that anyone would *want* this behavior.  which is !WRONG

Since this bug has 64 votes, it's clear that *many* people want this behavior.
If this feature weren't used by anyone, how did all of us voters come to
discover that the feature was missing in Mozilla? Microsoft must have also
perceived that somebody wanted this behavior when they designed IE. Since the
feature doesn't "come for free", it must have been a specific design goal.

Could we please refrain from reopening the issue of the validity of this bug? I
think that it's already clear that some people want this feature, while others
don't. The relative merits of the feature have already been hashed out ad
adnauseum in earlier posts, and we have been asked not to generate more useless
noise on this topic.
I think Andrew's compromise would be an ideal solution. I really like how IE
copies history, and think Moz should default to that as well.

As far as loading the current page in new windows (and tabs now, too), at first
I was for it, but then remembered (as some people pointed out) how it was very
annoying on dynamic pages, or large pages that take long to load. Adding it to
the end of history accessible via Back is an awesome idea. It's there when you
need it, and doesn't have to load when, more often, you don't.

Even if it's not perfect, those are much nicer defaults. If there're still users
who want something else, we can add prefs down the road. But getting the
defaults closer to what Andrew suggested by 1.0 can only help us gain users and
get good reviews for the big release.
Jeremy: Wouldn't the page load most of its information/images from cache into
the new window? The dynamic part seems would be very small. Therefore loading
the current page in new window might be the better "default".
What page to open in new windows is handled by Bug 36269 
and others, this bug should be restricted to just the history.

This bug addresses a frequent question I have to answer for 
various people (family members, patrons at the library where 
I work, staff at the library where I work, and generally 
anyone who isn't a geek):

Clueless:  "How come I can't go back?"  
Me:        [Looks at screen]  "If the Back button is greyed out,
           it means there is nowhere back to go.  You're already
           looking at the very first page the window displayed."
Clueless:  "No I'm not.  I was looking at [something stupid]
           and I clicked [something dumb] and it sent me here."
Me:        "Maybe something opened a new window."
Clueless:  [Clicks back button]  "I want to go back to the
           other one."

It took me a long time to realise it, but most end users are 
completely unaware that Windows is capable of having more
than one window open at a time.  And if you try to explain it
to them, they will argue with you.  If you try to demonstrate
it by resizing windows so they overlap, the user will become
confused or angry and walk away.  


We have been talking about this for over a year and still haven't come up to any
solution. It is one of only about 10 bugs that have this many or more votes!!!

I like Andrew's compromise.. its very thoughtful... but heheh its not practical
imho. I feel instead of making both parties happy it will make one semi-happy
and one totally angry as the back history has a rogue member in it.

What we need is someone who is willing to take this under their wings (not me -
please don't even ask :) - If someone implements it - it will probably be added
because of the number of votes on this bug. So this is a chance for someone to
make a real impact. I mean a HUGE impact.

Please correct me if I'm wrong... but what we need is:

A) Code to implement the copying of a window.
1) HTML data
2) Forward history
3) Back history
4) Javascript/images/etc...
5) Make sure popup windows for ads etc don't do this or it would slow things
down. (Maybe later)

C) Test its performance and fine-tune it. Copy memory in bulk, etc.


2+3 are probably best done every time in order not to complicate things.

Bug 18808 should only have to do with how to trigger it because otherwise it is
way too broad. 

Therefore... I am opening a new bug Called "Implement the code to copy a window"
and copying this text in. This code will have nothing to do with the
implementation of the UI for the bug but only have to do with the actual copying
of the window. It can be tested using javascript or whatever. i.e. :
copywindow(); in the URL bar.

Questions:
Would it be best if it copied the page as-is including pages recieved from CGI
without re-sending the CGI? Therefore data entered into forms would be copied
along with data recieved so the user wouldn't have to wait... Or would this
cause a mess?





The new bug is bug 110535
Depends on: 110535
Notice: This should also work on tabbed browsing.
reassign to Navigator manager
Assignee: vishy → trudelle
Changing from future to wontfix as suggested by Brian "NeTDeMoN" Bober
Status: NEW → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WONTFIX
Peter: What I said was that if you mark bug 110535 invalid then this should be
marked invalid too, although I do not agree with this being marked invalid. Your
reasons for marking both bugs invalid was stated in bug 110535 as follows:

We are trying to make windows open faster and be easier to use, not slower and
more complicated.  wontfix.

This bug would only slow down the opening of windows if the user wanted the
history and data to be copied. As that is not always the case it would not
always slow down window opening. As for not implementing this because it would
slow down window opening when a user wanted to use this feature, we have no
right to tell people they can only open windows in the way that's fastest. This
bug has 66 votes and as such it is obviously a highly requested feature and to
just brush it off because of performance issues that won't exist if this bug is
implemented correctly is not right.

Windows that are opened for popups, etc don't need to copy the history. Its only
main browser windows and only when the user wants it. I think the best solution
is just to add another option to the file menu called "Duplicate Window" along
with another member of the right click on link context menu that says "Open in
duplicate window" and forget about prefs, etc. 

That way, people will have to specify when they want a new window to duplicate a
window and the default will be a blank window. I think after some time people
will get used to picking one or the other based on what they want. As for speed,
the speed will only depend on which option they choose and if they choose the
first option then it should be just as fast as if the second option wasn't there.

Another possibility would be to put Duplicate Window under New - as in 

New Navigator Window
New > Duplicate Window
      Message
      etc.

or 

Duplicate Window
New > Navigator Window
      Message
      etc.

depending on the pref chosen. (The first would be default).

But either way, as I said before, implementing this feature should not slow down
the basic opening of a window it should only allow a second option for how the
window is opened that is slightly slower and only used when the user wants it.

As for complexity, I don't believe implementing this feature will add
significant complexity for the end-user. It can be configured in prefs and even
made so it doesn't appear unless the user requests it. As for complexity for
opening new windows, it should add code but in terms of speed it shouldn't make
a difference if the user wants to open a window the normal way. If the user
chooses to open it the normal way the code listed in bug 110535 shouldn't be
used at all.
Peter, to me, this is the most sorely needed feature in Mozilla - until such
time as it appears Mozilla will be a second rate browser IMO.  I would trade
some new window performance for this anyday, because it would dramatically
improve MY performance, save me much time and make my life easier.

There are 66 votes on this bug, putting it in the top ten.  This means many
people want this feature.  You have not provided any evidence to back up your
assertion this would significantly affect new window performance, enough to
justify not including it.

If you wish to place performance reservations on this feature, you can certainly
do so, but only once an implementation has appeared that we can judge it
against.  Marking a bug as WONTFIX because you don't see the point in a feature
is not the way this project works, and it has never been accepted as valid in
the past.  If you don't like it, please reopen it and reassign it to nobody.
Reopening. This is still a valid feature request (one of the top 5). Future or
reassign it if you aren't going to implement it.

A pref would certainly address any perf inpact, but if copying 10 URLs and their
<title>s from history is causing that much of an impact, something is terribly
wrong.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: [RFE]Spawned windows should inherit current page/back button/go menu history. → [RFE] New windows/tabs should inherit current page, back button/go menu history
-> nobody
Assignee: trudelle → nobody
Status: REOPENED → NEW
Keywords: nsCatFood-
Depends on: 112372
There are two new bugs that I made to branch off of this one. 

The first one, bug 110535 should be for talking about the code necessary to
implement this and the specifics of how it will be implemented including what is
going to be copied, the history layout of the new window, and performance. 

Bug 112372 should be to talk about how a window duplication should be activated
- i.e. what should be added to the UI and when new windows should be created in
this way.
(whenever/however this is implemented, don't forget tabbed browsing)

-matt
Just removing myself from the CC list
*** Bug 129570 has been marked as a duplicate of this bug. ***
*** Bug 142596 has been marked as a duplicate of this bug. ***
*** Bug 145871 has been marked as a duplicate of this bug. ***
I think it would be good if you could toggle picture and have diffent settings 
between tabs and windows.
*** Bug 156105 has been marked as a duplicate of this bug. ***
*** Bug 157046 has been marked as a duplicate of this bug. ***
*** Bug 157874 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
*** Bug 168045 has been marked as a duplicate of this bug. ***
*** Bug 170113 has been marked as a duplicate of this bug. ***
Summary: [RFE] New windows/tabs should inherit current page, back button/go menu history → New windows/tabs should inherit current page, back button/go menu history
*** Bug 175499 has been marked as a duplicate of this bug. ***
I used to be very much in favour of implementing this, but now I think it is a
bad idea. Here's why:

1) Mozilla now has the ability to open new pages in tabs. Thus it is not so much
of an issue to switch back to your original tab, and go back through history
from there.

2) Now that more and more websites seem to think it's a good idea to open links
in new windows, it is actually quite useful *not* to have a history for the new
window. Frequently I will go to click on the back button and notice that it is
disabled. This alerts me to the fact that I am in a new window, and should just
close it to go back. [It was only in the last few days when I was forced to use
IE at work that I became painfully aware of this. In IE, there is *no*
indication that you are now in a new window, if you have the taskbar on
autohide. At the end of a session you can have a dozen or so windows open
without even realizing it, which is very wasteful of system resources.]

If this is ever implemented, please make a pref to switch it off.
*** Bug 181201 has been marked as a duplicate of this bug. ***
It seems that alot of people like and use this feature, and some dont. The 
bottom line is, alot of IE users who migrate to mozilla have grown up on 
browsing using it, and there are many occasions where it is very useful. Indeed 
a few of my colleagues will not leave IE because they find that so central to 
how they use the browser.

For mozilla, things get more interesting because it could go for both CTRL-N 
(window) and CTRL-T (tabs). Why can't we keep both groups happy; offer it as a 
checkbox preference under tabbed browsing for CTRL-T (or use CTRL-SHIFT-T), and 
offer the feature as an entirely new keystroke for new windows, say ALT-D for 
duplicate. That way people can work in the present, Navigator way, or in the IE 
way. Surely no-one is offended?

Often you want to "freeze" where you are and go off on some link journey; a 
duplicate window with history allows you to go off to new links easily, and 
also allows you to go back prior to your current place - with the peace of mind 
of knowing your current position and history is safe.
gabriel: Can't we just turn it off for popup windows?
I thought what I wrote was ambigious, so I'll clarify.

What if we made it so that by default opening a link in a new window didn't have
the back button history. OTOH, using File > New could along with right clicking,
and choosing "Open in New Window". Therefore, the history would only be copied
if you initiated the new window.
I very strongly want to initiate new windows myself without inheriting the 
history. This is doubly true with tabbed browsing -- I tend to work in tabs 
mostly, but when I do open a new window, I want it to be a *new window*, not 
some weird clone of the existing one.
There seems to be two camps here: those resolutely opposed to this feature, and
those who are adamant that they need it, and not much in between.  This is
obviously a popular item, so why can't it be implemented with an option to
disable or enable it in the preferences?  That would make everybody happy and
relegate arguments to whether it should on or off by default in a fresh
installation.

Is there any work progressing on this enhancement?  Or, are all the developers
capable of making it happen in the camp opposed to the feature?  I see
"helpwanted" in the keywords field, which doesn't bode well.  I also see 99
votes, which must make it one of the most requested outstanding enhancement/bug.
*Sigh*  Again the solution would be THAT easy!

A: "I tend to work in tabs mostly, but when I do open a new window, I want it 
to be a *new window*, not some weird clone of the existing one."

B: "Nav used to automatically inherit the list of previous pages when you 
spawned a new window.  Then it disappeared for some reason, and it seems to 
have continued like this in Moz.  It is quite useful and would be really nice 
to have."

C: "There seems to be two camps here: those resolutely opposed to this feature, 
and those who are adamant that they need it, and not much in between.  This is
obviously a popular item..."

So what can we do here?

Solution: ADD the following command under the menu "File":

New > Duplicate

...

Along with that I would propose a renaming of the shortcuts for commands:

Bookmark This Page: Ctrl+D ---> Ctrl+B
File Bookmark: Ctrl+Shift+D ---> Ctrl+Shift+B

Manage Bookmarks: Ctrl+B ---> Ctrl+M

New > Message: Ctrl+M ---> Ctrl+C

   Actually, if you select "Message" a windows opens with the 
   name "Compose:..." (!) Hence this renaming is not that strange, 
   as it might look like, at first.

New > Duplicate   Ctrl+D

Actually, the following order would be nice:

New >

   Duplicate          Ctrl+D
   --------------------------
   Windows            Ctrl+N
   Tab                Ctrl+T
   --------------------------
   Message            Ctrl+C
   ...

etc. or something in that line, whatsoever.
(IE also just has: "File New > Windows" etc., but opens a _duplicate_/_clone_.)

The IDEA of the solution is just: Let the USER decide what he wants to open: a)
a FRESH Windows without any "history" (and the Home page as start page), or b) 
a DUBLICTE (or a clone) of the actual "session" (with the actual page as start 
page, the same "scrolling" position, etc.,and a full copy of the history of 
visited sides, in fact a clone).

BUT _both_ actions (possibilities) seem to make sense in certain circumstances. 

*I* (for example) _personally_ miss the possibility to open/start a "duplicate" 
(cloned) session very much.


P.S.
Opened: 1999-11-13 23:01 
Votes: 99

Assigned To:  nobody@mozilla.org  <-------- !!!

:-(((

Is THIS the way things are solved this days (concerning the Mozilla project)?!


"------- Additional Comment #18 From shuang@netscape.com 2000-05-05 16:58 ------
- 
[The] features are done in the way we think fits most of users' needs. You can 
keep the discuss open. However, due to other high priority features, I am 
setting this one to later milestone for future investigation if time permits." 

:-(

"------- Additional Comment #20 From Jeremy M. Dolan 2000-05-12 13:06 ------- 
IE5 has this feature and I must say i find it ***VERY*** handy. I use it daily, 
at least. I've been meaning to file an RFE on this for some time, never got 
around to it, and just noticed this open bug today. [...] This really is a 
severe usability enhancement, and for the (not unreasonably large) amount of 
work required, I think it should be done M19-M21ish."

Well... we have Mozilla 1.2 now...; and 1.3 will still NOT have that 
_feature_. :-(

"------- Additional Comment #22 From Matthew Tuck 2000-05-13 21:01 ------- 
I think there's no chance of Netscape doing this for N6.  Your best bet is to
try to get enough other people to vote on this to wake some people out of their
dream world."

Sure... We TRY... We TRY...

"--- Additional Comment #30 From Matthew `mpt' Thomas (gone) 2000-07-06 06:51 
I think 43 votes is quite enough :-), so reassigning this RFE from a UI person 
to a programming person."

Obviously not... :-(

------- Additional Comment #89 From Peter Lairo 2001-02-22 03:37 ------- 
[...] This feature is clearly very important
to many users. The votes and CC list proves it beyond ANY doubt. Whatever
taskmanager/projectmanager at Netscape has been deciding to ignore this bug
since November 1999 should reconsider or be replaced. Sometimes the will of the
people must outweigh the will of the programming "elite" (and we ARE eternally
grateful for you efforts).

Sure...

------- Additional Comment #94 From Peter Lairo 2001-05-30 02:48 ------- 
What can be more important than 54 votes, 6 dupes and 24 CC's? Please reconsider
giving this bug some attention [...]

Bruahhahahahah.... 

re: keybindings, see
http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
and either
   http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html
or
   http://www.mozilla.org/projects/ui/accessibility/mozkeyplan.html

If you take away my existing control-C (copy) and control-M (minimize) I'll be
very annoyed. Keyboard shortcut switching is something takes some very careful
consideration as the real estate is limited and lots of folks have some serious
muscle memory invested in existing shortcuts.

re: assigned to nobody
this is the convention when nobody has been assigned or volunteered to take a
task. If you think it shoulbe assigned to an engineer when nobody has time to do
it (and it hasn't been made a priority by those who are paying engineers to
code), then consider this:
    - the engineer would already be overbooked, so it wouldn't get done
    - a potential volunteer hacker would think they weren't needed here

re: the rest of it
I stopped reading... sorry.

-matt
"If you take away my existing control-C (copy)..."

Oh, sorry, yes. Ctrl+C should stay for "Copy", right. :-) Actually, I am not so
eager to have "Ctrl+C" for the Command "Message". :-)

Well, if we take (_for example_) "Ctrl+Shift+B" for "Manage Bookmarks", this
would mean that "Ctrl+M" would be free ... for "Message".

"...and control-M (minimize) I'll be very annoyed."

?!? What? But "Ctrl+M" currently IS NOT used for "minimize". (Mut for "Message".)

"re: assigned to nobody this is the convention when nobody has been assigned or
volunteered to take a task."

Thanx for that lucid explanation of the term. I didn't know that before.

"If you think it should be assigned to an engineer..."

Yes, that's EXACTLY what I think. (Someone should be responsible for it, yes.)

"...when nobody has time to do it"

Somebody SHOULD take the time to do it, imho.

"...and it hasn't been made a priority by those who are paying engineers to
code"

Well, probably it SHOULD be made a priority, by them. BUT that can ONLY happen
if a coding guy would ACKNOWLEDGE the problem to be a problem.

Seems as if 100 votes are not enough for that. :-(

"...then consider this: - the engineer would already be overbooked..."

Well, I have no doubt that they ARE "overbooked", certainly the have to their
own preferences... But on the other hand... A problem, is a problem is a
problem..., etc.
> ?!? What? But "Ctrl+M" currently IS NOT used for "minimize"


Not on your platform... but you didn't read these did you:

http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
and either
   http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html
or
   http://www.mozilla.org/projects/ui/accessibility/mozkeyplan.html

(no more from me on this)
Just to make my point clear.

I propose to add an additional command (under File) that in fact opens a "clone"
(window) or "duplicate" of the current session.  Something along this line (_for
example_):

File
   New >

      Duplicate          ...
      ---------------------------
      Window             Ctrl+N
      Tab                Ctrl+T
      --------------------------
      Message            Ctrl+M
      ...

So for the guys who don't like to use this feature, the don't have to care. But
the other's who really LOVE that feature (that actually means a *considerable*
improvement of productivity sometimes) will be quite happy. (Actually it would
be at the very position in the menu where you find this _functionality_ in MS's IE.)

Well... concerning the shortcuts, probably a) "Ctrl+Shift+N" would be
appropriate. (Clearly "Composer Page" will find a better shortcut than that!?)

Or ... b) as already proposed: Ctrl+D.

(But) Then "_B_ookmark this Page" probably should take "Ctrl+B", and "Manage
Bookmarks" probably should take "Ctrl+Shift+B" (Currently free?)

Or ... c) something else. :-)

Well, but that's only a secondary problem.
You don't think "New Duplicate" vs "New Window" vs "New Tab" is just going to
confuse end-users, especially ones who aren't software developers?  Even I'm
confused... is "New Duplicate" going to open a window or a tab?  Don't forget
KISS... options confuse people.

But anyway, what is the point of arguing of small matters such as UI details...
there isn't even an implementation to hook it up to.  For now, forget the UI and
how we're going to invoke it - lets have an implementation first.
Franz: Don't forget right click + "Open page in duplicate window". I discussed a
similiar thing to what you said in comment #114. The issue isn't really the
specifics of what we are going to do, but actually the fact that no developer
has time currently... Eventually things might change and due to the number of
votes, that might happen.

If someone who has sufficient coding experience with Mozilla wants to give this
a stab, I'm sure some "strong hackers" will give their time to at least point
you in the right directions by giving a list of what needs to be done on this
bug and providing files, etc you need to look at. I wouldn't try tackling this
as your first bugfix though.
"...forget the UI and how we're going to invoke it - lets have an implementation
first." 

Ok, that's only fair to give _function_ a preference. :-)

"But anyway, what is the point of arguing of small matters such as UI details...
there isn't even an implementation to hook it up to."

The point is that s o m e argued that they DONT WANT a duplicate windows (or
clone) when they "say" (select) _New window_. So my proposal only shows that
this actually is IN NOW WAY an "valid" argument against the proposed feature.
Since this _two_ possibilities can co-exist without any problems. In fact that
would be the _ideal_ solution. (IE for example don't have the possibility to
open a _new (fresh) window_ in this way!)

"You don't think "New Duplicate" vs "New Window" vs "New Tab" is just going to
confuse end-users, especially ones who aren't software developers?"

Actually I don't know... Clearly these things can be "discussed". Probably you
are right..., but I am convinced it can be resolved in a clean and simple way.

Well... Probably it's even worth an own command in Menu "File"?

Something like:

File

   New >
   ---------------------------
   Duplicate Navigator  Ctrl+D
   ---------------------------
   ...

etc.

Actually, it's a "big" thing. That's clear. In a certain sense it's a complete
clone of the "open session (windows)" - in fact even Tabs would have to be
copied/cloned!

Yes, I think this would probably avoid the (possible) confusion you mentioned.

Good point, Malcolm!

"Even I'm confused... is "New Duplicate" going to open a window or a tab?"

Ok, I got the point. Better now?

"Don't forget KISS..."

Of course not, it's one of my favorite mottos.

"Options confuse people." 

Yeah, but if CERTAIN options aren't there, people will miss them! (Trust me... ;-)
"Franz: Don't forget right click + "Open page in duplicate window"."

Well, I already thought about that... To be honest, I am not that eager to have
this option in the context menu (at least not "right now").

You certainly will agree: we cannot have _everything_ (that would make sense) in
the context menu.

Actually the feature of launching a cloned/duplicated navigator (window) is
missing. At least THIS feature should be available (but not necessarily in the
context menu...; certainly we can always add it later.)

"I discussed a similar thing to what you said in comment #114."

Ah!

"The issue isn't really the specifics of what we are going to do, but actually
the fact that no developer has time currently..."

Yes, I see.

What do you think about the proposal of a new command under "File", something
like: "Duplicate Navigator"? Probably it really should be THERE. Since it
actually means (is) a _complete_ copy (clone) of the Navigator and it's current
"state". No?

I always LOVED that feature in IE!  And didn't good old Netscape Navigator 4
have a comparable thing?!  (I really don't remember.)
Or another proposal...

File
   New >
          Navigator Clone
          ----------------
          Navigator Window    (Already there)
          Navigator Tab       (Already there)

And in the context Menu:

   Open Link in New Clone
   ------------------------
   Open Link in New Window    (Already there)
   Open Link in New Tab       (Already there)

---------

As you can see, the naming scheme would be consistent in this way.

---------

Note: We invented a new TERM here "Clone". Probably this is a good idea? I mean,
think about it...: this feature would NOT just open a "new window", in fact it
does MUCH MORE. It produces a (new) _clone_.

Why not INVENT new "things" from time to time?

And the _meaning_ of the term is actually quite clear these days, isn't it?!

---------

Well... just some thoughts.

"...forget the UI and how we're going to invoke it - lets have an 
implementation first."

I don't know who you are quoting... But this is definately the truth. The 
developers who put the most time into this project aren't really going to pay 
attention to this bug until this bug has reached the top of their "priority 
queue" ;-)

You can easily hook this feature up to some key, or mouse click, or anything 
else in the event system, or even better... just place some test entries under 
a new menu on the menu bar.

Once you have the window:
1) Cloning itself
2) Cloning itself and going to a new page

Then the developers and others will be much more likely to come in, look at 
the patches, make suggestiongs, etc.

When I hear someone say "I am willing to implement this and have the time and 
at least a little experience with Mozilla development", then I can look at the 
code, talk to strong hackers, and provide some info in this bug to get this 
person started... But as of yet, it appears to be a waste of time since no one 
seems to want to implement this. It seems like a good feature, but it looks 
like its a "Maybe next year" kind of thing.
hmmm.. instead u could have the bottom entry in the list of the back button
history display say "back to previous window"(if applicable).. Alls that this
would do is select the previous window(u could have it re-open it, if closed,
but maybe not)... This chain should aloow u to go back to the first window open
if u repeat... this way u could never get lost in knowing which windows have to
do with what (in what order)... also the one link in the back button isn't likly
to get users upset that don't wanting the entire list of the previous window's
back history in the next window's back history(whatevr u call it).. so i 'doubt
a  pref would be needed fo this...but u could...Let me know if this methode
would be prefered to most...
move TAB to new window

This may be a new feature request... but it's similar to this one.

I'd like to be able to right click on a tab, and have it be removed from the
nest, and put into a new window, (and a configuration option to close the tab or
not upon doing this)

(insert coments about one path of history being copied to new window)

I believe this post has few duplicates because people with clue are the people
who want the new window stuff.. (150 posts is a lot...)

I now have scroll wheel, tabbed browsing, easily configured menus, plug in
support, anti aliased fonts...  

This last feature will make it possible for me to completely ignore IE. (well
some win media plugins don't seem to work..)... and if this got font embeding my
friend would switch to it.

-AP

Move tab to new window (and may other features) are provided by the multizilla
(http://multizilla.mozdev.org) plugin.
My suggestions:
the wording "duplicate tab" might make more sense to typical users than "clone tab"
for tabbed browsing, a right click on the "new tab" icon could have a menu entry
for "duplicate tab".
also, unless it has been done already, since the idea of cloned windows/tabs is
not directly related to this bug, an new bug should be created for this topic.
im not going to create it until im sure it wont be a dupe.
*** Bug 196887 has been marked as a duplicate of this bug. ***
Hello, 

Quite frankly, I'm sick of loosing data.
I visit a lot of sites in a session, and I can't sort out the history tab in a 
reasonable amount of time

And... well I know that this causes DATA LOSS, though it is though extenuating 
circumstances... but it does majorly impact productivity.  just make it a 
freaking option, your platform won't be implemented if it's not usefull! Your 
trying to attract people to help AOL.  Leaving out no-brainer features like 
this (that can be turned off for those who like loosing data) is keeping you 
from acheaving your goal.

anyway, my change to critical and moz1.4b target... are an experiment.
I have no authority/knoledge to make this actually be in 1.4b.. but  this and 
font support are the last feauters keeping me form using Mozilla.
This bug needs attention though... and I will continue learning XPCOM and XUL 
etc so that someday I can actually contribute rather than just whine... 
-Aaron Peterson alpeterson@wsu.edu 509 332 7697

(actually saying normal rather than critical... even though data loss occurs)
(that didn't work... and I'm back here)
*** Bug 200611 has been marked as a duplicate of this bug. ***
If this feature (which, as has been mentioned, used to exist in Netscape
Navigator, but was taken away from us) and bug 70030, the ability to stop
animations with the "Stop" button (another longstanding and important feature
which was taken away), were fixed, I would finally be able to stop using
Internet Explorer (except on pages that have been authored by idiots to only
work properly with it).
I found a bookmarklet with the following code:
javascript:if(!document.referrer) alert(%22No referrer!%22); document.location =
document.referrer; void 0

I put this in my personal toolbar with the name '<' and I find it to be superior
to Mozilla's own 'back' button for the simple reason that it's a fine
work-around for fixing the 'back one page' portion of this 'bug'. ;)  Now I can
go 'back' from tabs and windows that I spawned while reading a page.

Hope that helps someone.  I'd LOVE to see this essentially become the default
behaviour of Mozilla's own 'back' button.
 


*** Bug 208171 has been marked as a duplicate of this bug. ***
I'm getting this behavior too on 1.5a (the current RC). For instance, if I enter
"www.slashdot.org" in the address area, and then enter "www.mozilla.org," the
back button is greyed out and the back option in the right-click context menu
(when I right click on the displayed page) is also greyed out.

This is a very annoying bug - to the point where I want to downgrade!

I'm running Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a)
Gecko/20030619 with Multizilla 1.4.0.3J and Google Toolbar / GoogleBox installed. 

--Pat / zippy@cs.brandeis.edu
The greyed out back button is a result of running Multizilla 1.4.0.3 with
Mozilla version 1.4b and later. The install page for Multizilla clearly states:

"Do NOT install MultiZilla v1.4.0.3(x) on Mozilla 1.4 but use our nightly, that
should work with Mozilla 1.4 (build 20030325 and up)"
( http://multizilla.mozdev.org/installation.html ) See the big bright red box at
the top.
I was disappointed that this problem hasn't been fixed in 1.4 and went looking
for the bug. Reading the prior comments, I'm dumbfounded that a fix for this bug
has been resisted for so long. To echo someone who commented before, this bug is
essentially the *only* thing I prefer about IE over Mozilla.

If the fix were implemented to behave exactly like recent versions of IE, I'd be
happy. If the absence of a "root", or origination point in the history of new
windows and tabs bothers people, why not simply highlight (tint them slightly
orange or something) the back/forward buttons when you are currently viewing
this tab or window's "origination page". Likewise with the back/forward button
history lists: color the origination page entry differently.
*** Bug 211589 has been marked as a duplicate of this bug. ***
*** Bug 213977 has been marked as a duplicate of this bug. ***
also, being able to re-arrange tabs would be nice (but then this is probably a
different bug already)

Use case (read as: why I still use IE):
I was composing a mail message in Yahoo Mail.  I wanted to copy a few things
from some other mail messages.  I opened a new window (with complete history),
pressed "back", and was right at my list of messages.  In Mozilla, I would have
had to wait for the home page to reload, type in "mail.yahoo.com" (or menu to
a bookmark), wait for that to load, click on "Inbox", etc.  What a pain.  One
would think that after four years on the list, and now 129 votes, and lots of
dups, SOMEONE would think this worthy of some investigation.  And no, I don't
have time to spend weeks learning the code base.  I encourage other members of
this CC: list to send in use cases.  Maybe I just need a paradigm shift?
Hello,

wrt comment #165 I'd like to point to Multizilla which solves most of these
problems. I was referred to it a while back and tried it, and left it installed.
Multizilla has the advantage of bringing you most of these things and some more,
but also (of course) has some downsides like (imho) requiring significantly more
CPU power, and an inferior focus handling. Anyway, the upsides outweigh these
problems for me.

You can find this and other add-ons to Mozilla at

  http://www.mozdev.org/

Maybe someone wants to make hints like these part of the standard documentation,
so people know where to turn instead of nagging the "wrong" people...
*** Bug 220790 has been marked as a duplicate of this bug. ***
Being able to clone a window complete with history is a really nifty feature in
browsers that hav it. So why leave it out? If some want to clone home instead,
just clone (1 click or key combo) then go to home (1 more click or key combo).
If that's too slow for purists, a settings option to tailor the browser to go
whichever way the user wants, in one step, will take care of things.

Purism is fine, but in the end, it's the usability, stupid.


From what I've seen with any discussion regarding the bug, its the back-end
that's the major issue. All the discussions of the front-end were moot because
once there is a back-end, a front-end can be figured out. Its not going to be an
easy bug to fix, but I wish someone would give this a stab :-)
Wow. There sure is a lot of controversy around this request!

I'll admit, I've wished for it before. I didn't know IE had it until reading
this (haven't used Windows in a while :-) but it sure would be nice.

However, I can also understand people's objections. I also remember many
occasions where I went up to click on the ghosted back button only to remember
"oh, yeah, that opened a new window...why don't I just close it and go back to
my 35-tab parent window?" So, in other words, I can see it both ways.

But anyway, I don't see why that should hold things up. I can see a fix that
should solve both problems:

1)Whatever we do, let's enable it as a pref. No need to ruffle anyone's feathers
over it, and since it's obviously a touchy subject, let's leave it off by default.

2)How about adding one special page to the history of the new window in between
the page displayed and the last page. One that said in big letters, "You have
reached the first page displayed in this [window|tab]. The history from this
point backward is thus the history of the parent [window|tab]. Please behave
accordingly."

This solution answers the nay-sayers' concerns by giving users (both the
un-html-initiated and the proficient users not paying attention (me)) a "glowing
neon sign" reminding them to go back to the parent window. With that warning I
can't really see any other arguments against this behavior.

At this point it is important to note that I am not in any way advovating
unifying the history amongst the windows. Any implementation of this should just
copy the history of the parent into the new window, allowing for forking.

So anyway, are there any reasons why this wouldn't be ideal?
> 2) How about adding one special page to the history of the 
> new window in between the page displayed and the last page. 
> One that said in big letters, "You have reached the first 
> page displayed in this [window|tab].  The history from this 
> point backward is thus the history of the parent [window|tab]. 
> Please behave accordingly."

How does that provide access to that history?

You are forgetting something.  (See below.)


> This solution answers the nay-sayers' concerns by giving users 
> (both the un-html-initiated and the proficient users not paying 
> attention (me)) a "glowing neon sign" reminding them to go back 
> to the parent window. With that warning I can't really see any 
> other arguments against this behavior.

You're not seeing very well.

1.  What good is a reminder to go back the parent window IF THE 
    PARENT WINDOW NO LONGER EXISTS (if the user has already 
    closed it)?  

2.  What good is a reminder to go back to the parent window if 
    in that parent window the user has already backed up in its 
    history and then gone somewhere else?  (The page from which 
    you opened the newer window is no longer in the parent windows 
    Back/Forward history.)

3.  What good is a reminder to go back to the parent window if 
    in that parent window the user has followed links after opening
    the other window?  The user would have to back up (who knows 
    how far) to get to the point in the Back/Forward history from 
    which the newer window was opened.  Then to "undisturb" the 
    parent window, he or should would have to go back Forward (again, 
    who knows how far).  And who knows if that would even work as the
    user traverses expired pages.
 
     
> So anyway, are there any reasons why this wouldn't be ideal?

In case somehow the answer is still not obvious:  YES!




wrt. comment #171:

Please take a look at what MultiZilla does. It lets
you re-open any closed windows which then come back
complete with history. It also lets you move tabs to
new windows and vice-versa, or clone windows complete
with history, and some more. You can find it
on multizilla.mozdev.org.

As far as I'm concerned, the MultiZilla package is
"good enough" for me.
Blocks: 164421
Flags: blocking1.7b?
Flags: blocking1.7b? → blocking1.7b-
*** Bug 234390 has been marked as a duplicate of this bug. ***
*** Bug 242125 has been marked as a duplicate of this bug. ***
*** Bug 250460 has been marked as a duplicate of this bug. ***
*** Bug 253778 has been marked as a duplicate of this bug. ***
There is no mention of Firefox (or Firebird) anywhere in this bug or comments
(that I can find), yet my Firefox bug 253778 was marked a duplicate. What is the
protocol for bugs that cross over between Mozilla Browser and Firefox? From the
FAQ etc I don't see this addressed.
Firefox bugs are marked duplicate of Browser bugs if, theoretically, the patch
that would fix the Browser bug would also fix the Firefox bug since the code
between the two doesn't change and is being shared. I guess this is one of those
instances, but, then again, I could be completely wrong.
Hao2lian is correct. This bug requires major back-end changes (to be done
properly and not be a total chrome/xpconnect hack), and the front-end fix wold
be a trivial menu change. I'll take this since IE-parity bugs are very important
to me.
Assignee: nobody → netdragon
Priority: P3 → P2
QA Contact: claudius → core.history.session
*** Bug 254666 has been marked as a duplicate of this bug. ***
*** Bug 261254 has been marked as a duplicate of this bug. ***
fyi: the Clone Window extension available at http://www.pikey.me.uk/mozilla/ is
lighter weight than multizilla and directly solves the issue this bug is tracking
*** Bug 281915 has been marked as a duplicate of this bug. ***
*** Bug 283411 has been marked as a duplicate of this bug. ***
*** Bug 284195 has been marked as a duplicate of this bug. ***
I find it hard to beleive, but in reading this very long, 5.5 year long bug that
nobody expressed my reason for NOT wanting this as the default behavior. One
thing that annoys me to no end is when sites use links that open up a new window
instead of allowing you to browse through. This is all too common. If you are
maximized (which I frequently am) and on a reasonably fast machine you don't
know they opened another window. After extended browsing I would find myself
faced with some large number of windows in the background all maximized. The way
I know when I am getting a new window is the back button goes gray. If you take
this away from me I will be quite vexed. Usually I solve this by either deciding
that I don't care about my history, and closing the old window, deciding I care
and leaving it open,  or deciding I care, and I already have a zillion windows
open so I copy the URL to the old window.

My number 2 reason for not wanting this to be the default behavior is that the
discussion has bled over to new tab behavior. At work I am FORCED to use lotus
notes, and even worse our IT department FORCES the preferred browser setting in
notes to IE. I of course have a not exactly authorized copy of firefox, that I
use for all my browsing anyway. My single most common set of keystrokes on
Firebird happens like this:

Somebody sends me a link in email. It is an external link and I usually don't
want to spread IE User Agent headers when I don't need to, so I highlight the
link, then do a quick

ctrl-C
alt-tab to firefox (often the last or 2nd to last program in alt tab)
ctrl-T
ctrl-V
Return.

At this point I can almost do it as fast or faster than the IE startup time. (on
a 3.4 Ghz box) If I have to muck around waiting for a page to load in the tab,
and clearing whatever URL is there... I'm going to wind up just browsing with IE
to save time. 

This is quite obviously very important to some, and quite undesireable to
others. My point is this: 

THAT IS WHAT EXTENSIONS ARE FOR. 

Rather than loading every feature in and fighting over space in the Ctrl key
world, this and other controversial bugs should be an extension (and it sounds
like it already is) If the needs are covered by an extension, and that can be
verified this should probaby become a wontfix.
This all seems to be beside the point. If the *option* is given to have new Tabs
and new Windows copy the state of the current screen, then you can keep your
desired behavior, and others can get their desired behavior.

Now, the extensions idea is interesting, but there is also a place for options
-- that's why there are there, and not everything is done with extensions. There
is also the issue that on every system I've worked with, the more extensions you
load, the more likely you are to have either security problems or simply bad
interactions between them. This may not be a problem with FireFox -- if you have
references that show why not, it'd be interesting to see them.
*** Bug 290013 has been marked as a duplicate of this bug. ***
*** Bug 290966 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
quote: THAT IS WHAT EXTENSIONS ARE FOR.

That is also why my win32 friends dont install firefox cause it does not work as
they want without adding extensions.  Win32 users are lazy and want something
that work out of the box and clearly don't want to have to check a forum /
extension site to find how to make it work.

A simple checkbox in the options would be great for this bug.

An extension provide the window cloning capabilities :
http://extensionroom.mozdev.org/more-info/clonewindow

It's 6KB, I don't why it cant be included in firefox. Another problem, is the
day this extension is no more maintained, users are screwed (until someone is
willing to update it). Having it in the main branch ensure proper updates.

http://extensionroom.mozdev.org/more-info/clonewindow
Blocks: 300763
No longer blocks: 300763
Depends on: 300763
Voting on this bug as it seems time to think about adding in the tab
functionality of Duplicate Tab, Tab X, Undo Close Tab, SingleWindow, and Focus
Last Selected Tab extensions. 

If the drag and drop of tabs should be included, these ones have an even greater
reason for inclusion in the core code. The size and "overhead" or "price" is
small, the code is done (in the extensions), and the gain is great. 

Thanks for doing this.
Flags: blocking1.9a1?
Flags: blocking-aviary2.0?
It would appear that commenting on this bug is a waste of time, but I'll do it
anyway...

Here's my desired behavior: New tabs/windows should have no history (they're
*new* after all). I don't care whether they open to blank or home as long as I
can set a pref to choose which. *Duplicating* a tab/window is something I never
want to do. I understand that some people do and think it's something best
implemented as an extension.

By contrast, links opened in new tabs/windows should inherit history from the
page that spawned them. Let me put it another way:

  >>> The history for the page I'm viewing should be a record of how I <<<
  >>> got there. Whether I got there via right-click or middle-click   <<<
  >>> *should not* matter.                                             <<<

*** Bug 318457 has been marked as a duplicate of this bug. ***
*** Bug 322466 has been marked as a duplicate of this bug. ***
There's a related Firefox bug that covers doing something along these lines that's a little saner and more in line with what we want to do here.  Clearing nominations.
Flags: blocking1.9a1?
Flags: blocking-aviary2?
What is the bug nr. of that bug, then? Thanks.

~Grauw
Twanno has a cross-browser extension that does this at http://twanno.mozdev.org/
*** Bug 322910 has been marked as a duplicate of this bug. ***
*** Bug 324787 has been marked as a duplicate of this bug. ***
[note: timed out first attempt to submit this. my appologies for any duplication.]
I would just like to add that...

I. I personally hope this feature is never added as it is one of the things that I and most other people I know consider annoying about IE.

II. If it is added I think, as do many before me apparently, that it should be optional. Regarding the choice of default option...

  A. Have it default to OFF so that long time Mozilla/Firefox/SeaMonkey users will not be suddenly surprised by a feature crossing over from a browser they chose not to use.

  B. To comfort those migrating from IE, offer to turn on the option during installation or profile creation, perhaps as part of an "IE-like" suite of non-default settings they can choose en mass. (Perhaps that deserves a bug of its own, if it doesn't exist already.)

As a general comment on adding IE-like features, I oppose adding such features solely "because they're in IE." The decision to add any such feature, and whether it should be activated by default or be left to be implemented as an extension, should be made on the merits of the feature itself without regard to its presence in any other browser, but with regard to precedent set within Moz/FF/SM. If any prospective new feature is deemed useful but the main argument for enabling it by default is that IE does it that way, it should then fall under the scheme described in II.B above.
John, if you could say *why* you don't want a complete history that would be more helpful IMO.

Also, since there are a ton of comments here, reading the previous 150 comments and saying "I agree with comment #number" might be even better.
(In reply to comment #201)

<snip>
 
> Also, since there are a ton of comments here, reading the previous 150 comments
> and saying "I agree with comment #number" might be even better.
 
Please don't encourage "Me too" responses; they merely clutter up bug reports.

*** Bug 358860 has been marked as a duplicate of this bug. ***
can this fix https://bugzilla.mozilla.org/attachment.cgi?id=250222 for bug 364972 be adapted to clone tabs at the very least? When we accidentally close a tab, the Undo Close Tab feature restores the closed tab with the tab's browsing history restored.
(In reply to comment #26)
> This is a very useful feature - Opera 3.60 has something similar, in its
> duplicate window command, and I use it frequently, particularly when I want to
> be able to explore another part of a site without having to go back up a few
> levels then open a new window from there.
> IE5's version of this feature has one major problem IMO - it duplicates the
> current window by default, i.e. new window opens up the current URL again.  If
> the current window is the 'order confirmed' page of an e-commerce site, there's
> a risk that your order could be re-submitted, which is hardly a good default
> behaviour (though I've not tried this, being too chicken...).
> I suggest NS6/Mozilla should implement this feature as a new 'duplicate/clone
> window' command - this will only be used by experts, and would open the new
> window on the current page, with full history.  The default New Window command
> should just open the current window on the configured home page, as with NS4,
> which will be less surprising to newbies.


actually I like that b/c a lot of the time I want the duplicate of the same window.  The order confirmed type page is NOT an issue.  I do it all the time.  Creating the new window is not like "hitting submit."

I still don't use Mozilla solely because of this one feature.  

A great example of the issue with Mozilla is expedia.com and a lot of pages use java where if I get a hotel list and want to view 2 hotels at once, I can't open a new window with the link in there b/c of java.  But with IE, I can just open a new window or 2 or 3 and then click on the links...
Whiteboard: DO NOT COMMENT, WE KNOW PEOPLE WANT THIS
Blocks: 189313
It seems, that the Firefox 3 beta4 had a "history" in the tab opened by ctrl+click on the "Go Back" button. But the FF3b5 has no this useful functionality again.
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
Depends on: 448546
When bug 225680 gets fixed Ctrl+Shift+N does exactly what is proposed here (and the same as Ctrl+N in IE).
Flags: wanted1.9.2?
Flags: blocking1.9.2?
Flags: wanted1.9.2?
Flags: wanted1.9.2-
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Regarding Klaas' comment #214, it would appear that's no longer true.  The bug 225680 enhancement is now in release versions of Firefox, but the "clone tab" functionality was apparently pulled out of the patch and filed as bug 455722.
Sorry for the bugspam, but just did some reading on related bugs and discovered that the clone tab functionality *is* there now -- there just isn't any easily discoverable way to trigger it yet.  However, in the meantime you can hold down Ctrl on Windows (& presumably UNIX?) or Option on Mac and drag a tab far enough to the left or right in the tab bar to get the placement indicator, and it'll be cloned, with history!  Whoo-hoo!  (If you don't like the "Always show the tab bar" option, as I don't, and this is a single-tab window, you'll first have to create a second dummy tab so there's a place to drag inside of.)

Since presumably manual duplication of tabs is going to be the preferred approach rather than the old behavior of cloning windows by default when opening new ones, this bug should probably be closed.
I did a search for Bugs with the most Votes and am down to this one.

This BR is over 10 years old and has over 170 votes.


It would seem to me that (almost?) all concerns could be addressed with the TM+ Extension. Goto the link below, click on "Add to Firefox" and your good, or goto the Author's Site for the 'Beta' which works very well.

If the "Reporter" and the "Assigned To" are satisfied can this be either closed or could we incorporate the TM+ features into Namoroka?

Tab Mix Plus
https://addons.mozilla.org/en-US/firefox/addon/1122
Trying but not to spam this bug, bug I've used TM+ for years and I've never seen an option to do that. Could you be more specific?
Trying not to spam this bug, but I've used TM+ for years and I've never seen an option to do that. Could you be more specific?
Blocks: cuts-tabs
No longer blocks: cuts-tabs
I'd like the very simple code from the "Duplicate Tab" extension to be added into the core code.

Duplicate Tab is at http://twanno.mozdev.org/
You can already duplicate a tab and his history with ctrl-dragging (ctrl changes a move into a copy), although that's not very clear (cursor doesn't change). It even works between windows
(In reply to comment #222)
> You can already duplicate a tab and his history with ctrl-dragging (ctrl
> changes a move into a copy), although that's not very clear (cursor doesn't
> change). It even works between windows

There is no way one would know that without reading it here. With a right click in the tab (as with Duplicate Tab), that is much MUCH more clear.
I don't think it has been mentioned here but there's an extension that does just this, hasn't been updated in a while, but works just flawlessly with Firefox 3.6 (haven't tried it with 4.0).

https://addons.mozilla.org/en-US/firefox/addon/1859/

All the known bugs are when opening a new tab from Chrome (which is the back/forth buttons and the location bar - with locationbar2 at least).
(In reply to comment #224)
> I don't think it has been mentioned here but there's an extension that does
> just this, hasn't been updated in a while, but works just flawlessly with
> Firefox 3.6 (haven't tried it with 4.0).

I'm a fan of this add-on, but since the author moved to Google Chrome, there is no one to update the add-on to make it work with Firefox 4.0 (it doesn't work even with extensions.checkCompatibility=false).

Though, on Russian forum there is already a fixed version of this, I'll try to release it on AMO or just drop a link to the tabhistory.mozdev.org when I'll upload it there.

But, in my opinion, such features shouldn't be done by extensions, it should be in the Firefox.
users may copy that code to userChrome.js file in their profile folder (create it, if there isn't such a file) to make it work.
Attached patch review? (obsolete) — — Splinter Review 
another patch. Works better with Fx4 and has no bug with tabhistory being mixed up from different tabs.
(In reply to comment #227)
> another patch. Works better with Fx4 and has no bug with tabhistory being mixed
> up from different tabs.
Did you write this patch? How is it different from the other patch that this one prevents tabhistory from being mixed up?
(In reply to comment #228)
> Did you write this patch? How is it different from the other patch that this
> one prevents tabhistory from being mixed up?

Woops, posted the wrong code.
No, I'm not the author of this code, it is Tab History add-on by Mattk https://addons.mozilla.org/ru/firefox/user/9229/ (that is not working with Fx 4.0 and the author has permanently moved to chrome), then it was modified by cfinke ( https://addons.mozilla.org/ru/firefox/user/2519/ ) as Tab History Redux (and it has some bugs), then it was modified by Ingo the NettiCat ( https://addons.mozilla.org/ru/firefox/user/516763/ ), who has fixed the rest of all the bugs and allowed me to post this code as a patch to that bug.

This code is different from the one I previously posted (that is Tab History modified by Anton to be compatible with Fx 4.0), but it had some bugs, that remained unfixed.

The code I am posting now can be downloaded as an extension from the site of it's author: http://netticat.ath.cx/xpi/install.php?id=TabHistoryReduxPlus.
Attachment #495001 - Attachment is obsolete: true
Attachment #495222 - Flags: review?(netdragon)
Attachment #495222 - Flags: feedback+
Attachment #495222 - Flags: approval2.0?
Attachment #495222 - Flags: review?(netdragon)
Attachment #495222 - Flags: feedback+
Attachment #495222 - Flags: approval2.0?
and why the **** the patch didn't get the approval?
what is the purpose of keyword "helpwanted" for this bug if you reject any help?
11 yeared old bug. Awesome!
Blocks: 569593
Oh ****, I missed your birthday!
Well, better later than never, so...
Happy 12th birthday, buggy!
Attachment #476522 - Attachment is patch: false
Attachment #495222 - Attachment is patch: false
bump
Dear teamleads, this material proves that you suck at setting priorities to the bugs: https://blog.mozilla.org/ux/2012/06/firefox-heatmap-study-2012-results-are-in/
HAPPY 13th BIRTHDAY, DEAR BUG #18808!!!!!!
EVERYBODY PARTY!!!
They are too busy eliminating "Send link/page" menu item.
I don't want the behaviour requested here, and I can tell some reasons why.

 1) It would be illogical, and would disturb me. When I create a new tab or window, I want to walk from a fresh start.
 2) It would take memory, and possibly quite a lot. In the history, the form data is remembered. Some effort is already being spent on reducing the (way too big) memory footprint of tabs’ “past” in Firefox.
 3) It would place junk in session store, and possibly quite a lot. In the history, the form data is remembered. Some effort is already being spent on reducing the (way too big) junk in session store.

Old IE on Windows had this buggy behaviour of taking the current window with him when I requested a *new* window. I think IE has got rid of this now. Let’s not introduce such a bug in Firefox now.
I, for one, used it a ton, and it's much more logical and convenient than having to remember, find, and return to the parent tab (providing you didn't already close it) in order to hit Back.  Memory and storage weren't an issue.

As with anything else, it should be user-configurable.  Then literally everybody can be happy.
From the discussion here (going since 2000 and dead since 2013!) seems there is slim to no chance of getting the Ctrl-K shortcut to duplicate an open page AND history, as it exists in msie. I had to go back to the msie because of that feature alone.
BTW, Ctrl+click on Back or Forward button (or any item from history) opens this link in new tab with duplicated history. It is very useful. See also comment #222 — duplicate tab via Ctrl+drag.
Flags: needinfo?(cece.manis83)
Assignee: netdragon → nobody
Severity: normal → S3

Redirect a needinfo that is pending on an inactive user to the triage owner.
:sefeng, since the bug has high priority, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(cece.manis83) → needinfo?(sefeng)

This doesn't look high priority.

Flags: needinfo?(sefeng)
Priority: P2 → P3
Severity: S3 → --
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: