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.

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.

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!

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.

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.

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.

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.

this sounds like something for History, yes? please lemme know if not.

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.

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. ***

Why does this bug depend on a bug that has been marked a duplicate of this?

Someone forgot to clean up, is all :-)

nav triage team: not a beta stopper.

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.

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).

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.

_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.

*** 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

Notice: This should also work on tabbed browsing.

reassign to Navigator manager

Changing from future to wontfix as suggested by Brian "NeTDeMoN" Bober

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.

-> nobody

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. ***

*** Bug 168045 has been marked as a duplicate of this bug. ***

*** Bug 170113 has been marked as a duplicate of this bug. ***

*** 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.

*** 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.

*** 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. ***

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

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.

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.

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...

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.

When bug 225680 gets fixed Ctrl+Shift+N does exactly what is proposed here (and the same as Ctrl+N in IE).

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?

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.

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.

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!

Oh ****, I missed your birthday! Well, better later than never, so... Happy 12th birthday, buggy!

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.