Closed Bug 197671 Opened 17 years ago Closed 17 years ago

Separate "When Navigator starts up" from "What a new tab/window does" preferences

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: vincent-moz, Assigned: iann_bugzilla)

References

(Blocks 1 open bug)

Details

(Keywords: perf, regression, Whiteboard: [adt2]Please do not debate pros/cons of home page in new tab - focus on a preference.)

Attachments

(2 files, 17 obsolete files)

3.10 KB, patch
jag+mozilla
: superreview+
Details | Diff | Splinter Review
661 bytes, patch
jag+mozilla
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review
User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030315
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.4a) Gecko/20030315

In the past (until recently), it was possible to start Mozilla, asking to open
the home page by default, while having a blank URL when opening new tabs. Now,
this is no longer possible since new tabs now takes the "When Navigator starts
up" option for their behavior, instead of using a new option. This is an
annoying regression.

Reproducible: Always

Steps to Reproduce:
I'll confirm this.

To clarify: your summary mentions new windows, although your description only
talks about tabs.  I'm assuming that you want this to cover both new tabs AND
new windows, not just new tabs?
Status: UNCONFIRMED → NEW
Ever confirmed: true
We should at least be able to have a hidden backend pref for this without too
much trouble.  (I would think.)

Currently we have "user_pref("browser.startup.page", [1-3]);".  We could add
something like "user_pref("browser.new.page", [0-3]);" defaulting to "0" which
would have it simply follow what the startup option is currently set to.
CCing jag due to his work on the existing tabbed browsing portion from bug 109551.
Er - this is actually an enhancement request.  (Nothing's actually broken here.)
Severity: normal → enhancement
Yes, I strongly support either reverting opening new tabs to the previous
(blank) behavior, or adding some form of preference as described in this bug.

Until the (in my eyes) ill-conceived fix for bug 109551 went in, I had set my
home page to my favorite news page. At the beinning of my day, I started up my
browser, and had my regular news fix served up for me.
I read the news, and went about my business, sometimes opening new tabs, to do
new  tasks.

The problem is that the news site is moderately complex, and takes some time to
render, sometimes even blocking the UI for a second or so - no desaster, but *
very* annoying when this happens with *each and every* new tab I open; even more
so when the content displayed in the new tab is by now completely irrelevant,
since I have already read it.

To make matters worse, on my home machine, I have a demand-dialling internet
connection. I use mozilla both to browse the internet and to browse local
programming reference. Until recently, I had a homepage defined, and I could use
'New Tab' to access local documentation. Now, every time I open a new tab, my
(external) home page got called, and initiated a demand dialup.

In both cases (home and office), the 'fix' for bug 109551 lead to me moving to
an empty home page. Effectively, the fix for something I didn't percieve as a
bug took away a useful feature, namely the ability to define a homepage. The
loss is small (I now have to press a button in my personal toolbar right after
startup), but it is still a small loss of efficiency.

To me, it seems like having new tabs open the homepage takes care of a *very*
specialized use case, where somebody does the majority of their browsing from
one special location, which is defined as the homepage. How common is this
scenario? For me, I basically never happens. In my eyes, unless there is some
study proving that this use case is by far the most common, the situation where
taking care of specialized needs makes using a generally accepted and used
feature much more cumbersome calls for a preference. 

Which of the two behaviors is to be the default is a difficult design decision,
which will probably generate some debate anyway; but I strongly believe there
should be at least a hidden preference to restore the old behavior.
Christian: Here's a workaround for your current problem (at least until this can
be sorted out).

Modify the shortcut you use to launch Mozilla by appending the name of your home
page.  (E.g. "mozilla myhomepage.com") That way, Mozilla will always launch with
your home page loaded when you run it.  Now tell Mozilla, in the preferences, to
startup with a blank page.  In this way, you'll always go to your home page on
startup (the command line will override the startup option), the home page
button will take you to your home page, but new tabs will be blank as before.
Re comment #1, I spoke about new tabs because this is what I use, but I think we
should have the same behavior for new windows (as far as I'm concerned, I don't
need separate options for new tabs and new windows, but I don't know if other
users would need that).

Re comment #4, the existing independence between startup and new tabs has been
broken by bug 109551 fix, that's why I filled this bug as a normal bug.
the wording is currently wrong ("When Navigator starts up display").
Netscape 4.7x loads also the homepage if you open a new window and the wording
there is "When Navigator starts".

The current solution is NOT broken, it's expected and there should not be a
difference between a NEW Tab and a NEW Window. (it was broken before this bug
got fixed)

We need either a chechbox with "load Homepage in new browser windows" (windows
should also apply to Tabs) or change the current wording (and mark the checkbox
solution wontfix or add a hidden pref for that).

There is also a workaround/solution :
set "when Navigator starts up" to blank and load Mozilla with 
"mozilla http://homepage.com" and you get exactly what you want.

