118835 - start up with default set of tabs (bookmark group as home page)

Status: VERIFIED FIXED

(SeaMonkey :: Tabbed Browser, enhancement)

Description

[kaboom]

This enhancement request is similar to #102130 (and in fact, people have
requested this enhancement in the comments for that bug).  Since it seems to me
that it would be implemented rather differently, however, I'm filing it as a
separate bug.  Feel free to close it if you think it's the same bug ;-)

Mozilla currently lets you specify a Home Page.  Once you do that, Mozilla on
start up will always display that page.  I'd like to instead be able to specify
a set of tabs, each with a unique home page, that all get loaded on startup of
Mozilla.  The first thing I do whenever I start up mozilla is open up five
additional tabs, and then load the five additional pages I monitor all day long
on each of those tabs.  Bookmarking that (as #102130 ask for) would be nice, but
even nicer would be for those tabs just to be my "home page"

Comment 1

[sairuh (rarely reading bugmail)]

that would be nifty!

Comment 2

[David Hyatt]

Reassigning to new component owner.

Comment 3

[Alex Bishop]

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

Comment 4

[Jeff Tilak]

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

Comment 5

[Jeff Tilak]

The preference "When Navigator starts up, display last page visited" should
remember all tabs 
and pages (if there are multiple tabs open when Navigator
closes) and load them all next time 
Navigator starts up.

Comment 6

[Jesse Ruderman]

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

Comment 7

[Pierre Chanial]

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

Comment 8

[Blackstripe]

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

Comment 9

[timeless]

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

Comment 10

[Ian Pottinger]

Bug 141907 presents a logical and intuitive UI for this feature.

Comment 11

[Lee]

Multizilla
http://multizilla.mozdev.org
does this already.
Should this be done again in mozilla ?

Comment 12

[Alfonso Martinez]

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

Comment 13

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 14

[Anthony DeRobertis]

See also bug 159357.

Comment 15

[gavin long]

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

Comment 16

[[e-mail] (away - not reading bugmail)]

is any work being done on this?

Comment 17

[jag (Peter Annema)]

Attachment: Make browser support opening multiple homepages at startup

This patch makes the backend code support opening multiple pages (in tabs) at
startup.

It changes nsICmdLineHandler's defaultArgs property to be a nsISupports, so
I'll need to fix up some of the JS implementations of that.

Comment 18

[jag (Peter Annema)]

For the pref UI we've come up with the following: add a button "Use Current
Group" (disabled when only one tab) which will set the textfield's value to " --
{ Home Page Group is set } -- " or some such obvious non-URI.

Comment 19

[jag (Peter Annema)]

Attachment: None of that nsISupports silliness, use '\n' as a delimiter between urls in one big string

With this patch nothing really changes for a single url homepage. For multi url
homepages we do the tab adding thing. Next up, prefs.

Comment 20

[Alec Flett]

Comment on attachment 100547 [details] [diff] [review]
None of that nsISupports silliness, use '\n' as a delimiter between urls in one big string

sr=alecf

Comment 21

[jag (Peter Annema)]

Attachment: 1.0 branch patch

I'll forward this patch to the trunk soon-ish, but since we want this feature
for blackbird I need to get r=, sr= and a= on this ASAP.

Comment 22

[jag (Peter Annema)]

Attachment: 1.0 branch patch, for real now

The previous one wasn't the 1.0 branch patch (oops).

Comment 23

[jag (Peter Annema)]

Attachment: This one also remembers the value when you switch panes

Comment 24

[jag (Peter Annema)]

Attachment: branch 1.0 patch: s/init23/init/g and remove the event param from locationInputHandler

Comment 25

[Brian Ryner (not reading)]

Comment on attachment 101152 [details] [diff] [review]
branch 1.0 patch: s/init23/init/g and remove the event param from locationInputHandler

sr=bryner

Comment 26

[Bill Law]

Comment on attachment 101152 [details] [diff] [review]
branch 1.0 patch: s/init23/init/g and remove the event param from locationInputHandler

r=law

But, jag says he might combine the button-disabling logic so it is all in one
place.	This r= should carry over since that will just be re-arranging of the
same code.

Comment 27

[jag (Peter Annema)]

Attachment: update to pref-navigator.js part of above patch: Merged the Startup code with the locationInputHandler code

Comment 28

[jag (Peter Annema)]

Comment on attachment 101177 [details] [diff] [review]
update to pref-navigator.js part of above patch: Merged the Startup code with the locationInputHandler code

r=law, sr=bryner

Comment 29

[Michael Buckland]

Approved to land directly on the branch by dveditz and Michael.

Comment 30

[Michael Buckland]

talked to gayatri - private build passed all tests.

Comment 31

[Asa Dotzler [:asa]]

Checkins to the Mozilla 1.0 branch still require approval from [e-mail]. 

Michael, your comment suggests that this patch has approval to land when it
doesn't. Can you use some different language when talking about whether or not
ADT wants something so as to not confuse it with approval to land code which
doesn't exist until [e-mail] have added that information to the bug?
Thanks.

Comment 32

[Michael Buckland]

asa, sorry about unclear language-what I was trying to convey was adt approval
only.  drivers, can we get approval on this?  

Comment 33

[timeless]

can someone please explain why this feature isn't being landed on the trunk
first like all other features?  the branch is supposed to be a stable branch
which cherry picks features which have been on the trunk for at least a few
days. Being in a hurry isn't a good reason to void procedure.

as for getting approval... if you want approval from drivers then you should
send
mailto:[e-mail]?subject=[1.0%20branch%20approval]%20Bug%20118835%20start%20up%20with%20default%20set%20of%20tabs%20(bookmark%20group%20as%20home%20page)&body=Please%20approve%20attachment%20%3csome%20number%3e%20%3curl%3e%20for%201.0%20branch.%20%3cSomeone%3e%20%3cemail%3e%20wrote%20this%20patch,%20it%20has%20r=%3csomeoneelse%3e%20sr=%3csomeSR%3e.%20%3cSome%20good%20reason%20why%20this%20bug%20should%20be%20accepted%3e.%20%3cA%20risk/benefits%20assessment%3e.

Comment 34

[jag (Peter Annema)]

Attachment: Trunk patch

This moves the "Choose File..." button in the nav prefs next to the location
field to make room for the new button (*mumble* restore default *mumble*).

Comment 35

[Joe Hewitt (gone)]

Comment on attachment 101548 [details] [diff] [review]
Trunk patch

sr=me

Comment 36

[jag (Peter Annema)]

Attachment: Screenshot of the prefs panel

Comment 37

[Bill Law]

Comment on attachment 101548 [details] [diff] [review]
Trunk patch

r=law

Comment 38

[jag (Peter Annema)]

Checked in last night.

Comment 39

[Terri Preston]

Verified Mac OS X trunk build 2002100403, Win XP trunk build 2002100409 and
linux trunk build 2002100408 (only comment is that it is really slow on Mac)

Comment 40

[jag (Peter Annema)]

Odd, I just tested build 2002100403 on my Mac (10.2.1) and all works well.

Comment 41

[Terri Preston]

Actually after more testing, it seems to work just fine.

Comment 42

[Judson Valeski]

 please checkin to the MOZILLA_1_0_BRANCH branch. once there, remove the
"mozilla1.0.2+" keyword and add the "fixed1.0.2" keyword. 

Comment 43

[Kathleen :Brade]

This appears to have caused a regression in Composer.  Clicking on the Browse
icon in Composer no longer works.

I am concerned that this fix was requested for the 1.0 branch when it caused a
regression in Composer.

Comment 44

[jag (Peter Annema)]

Okay, fix is simple enough. Composer is passing in an object (location) that
happened to get stringified before, and now isn't. It should pass in
location.href (gonna do that), and I'll forcefully stringify the objects I get
as arguments[0] in navigator.js just in case someone else is doing this.

Comment 45

[Gayatri Rimola]

Should this bug be marked "Reopen"?

Comment 46

[jag (Peter Annema)]

Attachment: Fix composer code and stringify arguments[0]

Comment 47

[Terri Preston]

Actually jag said that this checkin did not cause the browse problem, a new bug
for that has been written http://bugscape.netscape.com/show_bug.cgi?id=20411

Comment 48

[jag (Peter Annema)]

Well, this checkin was the cause, but it's more like exposing a problem that
already was in the code. See bug 172716 for the follow-up on this.

Comment 49

[Kathleen :Brade]

Comment on attachment 102072 [details] [diff] [review]
Fix composer code and stringify arguments[0]

r=brade

Comment 50

[Gayatri Rimola]

Is this checked into the branch? Please change the adt1.0.2+ keyword to
fixed1.0.2 if it has. 

Comment 51

[Gayatri Rimola]

Sorry, please ignore previous comment. I meant to say: 
Is this checked into the branch? If yes, please add keyword "fixed1.0.2".

Comment 52

[Daniel Veditz [:dveditz]]

Appears checked in -- if not please remove fixed1.0.2 and restore mozilla1.0.2+
keywords

Comment 53

[jag (Peter Annema)]

Yeah, it's in. Thanks, I was just gonna add the keyword.

Comment 54

[Terri Preston]

Verified Fixed Win XP branch build 2002100908, Mac OS 10.2 branch build
2002100905 and linux branch build 2002100906, adding verified1.0.2 keyword

Comment 55

[Boris Zbarsky [:bzbarsky]]

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

Comment 56

[Kathleen :Brade]

jag--did the fix for Composer also land on the branch or is it now broken there?

Comment 57

[Fernando Cassia]

Maybe this is a stupid question... but why is the target still "future"?

Actually make that TWO stupid questions:

does the keyword "verified 1.0.2" means that the 1.0 trunk will continue to be
enhanced/fixed in parallel with 1.1x ?

If so, does this make much sense?

Regards
Fernando

Comment 58

[jag (Peter Annema)]

Three questions. Well, I just forgot to change it to the correct milestone.
1.0.2 means we're still making changes to the Mozilla 1.0 branch (the so called
stable branch, to which we back-port certain important changes), and no, it's
not stupid, think about it for a while :-)