Closed Bug 118835 Opened 22 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.2beta

People

(Reporter: kaboom, Assigned: jag+mozilla)

References

Details

(Keywords: helpwanted, Whiteboard: [adt2])

Attachments

(5 files, 5 obsolete files)

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"
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
that would be nifty!
Keywords: helpwanted
Reassigning to new component owner.
Assignee: hyatt → jaggernaut
*** Bug 134647 has been marked as a duplicate of this bug. ***
*** Bug 147067 has been marked as a duplicate of this bug. ***
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.
Summary: start up with default set of tabs → start up with default set of tabs (bookmark group as home page)
*** Bug 150310 has been marked as a duplicate of this bug. ***
*** Bug 151384 has been marked as a duplicate of this bug. ***
*** Bug 153792 has been marked as a duplicate of this bug. ***
*** Bug 117953 has been marked as a duplicate of this bug. ***
Bug 141907 presents a logical and intuitive UI for this feature.
Keywords: nsbeta1
Multizilla
http://multizilla.mozdev.org
does this already.
Should this be done again in mozilla ?
*** Bug 156407 has been marked as a duplicate of this bug. ***
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
See also bug 159357.
*** Bug 165262 has been marked as a duplicate of this bug. ***
is any work being done on this?
QA Contact: sairuh → claudius
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.
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.
QA Contact: claudius → tpreston
With this patch nothing really changes for a single url homepage. For multi url
homepages we do the tab adding thing. Next up, prefs.
Attachment #100243 - Attachment is obsolete: true
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
Attachment #100547 - Flags: superreview+
Attached patch 1.0 branch patch (obsolete) — Splinter Review
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.
Attached patch 1.0 branch patch, for real now (obsolete) — Splinter Review
The previous one wasn't the 1.0 branch patch (oops).
Attachment #100948 - Attachment is obsolete: true
Attachment #101105 - Attachment is obsolete: true
Comment on attachment 101152 [details] [diff] [review]
branch 1.0 patch: s/init23/init/g and remove the event param from locationInputHandler

sr=bryner
Attachment #101152 - Flags: superreview+
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.
Attachment #101152 - Flags: review+
Keywords: adt1.0.2
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
Attachment #101177 - Flags: superreview+
Attachment #101177 - Flags: review+
Approved to land directly on the branch by dveditz and Michael.
Keywords: adt1.0.2adt1.0.2+
talked to gayatri - private build passed all tests.
Checkins to the Mozilla 1.0 branch still require approval from drivers@mozilla.org. 

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 drivers@mozilla.org have added that information to the bug?
Thanks.
asa, sorry about unclear language-what I was trying to convey was adt approval
only.  drivers, can we get approval on this?  
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:drivers@mozilla.org?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.
Keywords: mozilla1.0.2
Attached patch Trunk patchSplinter Review
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*).
Attachment #100547 - Attachment is obsolete: true
Comment on attachment 101548 [details] [diff] [review]
Trunk patch

sr=me
Attachment #101548 - Flags: superreview+
Comment on attachment 101548 [details] [diff] [review]
Trunk patch

r=law
Attachment #101548 - Flags: review+
Checked in last night.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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)
Status: RESOLVED → VERIFIED
Odd, I just tested build 2002100403 on my Mac (10.2.1) and all works well.
Actually after more testing, it seems to work just fine.
 please checkin to the MOZILLA_1_0_BRANCH branch. once there, remove the
"mozilla1.0.2+" keyword and add the "fixed1.0.2" keyword. 
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.
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.
Should this bug be marked "Reopen"?
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
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 on attachment 102072 [details] [diff] [review]
Fix composer code and stringify arguments[0]

r=brade
Attachment #102072 - Flags: review+
Is this checked into the branch? Please change the adt1.0.2+ keyword to
fixed1.0.2 if it has. 
Sorry, please ignore previous comment. I meant to say: 
Is this checked into the branch? If yes, please add keyword "fixed1.0.2".
Appears checked in -- if not please remove fixed1.0.2 and restore mozilla1.0.2+
keywords
Yeah, it's in. Thanks, I was just gonna add the keyword.
Verified Fixed Win XP branch build 2002100908, Mac OS 10.2 branch build
2002100905 and linux branch build 2002100906, adding verified1.0.2 keyword
*** Bug 173577 has been marked as a duplicate of this bug. ***
jag--did the fix for Composer also land on the branch or is it now broken there?
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
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 :-)
Target Milestone: Future → mozilla1.2beta
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.