-> XP APPS because preferences is wrong for the panels itself
Assignee: ben → jaggernaut
Component: Preferences → XP Apps
QA Contact: sairuh → paw
> Netscape 4.7x loads also the homepage if you open a new window and the
> wording there is "When Navigator starts".

We're not filing a bug for 4.7 - we're talking about the latest Mozilla trunk
build which does use the current wording under Preferences -> Navigator.  Unless
I'm missing something.

Noboby's arguing that new tab and new window should behave different.  Only that
what happens at *startup* should be able to be different than either a new tab
or a new window (which would both be the same).  As for the "it's broken" issue
- it's by design by the module owner so, by definition, it can't be broken.

> We need either a chechbox with "load Homepage in new browser windows"

Ack, no.  What's the point?  New tabs and new windows should do the same thing.
 If you *really* want them to behave differently (although I think that would
introduce far too much complexity and would really not be worthwhile), you can
file yet another bug.  But this one is only about separating startup behaviour
from the rest.
>New tabs and new windows should do the same thing.

Yes, that's the point. I mean that this checkbox should also affect a new Tab.
(And I agree that we should have such a pref !)
I killed bug "197610" because it's no bug. Jag fixed the unequal behaviour between 
a new Tab and a new window.
This is ridiculous. A pref was what bug 109551 was all about. It simply isn't
fixed. This shouldn't be an RFE. It is bad user interface, and even worse when
the pref says one thing and does another: It should open homepage on startup,
not on new tab.
Concerning the proposed workaround, I start Mozilla in various ways (either via
the command line or the window manager...), and as my home page sometimes
changes, this makes things tedious. So, a preference in Mozilla (that could be
put in my user.js and thus would be global) would really be useful.
> as my home page sometimes changes, this makes things tedious.

Vincent: Try this further workaround.  Set your shortcut to the following:

mozilla.exe javascript:home()

This will load Mozilla with whatever your Home page of the moment happens to be.
 (Note: This does not work if you have a tab group defined as your home page -
see bug 172657.)

> A pref was what bug 109551 was all about.

Bug 109551 was about changing the behaviour of new tabs so that they were not
hardcoded to do something.  There were various resolutions proposed, and one of
them was decided on.  Perhaps the summary should have been changed, but new tabs
are now no longer hardcoded but are based on other settings that you have.  

There are interim workarounds, already discussed here, to get back to the old
behaviour until this bug can be resolved.  (Which, so far, nobody here has been
arguing against.)

> This shouldn't be an RFE.

Current behaviour is as intended and "by design" per the module owner.  You
personally may not like it, but in Bugzilla terms any change to intended
behaviour is an RFE.
Bug 109551 was spun off from bug 105589 where Hyatt, the original module owner,
writes:

"I don't believe tabs should ever load the home page"

Summary of bug 109551 still reads "prefs to show home/current/blank page in new
tab". Similar requests are in several of the duplicates.

This isn't the only sample of tabbed browsing being slowly broken:
See bug 103354 and spinoffs for further samples of whimsical treatment of
features in what might be THE most vital lead Mozilla has on MSIE.

Seems to me that development of the tabbed browser has lost all direction.
I can't make myself believe this is done on purpose.
Keywords: perf, regression
QA Contact: paw → sairuh
Jason: I'm not under Windows. I sometimes start Mozilla from the command line,
sometimes with a relative path (I sometimes have several versions installed on
my machine). Moreover, will javascript:home() work if JavaScript is disabled?
> I sometimes start Mozilla from the command line, sometimes with a relative
> path

You could rename the Mozilla executable and drop in a script with the original
name that calls the new file with the startup page - in each instance.

> will javascript:home() work if JavaScript is disabled?

No.  And I don't know how to enable it only for localhost (or that one function).

Sorry, there's a point at which workarounds don't cover all circumstances. 
Obviously, nobody disagrees that the best solution here is to just resolve this
bug somehow...
I have to agree: this issue has not been resolved by the patch for bug 109551.  

The important thing here is making the tabbed browsing experience as smooth as
possible for as many people as possible.  Making new tabs behave identically to
a new window will satisfy some people, but not others.  There are good reasons
for wanting to make them behave differently.  The example in comment #5 is one;
my own case is another.  My homepage is set to a file on my hard drive that
contains links to the sites I visit most frequently.  When new tabs auto-opened
to about:blank, I always had to hit the Home button before I could continue
working, which was terribly annoying.  The slow-to-load news site example works
the other way, but the effect is the same: reduced efficiency and a higher
annoyance coefficient.

Face it: different people have different usage patterns, and the only way to
well and truly solve this issue is to make it configurable.  Ideally this would
appear in the prefs panel.

