109551 - show home/current/blank page in new tab

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[James Paige]

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:

Comment 1

[James Paige]

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?

Comment 2

[James Paige]

Ick. I didnt mean for those two lines to wrap.

Comment 3

[Rick Stockton]

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

Comment 4

[John Fredlund]

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.

Comment 5

[James Paige]

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

Comment 6

[Brad Garcia]

*** This bug has been confirmed by popular vote. ***

Comment 7

[Brad Garcia]

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

Comment 8

[Jonadab the Unsightly One (Nathan Eady)]

> 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

Comment 9

[James Paige]

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.

Comment 10

[James Paige]

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

Comment 11

[James Paige]

Attachment: patch to give those new tabs a little respect!

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.

Comment 12

[James Paige]

Attachment: even better patch (whee! this is fun!)

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

Comment 13

[James Paige]

Hmmm. I see I do not have the privileges necessary to mark my own attachments
obsolete. Consider the first patch obsoleted.

Comment 14

[John Morrison]

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

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 57799 [details] [diff] [review]
patch to give those new tabs a little respect!

marking obsolete for james

Comment 16

[R.K.Aa.]

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

Comment 17

[sairuh (rarely reading bugmail)]

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!

Comment 18

[John Morrison]

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

Comment 19

[Peter Trudelle]

James- you should have sufficient privileges now. 

Comment 20

[R.K.Aa.]

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

Comment 21

[R.K.Aa.]

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

Comment 22

[James Paige]

Soooo... has anybody had a chance to try this patch out? Any feedback? Any
reviews? Anything?

Comment 23

[James Paige]

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

Comment 24

[David Hyatt]

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.

Comment 25

[James Paige]

Attachment: freshly updated patch

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.

Comment 26

[Jim Graham]

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?

Comment 27

[Olav Vitters]

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

Comment 28

[David Hyatt]

Reassigning to new component owner.

Comment 29

[jag (Peter Annema)]

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

Comment 30

[Jim Graham]

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

Comment 31

[Tobias Tinkerman]

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.

Comment 32

[James Paige]

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

Comment 33

[Michael Wardle]

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.

Comment 34

[Michael Wardle]

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?

Comment 35

[Jason Bassford]

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

Comment 36

[Peter Trudelle]

nsbeta1- per ADT triage team, ->1.2

Comment 37

[R.K.Aa.]

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

Comment 38

[Jim Graham]

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

Comment 39

[Hixie (not reading bugmail)]

This pref should go with the "When Navigator starts..." pref.

Comment 40

[R.K.Aa.]

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

Comment 41

[Blake Ross]

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.

Comment 42

[Peter Trudelle]

We have to be careful how this behaves when we incorporate GroupMarks into this mix.

Comment 43

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 44

[R.K.Aa.]

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

Comment 45

[HJ]

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

Comment 46

[HJ]

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

Comment 47

[Anthony DiSante]

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

Comment 48

[Jim Graham]

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.

Comment 49

[meinhard benn]

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.

Comment 50

[Daniel Veditz [:dveditz]]

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

Comment 51

[Fernando Cassia]

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

Comment 52

[khindenburg]

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.

Comment 53

[Fernando Cassia]

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]|
|                                    |
+------------------------------------+

Comment 54

[James Paige]

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.

Comment 55

[Hixie (not reading bugmail)]

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.

Comment 56

[Jody Belka]

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?

Comment 57

[alanjstr]

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

Comment 58

[jag (Peter Annema)]

Attachment: Load homepage / first page of group

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.

Comment 59

[jag (Peter Annema)]

Checked in.

Comment 60

[Pratik]

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.

Comment 61

[Jason Bassford]

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

Comment 62

[Jason Bassford]

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

Comment 63

[jag (Peter Annema)]

You're right, I screwed up. Fix coming up.

Comment 64

[jag (Peter Annema)]

Attachment: Get "page to load" from command line handler, dummy

Comment 65

[jag (Peter Annema)]

Comment on attachment 116975 [details] [diff] [review]
Get "page to load" from command line handler, dummy

Almost, but not quite.

Comment 66

[jag (Peter Annema)]

Attachment: Fix typo in above patch, split defaultArgs on \n

Comment 67

[R.K.Aa.]

This caused bug 103329 to reappear.

Comment 68

[jag (Peter Annema)]

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 69

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 116976 [details] [diff] [review]
Fix typo in above patch, split defaultArgs on \n

looks good and works right :)

Comment 70

[R.K.Aa.]

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.

Comment 71

[Jason Bassford]

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

Comment 72

[jag (Peter Annema)]

Ah!

Let me see if I can fix that over in bug 103329 then.

Comment 73

[jag (Peter Annema)]

Marking fixed again. Patch coming up in bug 103329 for the "" vs. "about:blank"
issue.

Comment 74

[Jason Bassford]

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.

Comment 75

[Ian Neal]

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

Comment 76

[R.K.Aa.]

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.

Comment 77

[Jason Bassford]

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

Comment 78

[R.K.Aa.]

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.

Comment 79

[James Paige]

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

Comment 80

[jag (Peter Annema)]

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.