Frank Yan (:fryn) Reporter
	Description • 14 years ago

STR:
1. Set browser.sessionstore.max_concurrent_tabs to 0.
2. Cmd+click (ctrl+click on win/lin) back/forward on a tab.

Expected results:
A new tab opens with the url of the previous/next page in the tab's history.
(Note that we now inherit tab history when cmd+clicking back/forward.)

Actual results:
A new tab opens with the same url. (The tab was duplicated.)

	Paul O'Shannessy [:zpao] (not bugmail, email directly)
	Comment 1 • 14 years ago

Alright, so my guess after a quick look is that since we aren't calling restoreTab when the tab is duplicated, we think that the tab needs to be restored when it gets selected. So in session restore we call gotoIndex when the tab gets selected, overriding the index that was just selected.

I'm guessing this should also be reproducible when done in the middle of restoring a bunch of tabs.

There are potentially other issues with this. The build history & call gotoIndex balance is delicate and currently broken in sessionstore. It would be easier to keep all of that together than have random other things calling into a potentially broken history (c.f. bug 597315)

This is a bit tricky since in sessionstore we expect these restores to happen by us. I'm thinking The best thing to do here is to special case the duplicateTab API so that it restores immediately instead of being put into the cascading queue. Might make things a little messy(ier) internally though :/

	Paul O'Shannessy [:zpao] (not bugmail, email directly)
	Comment 2 • 14 years ago

blocking?

Personally I'd say no and take a fix in a .x, but this does cause an existing feature to break for a minority of users.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 3 • 14 years ago

Non-standard about:config prefs don't block, no.

	Paul O'Shannessy [:zpao] (not bugmail, email directly)
	Comment 5 • 14 years ago

Dao has a patch in bug 623893 so just going to dupe to that.