And just to head off the inevitable complaints about bloat, this is not bloat,
it's the cure to it.  This is merely offering a reasonable level of personalized
control over an existing feature.  Imho, offering control over an existing
feature is *never* bloat.  Having features without offering control over them
*is* bloat.  (Which, on a side note, is my personal peeve against Phoenix: there
is a LOT of functionality that they have but don't offer easy control over.)
*** Bug 198084 has been marked as a duplicate of this bug. ***
*** Bug 198143 has been marked as a duplicate of this bug. ***
This makes opening a new tab a pain for a lot of people.  Is this really of
"enhancement" severity, since it is a regression?  Wouldn't "trivial or higher
be more suited, at a minimum?  Voting for this bug...
I also find the behaviour of new tabs opening a homepage very annoying. Yes, the
workaround fixes it (for me and my usage pattern) but in my view the previous
behaviour should be restored and when the mechanism is in place for separating
start-up from new tab  behaviour that blank url should be the default for new
tabs. Voting ...
> Is this really of "enhancement" severity, since it is a regression?

Yes.  There is no such thing as "enhancement severity" - an enhancement request
is not the same thing as an indication of severity.  You can have an enhancement
request that's a "major" bug - but still be an enhancement.  (See bug 9412 on
changing this state of affairs.)

The correct way of indicating severity on an enhancement request is not to
change it from "enhancement" but to set the priority flag.  (Eg. P1, P2, etc.,
where the lower that value the more important it is.)  However, I believe that
only the person to whom the bug is assigned is supposed to do that, so please
don't rush off to set this bug's "P" level...
IMO we're talking about three different things here. The current pref says "When
Navigator starts up display...", this is not the same as "When opening a new
window display..." or even "When opening a new tab display...". These are three
different things and if done properly should have three different settings.
People use their browsers in different ways. Personally I don't know why I would
need a new window to open my home page. And I definitely don't want my tabs to
do it. I open new tabs and windows to enter an URL by hand; if I want to load my
home page I can hit the proper button. I hardly ever open a new page, but I'm
sure people who do it, have them for the different uses than tabs. So again: we
need three options for this: one which definies what happens at startup, one
which defines the beviour for opening new windows, and one for new tabs.
*** Bug 200276 has been marked as a duplicate of this bug. ***
Since I like the behaviour of opening a blank tab better than loading some page
and I noticed this has changed in version 1.4a for Linux, I filed a bug (bug
200276) and was redirected to this bug report. Reading all the patches and
comments here I was able to produce a fix that

1) will just start mozilla with a page of my choice just giving the mozilla
command, without any command line options
2) will open a blank page when pressing Control-T, or selecting File->New->Tab
3) will still open a page when using the middle mouse button on a link or typing
it in the location bar and hitting Control-Enter.

This is how to do it :

- create a backup of comm.jar
- unjar is and edit the file content/navigator/navigator.js
- in the function BrowserOpenTab, uncomment (or remove) the lines that say

    var uriToLoad = handler.defaultArgs.split("\n")[0];
    if (/^\s*$/.test(uriToLoad))

- create a new jar archive called comm.jar from the content subdirectory and
(re)start mozilla.

I'm not sure, however, if this will introduce any errors, but so far it seems to
work fine.
> will open a blank page when pressing Control-T

Remember that any actual patch to this bug will not be something that forces a
blank page with a new tab but one that let's the user choose what will happen
with a new tab.
> Remember that any actual patch to this bug will not be something that forces a
> blank page with a new tab but one that let's the user choose what will happen
> with a new tab.

Sure. I never claimed it was a patch. It's only another workaround for people
who don't like the other presented workarounds. But I would appreciate a
permanent fix like that much.
I for one LOVED the way opening tabs was behaving before it got "fixed".

I personally also - both, at home and at wotk hav a news site set up as my home
page.  When I open new windows or tabs - I do this only to open some bookmark or
enter new url for this tab (or if I want some external program to open a link in
a new tab)  In any case - loading the page that was set up as my home page,
every time I open new tabs, is overkill, scince only time I might actually be
interested in the cntent of thet page is when I first start up my browser. Rest
of the time it's for new content...

