320989 - Reuse last tab if blank

Status: ASSIGNED

(Firefox :: Tabbed Browser, defect, P4)

Description

[Mike Connor [:mconnor]]

If we call addTab and the last tab is empty, use that tab instead.  Patch upcoming.

Comment 1

[Mike Connor [:mconnor]]

Attachment: foo

This reuses the last tab if the last tab is blank and the tab to be added isn't another blank tab.

Comment 2

[Jesse Ruderman]

about:blank doesn't always mean the tab is empty.  It could be a page generated using DOM2.

Comment 3

[Mike Connor [:mconnor]]

Comment on attachment 206435 [details] [diff] [review]
foo

Is there a reasonable way of detecting a modified about:blank URL?

Comment 4

[Robert Strong (they/them - no direct email)]

There are also timing issues using this method... when opening multiple pages in new non focused tabs a previously opened tab with a page that hasn't loaded yet is often over written by the next page to be opened.

Comment 5

[Mike Connor [:mconnor]]

hmm, right, last time around I hit that, and I fixed that, but I lost the patch when OS X ate itself.

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #3)
> (From update of attachment 206435 [details] [diff] [review] [edit])
> Is there a reasonable way of detecting a modified about:blank URL?
> 

Simple check seems to be to check that body has no child nodes. Wouldn't catch everything though.

Comment 7

[Ben Basson]

(In reply to comment #6)
> Simple check seems to be to check that body has no child nodes. Wouldn't catch
> everything though.

A slightly more elaborate check would be to fetch the document source as a string and compare it to a XMLHttpRequest DOM "string" for the true about:config document. I might be missing something, but I imagine that would be fairly reliable and non-destructive.

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 206435 [details] [diff] [review]
foo

>+            if (aURI != "about:blank") {

Why is about:blank special cased? What this implies to me is that when a group of tabs is opened if the first of the set is blank, the last _isn't_ reused and another blank one added. Is this to make sure that Ctrl+T still works? Something more tailored to that case would seem more appropriate if so.

>+                if (aPostData === undefined)
>+                  aPostData = null;

Isn't this coercion implicit? If not, why not change all the callers to make the API tighter, rather than add code bloat here?

Comment 9

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

>+              var browserForLastTab = this.getBrowserAtIndex(this.mTabContainer.childNodes.length - 1);

use this.mTabs instead of this.mTabContainer.childNodes

Comment 10

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(In reply to comment #5)
> hmm, right, last time around I hit that, and I fixed that, but I lost the patch
> when OS X ate itself.
> 

Would checking nsiwebprogresslistener.isLoadingDocument cover that?

Comment 11

[(not currently active) Ted Mielczarek]

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

Comment 12

[Asaf Romano (gone)]

Useful docshell attribute at bug 241972.

Comment 13

[nathaniel]

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

Comment 15

[Håkan Waara]

Anyone interested in reviving this patch?

Comment 18

[u294409]

Please change target milestone - current is no longer adequate.

Comment 19

[Tyler Downer [He/Him]]

Putting as Future for now, until we get something on this.

Comment 20

[Dave Townsend [:mossop]]

The new tab stuff will likely make this bug invalid.

Comment 21

[Dão Gottwald [:dao]]

Attachment: patch

Comment 22

[Dão Gottwald [:dao]]

Attachment: patch

A number of sessionrestore tests also needed attention. This passes on the tryserver.

Comment 23

[Shawn Wilsher :sdwilsh]

dao - does this still apply?  If so, feel free to point this request at me.

Comment 24

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 379530 [details] [diff] [review]
patch

This no longer applies cleanly.

Comment 30

[wojtek]

Just the other day I asked about this exact issue in forums https://support.mozilla.org/en-US/questions/1240609 and after unsatisfying reply decided to open a new bug/feature request... just to find out that there is already one.

So a small +1, this is quite annoying when you have window with single, blank tab (ideally without history) and opening link from external tab open new tab next to this one.

Comment 32

[wroot]

I didn't have this problem for many years until old add-ons were killed (which probably had their own workaround for this issue). Now i have switched to Firefox Quantum and webextensions and have to deal with this annoyance from 14 years ago. My own bug report has been closed as a duplicate of this. Though there is a number of similar reports still open. Not sure if this super old report with outdated comments and patches should be kept alive and untouched for another 14 years (as it seems). The thing is that in some cases Firefox reuses the blank tab and in some not. So this bug report is too broad and is not representing the current state. E.g.

Sometimes add-ons can reuse last blank tab, sometimes don't https://bugzilla.mozilla.org/show_bug.cgi?id=1539927
It reuses blank tab when opening a bookmark, but not when opening a few at once https://bugzilla.mozilla.org/show_bug.cgi?id=1498093
It is not reusing a blank tab when opening links from external application https://bugzilla.mozilla.org/show_bug.cgi?id=1502836

Comment 33

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 10 duplicates, 69 votes and 50 CCs.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 34

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.