Closed Bug 109551 Opened 23 years ago Closed 21 years ago

show home/current/blank page in new tab

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.4alpha

People

(Reporter: MozillaUser, Assigned: jag+mozilla)

References

Details

(Whiteboard: [adt2])

Attachments

(2 files, 4 obsolete files)

RFE spun off from bug 105589

When you create a new tab, it loads blank. Some people love this, as it makes
for slightly faster tab-opening-time, but others hate it, because they always
want their start page in the new tab, and what good is it to save time not
loading a page when you always know in advance what page you want next?

Anyway, fortunately this is a very simple issue that we need not bicker and
argue about, we can just add a simple pref to make everybody happy.

I have taken the time to figure out what code is neccisary, but unfortunately I
do not have access to a build system of my own, so I am going to need the
assistance of others to test this code and attach it as a real patch.

Code follows:
First have a look at the BrowserOpenTab function in
/xpfe/browser/resources/content/navigator.js (
http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/navigator.js#808
)

It currently reads:

  function BrowserOpenTab()
  {
    gBrowser.selectedTab = gBrowser.addTab('about:blank');
    setTimeout("gURLBar.focus();", 0); 
  }

And all we need to do is change it to;

  function BrowserOpenTab()                                                       
  {
   if (pref && pref.getBoolPref("browser.tabs.use_new_page_default") &&
getBrowser().localName == "tabbrowser") {
      var handler =
Components.classes['@mozilla.org/commandlinehandler/general-startup;1?type=browser'].getService(Components.interfaces.nsICmdLineHandler);
      var startpage = handler.defaultArgs;
      gBrowser.selectedTab = gBrowser.addTab(startpage);                            
   } else {
      gBrowser.selectedTab = gBrowser.addTab('about:blank');                   
   }
   setTimeout("gURLBar.focus();", 0);
  }