Anyway - scince hardcoded about:blank is also bad (for all the reasons in
Comment #17), I propose an additional pref for opening new tabs/windows:
1 - about:blank
2 - default homepage
3 - custom page.

Anyway - Im voting for this bug....
*** Bug 200390 has been marked as a duplicate of this bug. ***
*** Bug 200400 has been marked as a duplicate of this bug. ***
I've been dealing with this bad loading home page in new tabs **** for a few
days now and you know what I found it has led to? I'm using Safari more. Well
Safari build v62 (the first build with tabs) anyway. Seriously this has got to
stop before I murder someone. Please make it go back to the old behaviour of
Cmd+T dropping you in a freshly blank tab with the cursor in the location bar.
If I wanted to see my home page again, I would either click the home button in
the toolbar, or I would hit Cmd+W and open a new window. Anyone know what the
last nightly was before this braindead behaviour began so I can use that build?
Otherwise I guess I'll go back to 1.3.

Someone should request that this blocks 1.4b.
I agree with comment #31.  
It is almost unbearable, especially in Unix/Linux since copy/paste functions are
sensitive to highlighting text.

One way of opening the home page in a new tab is to drag the home link from the
personal toolbar to the new tab button.
A second way is to add the same context menu of a link on a web page to the
location bar URL icon when it is right clicked.
Or add a pref.  This should be fixed as soon as possible.

Reads from prefs to find out what to load in new tab.

Uses two new prefs - browser.tabs.startup.homepage and
browser.tabs.startup.page (these are the same names as the equivalent
browser.startup prefs, for consistency).

browser.tabs.startup.page takes the following values:

0 - Load tab with blank page
1 - Load tab with default homepage
2 - Load tab with last page visited
3 - Load tab with value of browser.tabs.startup.homepage

Note that you will need to add these prefs manually at present, otherwise
opening new tabs will break [getCharPref() and getIntPref() seem to throw
exceptions if the relevant pref doesn't exist). This patch isn't ready to be
checked in for this reason - does anyone know where I need to add new prefs?
Thank you, Chris, for submitting a patch!

One note: This bug is actually not *just* about new tabs, but also about new
windows.  (The summary reads "new tab/window".) While Navigator may start with
your home page, if you want new blank tabs for reasons of bandwidth, it's also
assuming here that when you open a new window it, too, should be blank.

Additionally, I think that using "start" in your preference name would cause
more confusion over how Navigator "starts" and what "new" tabs/windows should do.

Lastly, I don't think that we (at the moment) want to deal with the added
complication of having new tabs/windows do something *different* than opening as
blank, home, or last page as already defined.

For all of the above, I believe you should consider just a single preference
that's renamed to "browser.new.page" that does the following:

0 - Load new tab/window with blank page
1 - Load new tab/window with default homepage
2 - Load new tab/window tab with last page visited
Why can't it just go back to the old behaviour that we've had for the last year
and a half?

* New windows do whatever you have configured in the "When Navigator starts up,
  display" preferences.
* New tabs open blank page with cursor in location bar.

Please just return it back to the old behaviour. Go ahead and create prefs to do
whatever mind-numbing config bloat that 1% of the population wants, but please
just put the defaults back the way they were.
> Why can't it just go back to the old behaviour that we've had for the last year
> and a half?
> 
> * New windows do whatever you have configured in the "When Navigator starts up,
>   display" preferences.
> * New tabs open blank page with cursor in location bar.

Perhaps you don't remember, but originally new tabs did the same thing as new
windows.

Then somebody changed new tabs to open a blank page.  This caused a whole slew
of bugs to be filed, including ones where people said "Why can't it just go back
to the old behaviour?".

So obviously, to make everybody happy, this needs to be configurable.  And I
personally believe that either all three events (first window, new window,
new tab) should each have their own setting, or that new windows and new tabs
should behave the same way.
Re comment #33 and comment #34, I don't know if we should have different options
for new tabs and new windows, but some users may want them to behave differently
(see comment #17). But an important point is that we should have only one
homepage, otherwise this would be very confusing. So, a pref
browser.tabs.startup.homepage would be a bad idea.
> I don't know if we should have different options for new tabs and new windows

My feeling is that we should do whatever will generate a patch to address this
bug as quickly as possible (if we try to come up with something that handles the
two separately it will just take that much longer to resolve) - the easiest is
to combine the two components right now then deal with any possible separation
in a different bug.

(On a purely *personal* note, I should perhaps mention that I'm perfectly happy
with things as they stand now.  I actually prefer to have my home page appear in
all new tabs and windows.  I've also seen other people request the current
behaviour before things got "fixed", so I know I'm not alone.  It's only those
who don't like things that are the most vocal.  However, I recognize the
difficulty that this is causing for other people, and it's no better simply
replacing one group of unhappy people with another.  So, in order to make sure
that nobody is unhappy we really do need to make this a matter of user choice.)
I realize that different people have different behaviours but the current
behaviour really seems not logical to me. I start a browser once per session, so
the loading of the startup page is a "once a session action"; on the other hand
I open a lot of tabs and windows many times during one browser session, these
are repeated actions. It really makes no sense to force the same behaviour on
completely different things, it doesn't follow any logic. To me that's almost
like showing a splash screen every time I open a new window.
People, please let's not debate this issue.  It will only take away from a
resolution that *everybody* can be happy with.  Let's work on fixing this bug
and getting a preference in place.
Whiteboard: Please do not debate pros/cons of home page in new tab - focus on a preference.
navtriage: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: Please do not debate pros/cons of home page in new tab - focus on a preference. → [adt2]Please do not debate pros/cons of home page in new tab - focus on a preference.
Updated version of Chris's patch with only one new pref now "browser.tabs.page"
and only 3 options after removing the custom page load. Also added missing ; to
case 1's break.
Two more patches to come to add new pref to preferences UI.
Attachment #119448 - Attachment is obsolete: true
This is the first of 2 patches to add new pref to preferences UI for en-US
locale. I presume other versions of this file would need to be created for
other locales
This is the second of 2 patches to add new pref to preferences UI.

These three patches have not been tested by myself so I'm hoping someone can
look at them, test them if they look safe and report back here. Treat me
kindly!
Attached file Counter-proposal for UI (obsolete) —
Here's a counter-proposal for the UI to implement those new prefs.  I've never
submitted any XUL to bugzilla before, so there's some submission protocol I'm
missing, I apologize in advance.  This attachment is a full copy of the
modified pref-navigator.xul from my comm.jar.  I haven't written any of the
JavaScript to implement new functionality -- it works just like before, only
there's a new drop-box that doesn't do anything.  Also, the XUL is a bit rough
-- I haven't declared entities for the caption/label strings, which are
currently hard-coded and shouldn't be.	But it's just a mock-up, after all. 
I'll post a PNG in a minute for those who don't want to muck about with their
comm.jar but want to see it.
Attached image Screenshot of previously proposed UI (obsolete) —
The promised screenshot.
Oh heck.  I've just looked at Ian's patch, and the UI is basically identical to
the one I proposed.  Guess great minds think alike.  Sorry for the extra email! :-/
Comment on attachment 119501 [details] [diff] [review]
Revised navigator.js with only 3 options instead of 4

r=me if:

1)  You put add a try/catch around the getIntPref() call and default to
something sane if it fails.

2)  You give this a better pref name than browser.tabs.page.

3)  You get sr from jag on all this stuff.
Attachment #119501 - Flags: review+
Comment on attachment 119502 [details] [diff] [review]
Add new pref to preferences UI part 1

