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

VERIFIED FIXED in mozilla1.2beta

Status

SeaMonkey
Tabbed Browser
--
enhancement
VERIFIED FIXED
17 years ago
10 years ago

People

(Reporter: kaboom, Assigned: jag (Peter Annema))

Tracking

({helpwanted})

Trunk
mozilla1.2beta
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2])

Attachments

(5 attachments, 5 obsolete attachments)

17.45 KB, patch
Bill Law
: review+
Brian Ryner (not reading)
: superreview+
Details | Diff | Splinter Review
7.25 KB, patch
jag (Peter Annema)
: review+
jag (Peter Annema)
: superreview+
Details | Diff | Splinter Review
21.36 KB, patch
Bill Law
: review+
Joe Hewitt (gone)
: superreview+
Details | Diff | Splinter Review
15.30 KB, image/png
Details
1.68 KB, patch
Brade
: review+
Details | Diff | Splinter Review
(Reporter)

Description

17 years ago
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"

Updated

17 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
that would be nifty!
Keywords: helpwanted

Comment 2

17 years ago
Reassigning to new component owner.
Assignee: hyatt → jaggernaut

Comment 3

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

Updated

16 years ago
Blocks: 135915

Comment 4

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

Comment 5

16 years ago
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.

Updated

16 years ago
Summary: start up with default set of tabs → start up with default set of tabs (bookmark group as home page)

Comment 6

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

Comment 7

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

Comment 8

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

Comment 9

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

Comment 10

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

Updated

16 years ago
Keywords: nsbeta1

Comment 11

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

Comment 12

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

Comment 13

16 years ago
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]

Comment 14

16 years ago
See also bug 159357.

Comment 15

16 years ago
*** Bug 165262 has been marked as a duplicate of this bug. ***
is any work being done on this?
QA Contact: sairuh → claudius
(Assignee)

Comment 17

16 years ago
Created attachment 100243 [details] [diff] [review]
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.
(Assignee)

Comment 18

16 years ago
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.

Updated

16 years ago
QA Contact: claudius → tpreston
(Assignee)

Comment 19

16 years ago
Created attachment 100547 [details] [diff] [review]
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.
Attachment #100243 - Attachment is obsolete: true

Comment 20

16 years ago
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+
(Assignee)

Comment 21

16 years ago
Created attachment 100948 [details] [diff] [review]
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.
(Assignee)

Comment 22

16 years ago
Created attachment 101105 [details] [diff] [review]
1.0 branch patch, for real now

The previous one wasn't the 1.0 branch patch (oops).
Attachment #100948 - Attachment is obsolete: true
(Assignee)

Comment 23

16 years ago
Created attachment 101127 [details] [diff] [review]
This one also remembers the value when you switch panes
Attachment #101105 - Attachment is obsolete: true
(Assignee)

Comment 24

16 years ago
Created attachment 101152 [details] [diff] [review]
branch 1.0 patch: s/init23/init/g and remove the event param from locationInputHandler
Attachment #101127 - 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 26

16 years ago
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+
(Assignee)

Comment 27

16 years ago
Created attachment 101177 [details] [diff] [review]
update to pref-navigator.js part of above patch: Merged the Startup code with the locationInputHandler code
(Assignee)

Updated

16 years ago
Keywords: adt1.0.2
(Assignee)

Comment 28

16 years ago
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+

Comment 29

16 years ago
Approved to land directly on the branch by dveditz and Michael.
Keywords: adt1.0.2 → adt1.0.2+

Comment 30

16 years ago
talked to gayatri - private build passed all tests.

Comment 31

16 years ago
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.

Comment 32

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

Comment 33

16 years ago
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.

Updated

16 years ago
Keywords: mozilla1.0.2
(Assignee)

Comment 34

16 years ago
Created attachment 101548 [details] [diff] [review]
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*).
Attachment #100547 - Attachment is obsolete: true

Comment 35

16 years ago
Comment on attachment 101548 [details] [diff] [review]
Trunk patch

sr=me
Attachment #101548 - Flags: superreview+
(Assignee)

Comment 36

16 years ago
Created attachment 101550 [details]
Screenshot of the prefs panel

Comment 37

16 years ago
Comment on attachment 101548 [details] [diff] [review]
Trunk patch

r=law
Attachment #101548 - Flags: review+
(Assignee)

Comment 38

16 years ago
Checked in last night.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 39

16 years ago
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
(Assignee)

Comment 40

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

Comment 41

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

Comment 42

16 years ago
 please checkin to the MOZILLA_1_0_BRANCH branch. once there, remove the
"mozilla1.0.2+" keyword and add the "fixed1.0.2" keyword. 
Keywords: mozilla1.0.2 → mozilla1.0.2+

Comment 43

16 years ago
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.
(Assignee)

Comment 44

16 years ago
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

16 years ago
Should this bug be marked "Reopen"?
(Assignee)

Comment 46

16 years ago
Created attachment 102072 [details] [diff] [review]
Fix composer code and stringify arguments[0]

Comment 47

16 years ago
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
(Assignee)

Comment 48

16 years ago
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

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

r=brade
Attachment #102072 - Flags: review+

Comment 50

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

Comment 51

16 years ago
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
Keywords: mozilla1.0.2+ → fixed1.0.2
(Assignee)

Comment 53

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

Comment 54

16 years ago
Verified Fixed Win XP branch build 2002100908, Mac OS 10.2 branch build
2002100905 and linux branch build 2002100906, adding verified1.0.2 keyword
Keywords: fixed1.0.2 → verified1.0.2
*** Bug 173577 has been marked as a duplicate of this bug. ***

Comment 56

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

Comment 57

16 years ago
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
(Assignee)

Comment 58

16 years ago
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.