I understand from comments on bug 105589 that Hyatt doesnt have time for this
one right now, so are there any other mozilla developers who can step up and
help me out with this puppy?
Keywords: helpwanted
Ick. I didnt mean for those two lines to wrap.
In my use of the tabbed browser, I most frequently want to start with another
copy of the page CURRENTLY being displayed by the tab (or window) from which I'm
initiating the new tab. (I then often go forwards into a "submit comments" page
within one of the tabs, and use the other tab to see the original material I'm
attempting to talk about.

Currently, I copy the location from the old tab and paste it into the new tab.
Nasty. IMHO this preference should provide 3 alternatives (#1 none; #2 home
page; #3 clone a copy of the current page).
Great idea, but the suggested feature is already a part of tabs, only better.
Just Ctrl-click on the link on the existing tab, and the "submit" or whatever
you are going for opens in a new tab. Best of all - The focus does NOT shift to
the new tab. So you can keep reading the original page while the new tab is loading.
Rick: The example code as I wrote it ought to respect the "Last page visited"
new-window setting, which ought to get the result you want. Yes?

Still waiting on somebody to test out the code... Its gonna be a good 2-weeks to
a month before I can find time to get my own build system up and running...
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
> Great idea, but the suggested feature is already a part of tabs, only better.
> Just Ctrl-click on the link on the existing tab, and the "submit" or whatever
> you are going for opens in a new tab. Best of all - The focus does NOT shift to
> the new tab. So you can keep reading the original page while the new tab is
> loading.

Hmmm....  linux x86 2001-11-09-06:

Doing a ctrl-click causes a new *window* to be opened, not a new tab.
Are you sure about this feature?  I assume this is the behavior on MSWin?
> Doing a ctrl-click causes a new *window* to be opened, not a new tab.
> Are you sure about this feature?  I assume this is the behavior on MSWin?

See the option in Preferences->Navigator->Tabbed Browsing
silly me, I just realized that navigator.js lives in comm.jar , so I can edit it
and test it right here on my nightly build.

Something is wrong with my code as written. I am getting:

Error: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult:
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://navigator/content/navigator.js :: BrowserOpenTab :: line 814"  data: no]

grrr. Ill keep working on this. All help is always appreciated.
Ahaha! Now I see the trouble! browser.tabs.use_new_page_default needs to be
added to /modules/libpref/src/init/all.js 

That is why I was getting that error when it was undefined in my prefs.js file

So anyway, I have tested out my new pref now, and it works perfectly. With
browser.tabs.use_new_page_default set to false you get the current behavior of
loading a new blank tab

With browser.tabs.use_new_page_default set to true the new tabs respect all
three settings for new windows, homepage, blank, and last visited

So (pending the extra line for all.js), the code is good. Now we just need to
get this puppy attached as a REAL patch
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Yay for patchmaker!

Attached is my same code in patch form. The one thing the patch does NOT do is
add the pref to all.js , because patchmaker cant do that :(

So if you want to test this yourself, be sure to add
user_pref("browser.tabs.use_new_page_default",false); to your pref.js file
first.
Okay. here is what is new in this patch:

* Added the pref to the prefs window on the Navigator->Tabbed Browsing panel
* Changed the pref name to: browser.tabs.default_new_tab_behavior and made it
an int instead of a bool to facilitate easyer usage of a radiogroup instead of
a checkbox
Hmmm. I see I do not have the privileges necessary to mark my own attachments
obsolete. Consider the first patch obsoleted.
*** Bug 110232 has been marked as a duplicate of this bug. ***
Comment on attachment 57799 [details] [diff] [review]
patch to give those new tabs a little respect!

marking obsolete for james
Attachment #57799 - Attachment is obsolete: true
*** Bug 111616 has been marked as a duplicate of this bug. ***
Keywords: helpwantedpatch, review
spam: set your filter for "SeverusSnape" to avoid the influx of bugmail

changing QA contact of open tabbed browser bugs from blake to me. if this bug
requires a reassignment, however, feel free to change it!
QA Contact: blakeross → sairuh
*** Bug 112090 has been marked as a duplicate of this bug. ***
James- you should have sufficient privileges now. 
Target Milestone: mozilla0.9.7 → mozilla0.9.8
*** Bug 118567 has been marked as a duplicate of this bug. ***
*** Bug 118841 has been marked as a duplicate of this bug. ***
Soooo... has anybody had a chance to try this patch out? Any feedback? Any
reviews? Anything?
grrr... well, this patch has been left to sit for so long that patch-maker can
no longer apply it to nightly build 2002010803 :(

I will update it if/when I get a chance...
The patch looks fine. Change "Respect New Page" to "Respect New Window" and
sr=hyatt.  Get an updated patch and we can get it checked in.
Attached patch freshly updated patch (obsolete) — Splinter Review
forsaking my other duties for this hour, I have updated the patch to work with
my nightly build 2002010803 (Win 95) Remember that this lacks the default value
for the pref in all.js ... somebody else will have to do that part, as I cannot
alter all.js with patchmaker.
Attachment #57806 - Attachment is obsolete: true
Someone asked for feedback/reviews of the earlier patch (the one that was
current as of a couple of days ago), so.....

I've applied it to 0.9.7.1, and it seems OK.  One of the parts of the patch
failed (I forget which one), but it still works fine.  Also, I wrote a quick
shell script for applying the patch---it backs up the stuff being patched,
unzips the files, patches them (patches are contained within the script), and
then updates the zips (oh, and it reminds you to update prefs.js).  Does this
sound useful to anyone but me?
*** Bug 119866 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
Comment on attachment 64054 [details] [diff] [review]
freshly updated patch

r=jag, sr=hyatt

I'll check this in when I get a chance.

Note that I'll modify it so the indentation levels are 2-space, not 3-space in
navigator.js
Attachment #64054 - Flags: superreview+
Attachment #64054 - Flags: review+
> ------- Additional Comment #29 From jag (Peter Annema) 2002-01-22 18:31 -------
> 
> (From update of attachment 64054 [details] [diff] [review])

Tested patch with build 2002013103 (system is NT 4.0, if that matters).  When
the patch is installed, CTRL-T no longer creates a new tabbed window at all.
File-->New-->Navigator Tab doesn't work, either.

Is this working for anyone else?  If so, any idea what could be hosing mine,
and is there any chance I could get someone to send me an ftp/www site where
I can get a working copy?
Yeah, I noticed this too....seems like it doesn't remember any changes made to
the tabbed preferences section either.  Thought it was just me and I messed up.
*grr*

Hmmm. I wonder if this could have anything to do with bzabarsky's checkins for
bug  105537 on Jan 23. I havent taken the time to test this patch since then.

Jim: Tobias: do you guys see any interesting Javascript errors in the javascript
console after attempting to oppen a new tab while this patch is applied?
This might be related to bug 36269.

I'd be happy if the new tab did whatever a new window does, in fact I would
argue this should be the default.

To keep everyone happy, a dropdown list in a config dialog like this would be nice:

new window opens ---------------------V
                 * blank page
                 * home page
                 * same as current page

new tab opens  ---------------------V
               * blank page
               * home page
               * same as current page

I'm just raising the idea.  I guess if this is to go ahead, it should probably
be filed as a separate RFE.
Sorry for the spam.  I guess my comments belonged in bug 105589, but how do
users get any input there if it's a WONTFIX?
> I guess my comments belonged in bug 105589, but how do
> users get any input there if it's a WONTFIX?

As far as I know, they don't - unless David Hyatt reverses his WONTFIX decision
or somebody higher up does.  Until and unless that happens, this current bug is
about having new tabs do exactly the same thing as new windows, not about a user
defined preference for each separately.
nsbeta1- per ADT triage team, ->1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.2
*** Bug 132987 has been marked as a duplicate of this bug. ***
Here's a *PARTIAL* fix---it addresses the bug (that crept in as of ca. 0.9.6)
that causes Mozilla to open a blank tab with CTRL-T or File->New->NavigatorTab,
but that's it....  So, for those who simply want to correct that, this works.
For those who want the option, someone who knows Javascript will need to do
the rest to make that bit work....

Anyways, here's what I did to fix it:

   1) backup comm.jar
   2) extract content/navigator/navigator.js from comm.jar
   3) In the function BrowserOpenTab() (approx. line 800), add the following
      line after the setTimeout line:

         BrowserHome();

   4) update comm.jar with the new file