r=me if you change the "When Navigator starts up, display" text to something
that would make sense in this context.
Attachment #119502 - Flags: review+
Comment on attachment 119503 [details] [diff] [review]
Add new pref to preferences UI part 2

r=me.

Oh, and next time just diff from xpfe/ or from toplevel and make a single patch
file, ok?  ;)
Attachment #119503 - Flags: review+
pref is now called browser.tabs.loadOnNewTab and added patch to all.js, on bz's
suggestion, to add a default of 0 (load blank page) plus comments to explain
what each value does.
Attachment #119501 - Attachment is obsolete: true
Attachment #119502 - Attachment is obsolete: true
Attachment #119503 - Attachment is obsolete: true
Attachment #119509 - Attachment is obsolete: true
Attachment #119510 - Attachment is obsolete: true
Attachment #119517 - Flags: review?(bzbarsky)
Comment on attachment 119517 [details] [diff] [review]
Combined patch taking on-board bz's comments

+ // lets new tab load some different than new window

"something different than first window" you mean?

Also, you may want to move |var uriToLoad;| outside the try block; while what
you have is valid JS, it looks funny. 

jag?  Thoughts?
Attachment #119517 - Flags: superreview?(jaggernaut)
Attachment #119517 - Flags: review+
Attached patch Patch v1.2 (obsolete) — Splinter Review
Moved var uriToLoad; out of try bloack and tweaked comment in all.js as per
comment #52
Attachment #119517 - Attachment is obsolete: true
Attachment #119519 - Flags: superreview?(jaggernaut)
Attachment #119519 - Flags: review?(bzbarsky)
Attachment #119517 - Flags: superreview?(jaggernaut)
Attachment #119517 - Flags: review?(bzbarsky)
Comment on attachment 119519 [details] [diff] [review]
Patch v1.2

"something", not "some".  No need for a new patch; whoever checks in should
just fix that....
Attachment #119519 - Flags: review?(bzbarsky) → review+
For people who hate the current behaviour as much as I do, the Tabbrowser
extension (http://white.sakura.ne.jp/~piro/xul/_tabextensions.html) allows to
fix the current behaviour. With it you can define, in a very detailled way, how
tabs newly opened should behave.
Status: NEW → ASSIGNED
Hmmm, really assigning it to myself now
Assignee: jaggernaut → ian
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Re: Comment 42 (Removal of fourth option)

After patching my own installation, I actually quickly grew to really like the 
ability to have separate settings for my homepage and for new tabs. I have a 
fairly complicated homepage that takes a few seconds to render, so for obvious 
reasons I don't want to have that load every time I open a new tab (that's why 
I patched it, it was driving me insane!)... but I quite like the idea of having 
Google open up automatically in new tabs. This is usually why I open new tabs 
anyway - to search for something.

Would it be possible to reinstate the "fourth option", even without any UI? It 
seems to me to be useful functionality.

I also agree with comment #35 that new windows should just obey the "when 
navigator starts up, display" option. Anything else just seems unnecessary.
Attached patch Patch v1.3 (obsolete) — Splinter Review
Updated patch with following fixes:
- typo mentioned in comment #54
- new part of UI no longer expands to fill whole of pref window
- last page visited option now works, did not before because pref
browser.history.last_page_visited has been removed
Attachment #119519 - Attachment is obsolete: true
Attachment #119627 - Flags: superreview?(jaggernaut)
Attachment #119627 - Flags: review?(bzbarsky)
Blocks: 200956
Re: Comment #57

