192635 - Moving tab to new window doesn't copy/keep session history

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[Michael Zajac]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030204 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030204 Chimera/0.6+

After using the "Move Tab to New Window" contextual menu command, there's only
one item in the Go menu.  We haven't really moved the Tab, just created a new
window and loaded the same page.

Remember: "Those who forget their history are doomed to repeat it."

Reproducible: Always

Steps to Reproduce:
1. Have several tabs in a browser window.
2. Click a few links to build a history -- you'll have several items in the "Go"
menu.
3. Control-click on the tab and select "Move Tab to New Window" -- a new window
opens with the currently viewed page in it.
4. Look at the "Go" menu -- there's no history.

Actual Results:  
The history is lost.

Expected Results:  
The new window should have the same "Go" menu that was visible before moving the
tab.

Comment 1

[Greg K.]

Confirmed using Chimera/2003021707. History does not follow the document during
the "Move Tab to New Window" operation.

Comment 2

[Martin Girschick]

This behaviour is also annoying when using "open in new window/tab". It happens
quite often that I open several tabs from a search page and find myself
accidently closing the one which has the correct history attached to it. I guess
copying the history to all tabs/windows which are openend from a page doesn't do
any harm. Should I file an RFE for that?

Comment 3

[Mike Pinkerton (not reading bugmail)]

i'm not sure if gecko allows us this feature, though it's reasonable.

Comment 4

[Samuel Sidler (old account; do not CC)]

This bug is no longer valid with the Go menu now showing global history.

However, I'm leaving it open and updating the description to show a very related
problem:

The back button has no history attached to it when moving a tab into a new window.

(CCing Simon to look at)

Comment 5

[Simon Fraser [no longer active]]

This will be tricky to fix.

Comment 6

[Samuel Sidler (old account; do not CC)]

Targeting for 2.0 based on some Gecko work being done which may help with this.

Comment 7

[Stuart Morgan]

Why does this need any core work? Simon, is there some reason we couldn't just just move the BrowserWrapper to a new window?

Comment 8

[Simon Fraser [no longer active]]

(In reply to comment #7)
> Why does this need any core work? Simon, is there some reason we couldn't just
> just move the BrowserWrapper to a new window?

That would involve ripping the whole view hierarchy out of one window, and inserting it into another. I'm not even sure if AppKit supports that, but if it does, I bet there's stuff in nsChildView that would break (like i18n text input). It's worth a try, but my guess is that you'll run into hard-to-find bugs. 

Comment 9

[Oded Arbel]

I'm not sure what is the status with this bug (as it is quite old), but current Firefox (not Camino) has this feature working well.

Comment 10

[Chris Lawson (gone)]

(In reply to comment #9)
> I'm not sure what is the status with this bug (as it is quite old), but current
> Firefox (not Camino) has this feature working well.

Since this is specifically a Camino bug, that's expected.