Hopefully this will at least be useful to some.  I know it fixes my #1
gripe with 0.9.6 and beyond, and thus allows me to upgrade beyond 0.9.5,
which is a Good Thing.  :-)

If someone can work this into a config option+patch, that's even better....
Attachment #64054 - Attachment is obsolete: true
Summary: Need a pref to allow new tabs to respect the new window settings → [rfe] prefs to show home/current/blank page in new tab
This pref should go with the "When Navigator starts..." pref.
*** Bug 147118 has been marked as a duplicate of this bug. ***
Nominating for buffy, this is nice polish that people have been asking for.  I
don't see why we'd have a new pref for this, the current one should suffice. 
Perhaps we should just tweak the wording.
Keywords: nsbeta1-nsbeta1
We have to be careful how this behaves when we incorporate GroupMarks into this mix.
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
*** Bug 158809 has been marked as a duplicate of this bug. ***
Eh, why don't you simply add a new keybinding for ctrl-shift-tab (for example)
to open a new tab with a preferred URL set.

<key id="key_OpenPreferredTab" key="t" modifiers="shift"
command="doCmd_addNewPreferredTab"/>

<command id="doCmd_addNewPreferredTab" oncommand="addNewPreferredTab()"/>

function addNewPreferredTab()
{
  var aPreferredURI = pref.getComplexValue("browser.tabs.preferred",
"http://insert.website.here/", Components.interfaces.nsIPrefLocalizedString).data;
  gBrowser.selectedTab = gBrowser.addTab(aPreferredURI);
  return;  
}

Just my $0.2 cents
Two typo's: ctrl-shift-tab should read "ctrl-shift-t" and modifiers="shift"
should be changed in modifiers="shift, accel" to make it work, and don't ask me
where that |return;| came from, because that can also be removed.

/HJ
It's now August 2002, and I'm using Mozilla v1.1beta (+ a couple weeks)... so
this bug/request is 9 months old now.  What is the current status of this? 
Isn't this a rather simple issue of adding a few lines of code to implement a
preference, and shouldn't it be incorporated into a nightly build or something
like that?