This patch does mean that new windows obey the "When Navigator starts up,
display" preference and that new tabs obey the new "When new Tab is created,
display" preference. I've tried to mirror the options exactly that is why there
is no custom page option. I've spun off the adding the custom page option as a
separate enhancement bug (bug 200956) which could be looked at once this fix
gets checked in.
Note: It wasn't/isn't the intent of this bug to have new windows behave the same
as navigator startup.  (For all of the reasons that new tabs shouldn't.) 
Separating tabs will be fine for a partial fix, but (unless the reporter
disagrees) this bug should remain open after such a patch is checked in so that
new windows either mirror new tabs or another set of preferences is also checked
in for them.
I'm now working on the new window behaviour side of this patch. I do have a
working patch that makes use of the tab behaviour preference but I would like
the behaviours to be separate. This leads to the question what should the
preference be called and where in the pref UI should it sit.
One possible name for the pref is browser.windows.loadOnNewWindow (which follows
the tabs pref browser.tabs.loadOnNewTab) or just have browser.loadOnNewWindow
As far as the pref UI, it either needs to sit at the root of the navigator menu
or have a new submenu created for it. I'll upload a screen shot of the former in
a while.
Attached patch Patch v1.4 (obsolete) — Splinter Review
This patch adds a, currently hidden, pref "browser.windows.loadOnNewWindow".
When a new browser window is created from an already open browser window, the
behaviour followed is determined by this new pref.
0 - Blank Page
1 - Home Page (default)
2 - Last Page Visisted
Attachment #119627 - Attachment is obsolete: true
Ian: perhaps the following would be more useful?

-1 - Use "Navigator Startup" pref (default)
0 - Blank Page
1 - Home Page
2 - Last Page Visisted
Great work, Ian!  You're doing a good job with all of this.

(R.e. the "-1" for the same as Navigator startup.  I'm not sure if we need this,
but if it's implemented for new windows, it should also be implemented for new
tabs.)
With all these extra prefs it's pointing towards having a new submenu off the
navigator menu and putting both the new tab and new window behaviour choices
inthere. I can't immediately think of a name for the new submenu.
Just a word of caution.. you may want to float such a proposal by the UI owner
-- I suspect it will not pass muster.
If UI approval isn't forthcoming, how about just getting the backend prefs in
place for now and then work on hammering out and hooking up UI afterwards in a
different bug?
Might be a thought....

Again, my comments are just my comments, not policy or anything.  ;)
Re comment #67: I blieve splitting the UI part off of this bug is a *very* good
idea - UI discussions tend to be longish and complicated. Getting the backend
preferences checked in will avoid a lot of frustration when the whole checkin is
held up by discussions on UI aspects.

Additionally, we're in a period of release freeze. The longer the whole thing
takes to get checked in, the slimmer the chances will be, since tree control
will be tighter and people will be even less ready to make UI changes.
Blocks: 201177
What I propose to do then is add the extra backend stuff for the -1 option for
both tabs and windows, add the extra radio button in the UI for the tabs -1
option and see if I can get those fixes checked in. I've spun off the further UI
discussion into bug 201177 to discuss later.

Is it worth renumbering the options so:
0 - Use Navigator Startup Preference
1 - Blank Page
2 - Home Page
3 - Last Visisted Page

?
FWIW, I prefer the 0-4 numbering.
Attached patch Patch v1.5 (obsolete) — Splinter Review
Renumbered Options and added new Option 0 (set as default) which makes the new
tab/window behaviour same as navigator startup behaviour. Any comments back on
naming of radio button and what the default setting for behaviour should be is
welcome (as well as any other constructive feedback). It still needs testing
though.
Attachment #119695 - Attachment is obsolete: true
I would set the default behaviour for new tabs and new windows to be blank
(value=1) since this uses the least bandwidth and will cause the least
inconvenience to dial-up users.
> +     <radio value="0" label="&startupTabRadio.label;"
        accesskey="&blankTabRadio.accesskey;"/>

Is this correct?  Shouldn't the accesskey="&startupTabRadio.accesskey"?
Attached patch Patch v1.5a (obsolete) — Splinter Review
Same as patch v1.5 except without pref UI part of it, this has been spun off
into patch for bug 201177 (version 1.0a which includes the typo caught by
Jason)
Attachment #119816 - Attachment is obsolete: true
Attached patch Patch v1.5b (obsolete) — Splinter Review
Default option for new window/tab is now set to 1 - blank page
Attachment #119821 - Attachment is obsolete: true
Attachment #119905 - Flags: superreview?(jaggernaut)
Attachment #119905 - Flags: review?(bzbarsky)
I'd rather keep the pref values in sync with the startup ones. Stick to -1 to indicate "do whatever we do for startup".Instead of getting the current url from getWebNavigation() (which would fail for opening a new nav window from mail/news), do what's done in http://lxr.mozilla.org/seamonkey/source/xpfe/browser/src/nsBrowserInstance.cpp#793 (get the history service and ask it).I think the code might be a little clearer when you move |startpage = handler.defaultArgs;| inside the switch (but keep the |var startpage| where it is).My apologies for not speaking up sooner.
Sigh. Either certain browsers out there need to fix their textarea wrapping
before they submit, or bugzilla needs to be fixed. Once more, better laid out:

I'd rather keep the pref values in sync with the startup ones. Stick to -1 to
indicate "do whatever we do for startup".

Instead of getting the current url from getWebNavigation() (which would fail for
opening a new nav window from mail/news), do what's done in
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/src/nsBrowserInstance.cpp#793
(get the history service and ask it).

I think the code might be a little clearer when you move |startpage =
handler.defaultArgs;| inside the switch (but keep the |var startpage| where it is).

My apologies for not speaking up sooner.
Oh, and I agree with comment 73
I'm now looking at doing:

var globalHistory = Components.classes["@mozilla.org/browser/global-history;1"]
                    .getService(Components.interfaces.nsIBrowserHistory);
startpage = globalHistory.lastPageVisited;

but as far as I can see it always returns null, any ideas?
Ah, it's because we don't store the last page visited unless the browser startup
pref is set to 2; see nsGlobalHistory::AddPage. See the blame for those lines.
Fix seems easy enough.
Would an alternative way of fixing it be, going back to using
getWebNavigation().currentURI.spec and make it so calling up a New Window from
mail/news doesn't touch the new code which is what I was originally intending to do?
In fact my patch 1.5b is working how I originally intended it to work in that I
wanted a New Window from mail/news to have the behaviour of Navigator startup.
My interpretation of the original "When Navigator starts up, display" preference
was it determined the behaviour the first time a browser window is created,
either by starting Navigator or starting another component and then bringing up
a browser window.
Attachment #119519 - Flags: superreview?(jaggernaut)
Attachment #119627 - Flags: superreview?(jaggernaut)
Attachment #119627 - Flags: review?(bzbarsky)
Attached patch Patch v1.6 (obsolete) — Splinter Review
Updated patch to reflect jag's comments about moving |startpage =
handler.defaultArgs;| inside the switch and the fact navigator.js is now at
1.499
Left getWebNavigation().currentURI.spec as it was (see comment #83)
Will be attaching an updated patch to bug 201177 which will work with this
patch.
Attachment #119905 - Attachment is obsolete: true
Attachment #119905 - Flags: superreview?(jaggernaut)
Attachment #119905 - Flags: review?(bzbarsky)
Attachment #120119 - Flags: superreview?(jaggernaut)
Attachment #120119 - Flags: review?(bzbarsky)
bz/jag review? comments?
Comment on attachment 120119 [details] [diff] [review]
Patch v1.6

sr=jag. Just wondering now if we could refactor this code to share the switch.
Attachment #120119 - Flags: superreview?(jaggernaut) → superreview+
jag: unlikely, because (unlike new tab) new window wants to open all home tabs.
For the purposes of this comment if we assume that the home page is set to a
group and that all prefs are set to home page (both prior to and after this patch).

This patch does change the behaviour of New Window (Ctrl-N) from an existing
browser window. Prior to this patch it would open the whole group, after this
patch it would behave similarly to New Tab (Ctrl-T) and just open the first page
of the group.

Is this change to its behaviour acceptable? The old behaviour can still be made
to happen by setting the New Window behaviour pref to be Navigator startup page.
My personal opinion is to lean slightly in favour of opening all tabs in a tab
group in a new window, if the it's set to go to home and home is such a group. 
Otherwise it's slightly misleading.  Also some people <sigh> might want a new
navigator session to do something other than go to their home page, but still
have new windows go to their home page...

Having said that, I don't really think it's a big deal.
It should open the group of tabs.
I'm running today's build.  It has regressed horribly, on account of my home
page showing up in new tabs.  This needs to be fixed for 1.4b.

/be
Flags: blocking1.4b?
Flags: blocking1.4b? → blocking1.4b+
Attached patch Patch v1.6a (obsolete) — Splinter Review
New Window when set to home page now displays home page group if there is one.
Attachment #120119 - Attachment is obsolete: true
Comment on attachment 120258 [details] [diff] [review]
Patch v1.6a

Requesting review and superreview
Attachment #120258 - Flags: superreview?(jaggernaut)
Attachment #120258 - Flags: review?(bzbarsky)
I will not be able to get to this until at least Monday afternoon.... I'll try
then, but no guarantees -- the real world is catching up with me.
Adding some XP-Apps peers that might want to comment/review this patch and the
one to bug 201177
*** Bug 201915 has been marked as a duplicate of this bug. ***
Comment on attachment 120119 [details] [diff] [review]
Patch v1.6

Consider changing if (/^\s*$/.test(uriToLoad))
to if (!/\S/.test(uriToLoad))
Attachment #120119 - Flags: review?(bzbarsky) → review+
Attached patch Patch v1.6bSplinter Review
As v1.6a but with (!/\S/.test(uriToLoad)) as suggested by Neil in bug
103329c#19 and Timeless
Attachment #120258 - Attachment is obsolete: true
Comment on attachment 120258 [details] [diff] [review]
Patch v1.6a

Cancelling old r/sr requests
Attachment #120258 - Flags: superreview?(jaggernaut)
Attachment #120258 - Flags: review?(bzbarsky)
Comment on attachment 120517 [details] [diff] [review]
Patch v1.6b

Requesting formal r=/sr= and then can someone check it in?
Attachment #120517 - Flags: superreview?(jaggernaut)
Attachment #120517 - Flags: review?(timeless)
Comment on attachment 120517 [details] [diff] [review]
Patch v1.6b

sr=jag
Attachment #120517 - Flags: superreview+
i know that the frontend (bug 201177) hasn't been fixed yet, but since this was
checked in on 14-april-2003 18:49, should this be resolved now? or is there more
backend work expected here?

fwiw, this is what i see with today's (203.04.15) builds:

1. "home page" selected for "when navigator starts up" in Navigator pref panel.
i also have either a page url or a groupmark set for the home page location in
this panel (doesn't matter which).

2. quit and restart app. resulting browser page opens to the location set in (1).

3. open a new browser window via accel+N or from the main menu, File - New -
Navigator Window.

results: the new browser window is blank. is this expected with the current
state, or is it a new regression?
shouldn't the default not be changed to enabled instead of disabled ?
This is what is expected, the default setting for new window is a blank page, as
it is for new tab. It probably is best that the default settings for the two new
settings, until the pref ui bug is checked in, should be -1 which is the setting
for same behaviour as navigator startup.
Attached patch Quick Fix Patch (obsolete) — Splinter Review
Patch to set default for two new prefs to be -1 which means new tab/window
behaviour will be set to same behaviour as when navigator starts up.
Attachment #120638 - Flags: superreview?(jaggernaut)
Attachment #120638 - Flags: review?(timeless)
Attached patch Even quicker fix (obsolete) — Splinter Review
Only changes the behaviour for new window to be the same as for navigator
startup (i.e. -1 ignore new code)
Attachment #120638 - Attachment is obsolete: true
Comment on attachment 120638 [details] [diff] [review]
Quick Fix Patch

Cancelling r=/sr= requests on this patch
Attachment #120638 - Flags: superreview?(jaggernaut)
Attachment #120638 - Flags: review?(timeless)
Quick fix patch v.3 with proper diff (just for timeless)
Attachment #120640 - Attachment is obsolete: true
Comment on attachment 120642 [details] [diff] [review]
Quick Fix Patch v.3

Request for r=/sr= so it can be checked in
Attachment #120642 - Flags: superreview?(jaggernaut)
Attachment #120642 - Flags: review?(timeless)
Comment on attachment 120642 [details] [diff] [review]
Quick Fix Patch v.3

r=/sr=jag. I'll check this in.
Attachment #120642 - Flags: superreview?(jaggernaut)
Attachment #120642 - Flags: superreview+
Attachment #120642 - Flags: review?(timeless)
Attachment #120642 - Flags: review+
Marking as fixed.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
thanks, ian!

vrfy'd fixed with 2003.04.23 bits (still pending bug 2001177, o'course).
Status: RESOLVED → VERIFIED
Attachment #120517 - Flags: superreview?(jaggernaut)
Attachment #120517 - Flags: review?(timeless)
"(still pending bug 2001177, o'course)" 
Nope, make that bug 201177 :-)
*** Bug 203863 has been marked as a duplicate of this bug. ***
Strange...can't add myself (spooky130@cox.net) for CC: on this bug....

Why is this debate even going on now?  HJ fixed it back in, oh, October or
November (not sure, but it was somewhere around that time)....  The pref is
already there.  See Edit->Preferences->Multizilla->Links ... and from there,
two items:

   * Preferred location for opening new tabs (entry)
   * Use preferred location for new tabs (checkbox)

It's already fixed, and it works fine (well, except for more recent issues
with new windows opening *UNDER* the current window and with the original
startup tabset instead of the preferred location ... see bug 3673, which I
filed a few days ago).
> See Edit->Preferences->Multizilla->Links

The problem is, I don't see any "multizilla" under preferences.
That's for the multizilla addon and this is not the place to add comments about
UI things in multizilla.
Ok, I feel embarassed now....  I was reading the Multizilla list, and
ended up here somehow.  I thought I was still there.  Never mind.
*** Bug 204699 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.