Thanks,
Anthony
For Anthony, and everyone else watching this bug....

As of a day or two ago, if you're using Multizilla for tabbed browsing (and
you definitely *SHOULD* be using Multizilla!), it's fixed.  HJ added a new
pref in Multizilla 1.1.21 to cover this ... just because I asked for it.

After installing multizilla (http://multizilla.mozdev.org) and restarting
Mozilla, look in the Multizilla section of the preferences---from there,
under "Links", you'll see "[ ] Use the preferred location for new tabs".

Check that box, and you're done.  Bug 109551 will become a non-issue. Of
course, if you're not using Multizilla, you're still stuck with trying to
get this fixed.

With that, I'm removing myself from the CC list on this one.  I just don't
care about this one anymore.
QA Contact: sairuh → pmac
Summary: [rfe] prefs to show home/current/blank page in new tab → prefs to show home/current/blank page in new tab
For a number of reasons people might not use MultiZilla. So this bug should be
fixed for Mozilla, resp. this feature should be implemented. I really miss it.

I understand the code is written. For the UI
(Edit->Preferences->Navigator->Tabbed Browsing) I suggest a new framed box
underneath "Open tabs instead of ..":

+- When a new tab opens, display ----+
|                                    |
|  [o] Same as new window            |
|  [ ] Blank page                    |
|  [ ] Home page                     |
|  [ ] Last page visited             |
|                                    |
+------------------------------------+

Any comments/help on that? Thanks, Meinhard.
*** Bug 178236 has been marked as a duplicate of this bug. ***
This goes in response to comment#49. 

I don't know if I'm a rare case, but my HOME PAGE which I love reading when I
first load the browser, and my NEW TAB page needs are NOT the same. My home page
is a news site, and on the other hand, when I open new tabs (CTRL-T) it is often
 to search something new, based on the random thinking done after reading
something ("hey this reminds me that I should search for..."). 

(AND NO, don't mention the sidebar, which is very useful and I use it daily when
I'm on my 1024x768 desktop-PC/19" monitor, I'm thinking here about browsing on
my ancient laptop with a tiny 10" LCD screen @ 800x600, so the sidebar is out of
the question, and YES I know about F9 :).

Let me explain:

I wasn't aware of the existance of this bug, so I opened a new bug last night
with a very similar suggestion, within seconds, Mr. "Flash" Dveditz :-D marked
my bug duplicate of this one, so I hurried to read this one.

My problem with this bug, as it is right now, is simple, I see that someone has
decided that there are only 3 options that an user might want:

-Blank
-Same as current page
-Home Page.

Well, as I said earlier my needs don't fit any of these 3 options. 

Proposal:
WHAT I'd like to see: EVERYTHING suggested so far for this bug, but with a
fourth option: Open->New Tab->New tab Favorite. (URL saved somewhere in prefs).

In other words, this would be a second url entered somewhere in the prefs, the
same as the "home page" but would apply ONLY for new tabs. (you can call it
"home page for new tabs")

So when I launch the browser every morning (or afternoon :), I get netscape.com.
From that point on, CTRL-T should open a new [my url of choice saved in prefs].
(Google.com in my case, or ebay.com if I decided to change it for something else
like when I have some money in my pockets and I'm in "shopping season mode" ;).

Did I make my point clear? Will I be burned at the stake? Be nice to me,
please.. . ;)

Just my $.02
Fernando
I vote for Suggestion #49 idea; that is having 4 options of what to do when
starting a new tab.  IMHO this needs fixed in mozilla.
This goes in response to comment#52.

The comment #49 that you mention proposed this preference setting:

+- When a new tab opens, display ----+
|                                    |
|  [o] Same as new window            |
|  [ ] Blank page                    |
|  [ ] Home page                     |
|  [ ] Last page visited             |
|                                    |
+------------------------------------+

Maybe I'm too dumb, but what would "last page visited" achieve?? Who would like
to use that? In other words, if I'm in the middle of a search on google.com the
url would look something like this:
http://groups.google.com/groups?q=the+barkto+incident&ie=UTF-8&oe=UTF-8&hl=en

the same would apply to altavista.com, reading news on cnn.com, searching bugs
on bugzilla.mozilla.org etc... if I have selected the last option "last page
visited", when I press "Ctrl-T" it would open a new tab with the "last page
visited" which is... the page I was reading before pressing Ctrl-T !! Who really
wants to have two tabs of the SAME URL? how often??

What I propose, instead, are these options:

+- When a new tab opens, display ----+
|                                    |
| [ ] Blank page                     |
| [ ] Home page                      |
| [ ] "New Tab" favorite [custom url]|
|                                    |
+------------------------------------+
Re comment 53 and the exclusion of "Last page visited". Don't eliminate an idea
and assume that a particular feature would be useless to others. Thats how we
got stuck with the current blank-tab-only system.
Nor should you assume that every possibility should be exposed in the UI or even
implemented at all. _That's_ how we ended up with a bloated product and a prefs
window with more controls that a commerical airliner.
re comment 53, "Last page visited". As long as the history is copied across as
well i would find this very useful. when i used internet explorer, i would
sometimes be partway through replying to a message on a site, and want to look
at another message for something. to do this, i'd open a new window, which would
default on the current page, and then go back in the history list to get the
previous page(s) back up.

As an extra note, what would mozilla do if the home page option for new tabs is
selected, and a tab group is selected as home. I'm not sure what would be the
right thing to do here?
Adding myself to the CC.  For now, I use Piro's Tabbed Browser Extension
http://white.sakura.ne.jp/~piro/xul/_tabextensions.html.en#download
Target Milestone: mozilla1.2alpha → mozilla1.4alpha
For now I don't want to add more pref UI for this. Instead I'm going to reuse
the "normal" homepage for this, using the first page if the homepage is a
group.
Attachment #116418 - Flags: superreview?(bryner)
Attachment #116418 - Flags: review?(shliang)
Attachment #116418 - Flags: review?(shliang) → review+
Attachment #116418 - Flags: superreview?(bryner) → superreview+
Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
QA Contact: pmac → sairuh
Okay, here's the first "I don't like the new behaviour" post

I have Mozilla set to open a blank page when it starts up. NOw the behaviour is

Ctrl-N - load blank page in new window
Ctrl-T - load my homepage in new tab

ugh. I really wish that new tab followed new window prefs as set by the user.
Until we have a UI for a new tab as suggested in many of the comments. At which
time we could have different behaviour. That seems like a more reasonable
approach to me. I think the only difference between new tab and new window
should be that one opens a tab and the other, a window. The URL loaded in both
cases should be consistent i.e. blank page, home page, or last page visited.

But if enough people think that the current behaviour is more usable and much
better than I'll shut up and change my prefs to get what I want.
I don't mean to cause unnecessary traffic here, but what exactly has happened? 
(I'm not complaining, I'm just trying to understand the sequence of events here.)

I don't see any UI for new tab behaviour so I'm assuming it's hardcoded or
backend prefs.  However, I also don't see any "browser.tab" prefs that control
what a new tab does.

The patch that was checked in implies that this is now hardcoded to the home
page (as opposed to blank) but comment 60 mentions changing prefs.

If there are prefs, what are they; if there aren't I don't quite see how this
bug has been resolved "fixed" since it's always been about having a pref for
what new tabs do...
Further investigation: There seems to be no way to get a new tab to do anything
other than going to a user's home page.  Although this is exactly what *I* want
new tabs to do, it is not a resolution to this bug - which is about setting a
preference for tab behaviour.  Discussed here have been UI, backend pref, and
even having tab behaviour linked to what navigator at startup does - blank,
home, last visited (new tabs don't follow the latter either - they are ONLY
going to the home page).

So, while this may satisfy some people (such as myself) who want new tabs to
open the home page, just as many people will still be dissatisfied.  The patch
isn't a complete fix for THIS bug.  (Although it may be an interim step.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
You're right, I screwed up. Fix coming up.
Comment on attachment 116975 [details] [diff] [review]
Get "page to load" from command line handler, dummy

Almost, but not quite.
Attachment #116975 - Attachment is obsolete: true
Attachment #116976 - Flags: superreview?(bryner)
Attachment #116976 - Flags: review?(shliang)
This caused bug 103329 to reappear.
With both today's nightly and today's nightly + the most recent patch I'm not
seeing bug 103329.

R.K.Aa, could you tell me a little more about your settings?
Comment on attachment 116976 [details] [diff] [review]
Fix typo in above patch, split defaultArgs on \n

looks good and works right :)
Attachment #116976 - Flags: review?(shliang) → review+
To comment 68:
i just backed out like this and rebuilt on Linux, and it cures bug 103329:
cvs update -j1.490 -j1.489 mozilla/xpfe/browser/resources/content/navigator.js

-I have all prefs under "Tabbed Browsing" checked.
-I have checked Navigator radio button "When Navigator starts up, display"
"Blank page"
-The "Home Page" location field in prefs/Navigator is blank.
> -The "Home Page" location field in prefs/Navigator is blank.

R.K.Aa:  I see the same thing as you when I actually leave the Home Page field
devoid of anything (blank).  But if I make my home page "about:blank" it works
fine and does *not* cause the questionable behaviour when opening a new tab.  It
looks like you should specifically tell it to use "about:blank" - if you don't,
and it "assumes" it on its own, it causes problems.  So - set it to
"about:blank" and see if the problem persists...
Blocks: 197014
Blocks: 103329
Attachment #116976 - Flags: superreview?(bryner) → superreview+
Ah!

Let me see if I can fix that over in bug 103329 then.
Marking fixed again. Patch coming up in bug 103329 for the "" vs. "about:blank"
issue.
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
Verifying with latest (0313) build.

Minor nit: If you start with a home page, change your settings to "last page
visited", and open a new tab, it ends up being blank rather than the home page
(which, theoretically, should be the last page visited).  However, this is so
minor (and probably something that nobody would ever do) that it should be
addressed in a different bug, if it even is a bug...

Any further discussion / debate of what new tabs should do (such as having new
tabs behave *differently* from startup options) should be addressed in a new
bug, not this one.
Status: RESOLVED → VERIFIED
If someone does open such a bug can they make a note of the bug number in this
bug or reference this bug in some way. 
TIA
This bug simply isn't fixed. Where is the pref??
New bug 197671 is filed, but with wrong severity: Enhancment instead of major.
This is bad UI if i ever saw it.
Please don't SPAM this bug.  The resolution addresses one of the multiple
proposals submitted in various comments here.
Jason Bassford wrote:

>Please don't SPAM this bug
>The resolution addresses one of the multiple
>proposals submitted in various comments here.

I consider my comment to be of interest - not spam - for several reasons.
First of all it answers the highly relevant question in comment 75.

Many bugs flow over of ideas and proposals. What THIS particular bug never fixed
was the original bugreport. It is very unusual that a bug-report is allowed to
morph that badly, and has to be filed time and time again.

What's worse: It was *not* the QA but Jason Bassford who verified this bug as
fixed. Since the result of the "fix" is that Mozilla now has misleading text in
the prefs UI in addition to reduced usability and performance for those who
start the browser up with a homepage, I hope the real QA here wakes up and
changes the bug resolution.

The bug should not have been resolved as fixed in the first place. But why some
random bypasser is  allowed to verify the bug as fixed is perhaps the biggest
riddle.
As the original reporter of this bug, I agree that this bug is NOT fixed at all,
and that bug 197671 is only a duplicate of the original intent of this bug.

However, I will not re-open this bug, as it is Jag's bug and not mine, and the
bug number under which this issue finally gets fixed is irrelevant, just so long
as it does get fixed eventually.

Refer all further comments to bug 197671
Summary: prefs to show home/current/blank page in new tab → show home/current/blank page in new tab
Mind you that "when navigator starts up" and "what a new window does" have been
one and the same thing for a long time. Extending that into "what a new tab
does" seemed only natural.

But you're right, I should really have left this bug alone or marked it WONTFIX,
and then filed a new bug "page loaded in new tab should be the same as page
loaded in new window".

Now for some comments in bug 197671.
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.