346044 - No simple way to set a blank page as your home page

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect)

Description

[:Gavin Sharp [email: [e-mail]]]

The "Blank page" button was removed in bug 340677. This means there's no easy way to set your homepage to a blank page, which is a functional regression from 1.5.

Comment 1

[Simon Bünzli]

Having a blank homepage doesn't make that much sense other than that it shouldn't be loaded at startup and for new windows. The latter doesn't happen anymore with bug 340898 fixed. And exposing browser.startup.page would not only be more appropriate for the former, but also nicely fix bug 342701 (allow to resume the previous session).

With that done, those people who know and care about blank pages can always open a blank tab and set the homepage to that one.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #1)
> Having a blank homepage doesn't make that much sense other than that it
> shouldn't be loaded at startup and for new windows.

That's exactly the point...

> With that done, those people who know and care about blank pages can always
> open a blank tab and set the homepage to that one.

People shouldn't have to know a special trick to get a blank page as their homepage. A blank homepage isn't some "advanced" feature, and the fact that it was possible in 1.5 and is now impossible (without knowing about about:blank) is a regression. Whether or not you like having a blank home page isn't really relevant... this was possible before, and there's no good reason to remove it.

Comment 3

[Simon Bünzli]

(In reply to comment #2)
> That's exactly the point...

... for which there exists a cleaner solution (as outlined above).

> People shouldn't have to know a special trick to get a blank page as their
> homepage.

With the above solution, the need for a blank home page is largely diminished. Furthermore, opening a new tab and setting the home page to that one is neither very tricky nor does it require any knowledge about "about:blank". Since a blank home page could now become an edge-case, having dedicated UI for it might indeed be overkill.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #3)
> With the above solution, the need for a blank home page is largely diminished.
> Furthermore, opening a new tab and setting the home page to that one is neither
> very tricky nor does it require any knowledge about "about:blank". Since a
> blank home page could now become an edge-case, having dedicated UI for it might
> indeed be overkill.

What's the "above solution"? I don't see how bug 340898 is relevant at all, and I don't see what change would make having a blank home page become an edge case.

Having to "trick" the browser into doing what you want isn't acceptable - people  shouldn't have to think of how they can fool the preferences panel into using a blank page, when previous versions have had a simple button.

Comment 5

[Simon Bünzli]

Indeed. Bug 340898 is only insofar important as it got people asking for loading the home page in new windows when browser.startup.page isn't 1.

What I'm saying: Exposing that pref and allowing to set it to 0 (blank page), 1 (homepage) and 3 (previous session) would fix the issue you mainly pointed out (startup and new windows). Have a look at Opera's options dialog for how this might look (cf. attachment 229238 [details]).

Comment 6

[Mike Connor [:mconnor]]

plussing for now, we need to make a decision on this, which might be WONTFIX

Comment 7

[Frédéric Buclin]

I think being able to set a blank page makes perfect sense for those being offline most of the time and who start their web browser before having their modem ready. So I wouldn't suggest WONTFIX, Mike.

Comment 8

[Shannon]

Attachment: Blank page options: Startup or Home Page

Comment 9

[Shannon]

Attachment: Blank page options: Startup or Home Page

Comment 10

[Jeff Walden [:Waldo]]

Slight bug hijacking: the request from feedback meetings was for clearing the textbox to set the homepage to a blank page, which would be one way to expose this.  Doing that and not interfering with the default preference mechanism, however, might be interesting.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Mike Connor and I took a while with this one, as he (and others) had to convince me that it was worth actually exposing UI for this problem. They prevailed, so we took down the following goals

 - keep the UI as lightweight as possible; we're setting homepages, not tuning warp engines, and the watch words are "easy" and "few buttons".
 - restore the UI for starting with a blank page
 - add UI for always restoring the session as per bug 342701

We decided to add the concept of "what Firefox should do when it starts up" to the prefpanel as the best way to expose this:

  Home Page _______________________________________________________________

  Location: [_____________________________________________________________]
                   ( Use Current Page ) ( Use Bookmark ) ( Restore Default)

  When Firefox starts: [ Load my home page                      |v]
                       |------------------------------------------|
                       | Show a blank page                        |
                       | Show the tabs and windows from last time |
                       '------------------------------------------'

So, basically, expose the value of browser.startup.page. I'm not 100% sure of the wording on that last option, it seems a little long. Other ideas I'd had for it were:

   * Continue from where I was last time
   * Resume my previous session
   * Show me where I was when I quit
   * Remember where I was when I quit

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: implements spec in comment 11

Here's a patch that implements the spec in comment 11.  The only difference is that I added a menuitem for browser.startup.page = 2 ("Show the last page I visited"), since otherwise the menu will incorrectly default to the first item ("Load my home page") if the user has the preference set to that value.

Nit: seems like "Load my home page" should be "Show my home page" instead if all the other options start with the word "show", no?

Along the way I also corrected some references to browserStartupHomepage which look like they should instead refer to browserHomePage.

Comment 13

[Simon Bünzli]

(In reply to comment #12)
> I added a menuitem for browser.startup.page = 2

I'd rather not. I've never seen the value in this option (except for a very cheap session resume option) and this would probably at best confuse people.

NB: People who have browser.link.open_newwindow set to 1 will get a wrong option as well. Yet it was intentionally chosen to remove/not show the UI. This case should be the same case.

> Nit: seems like "Load my home page" should be "Show my home page" instead if
> all the other options start with the word "show", no?

Why not use "Show" only in the blank page case? Otherwise this might even be intentional since the home pages are usually loaded over the net while the previous session is restored from the cache...

Finally: Why the need for the menuseparator? I doubt that Mike intended that one.

Comment 14

[Mike Connor [:mconnor]]

Myk, we really don't want to expose that pref value, since "last" is nebulous with multiple windows and tabs.  Also, I think the separator is just beltzner's shameful ASCII art.  :)

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #13)
> Finally: Why the need for the menuseparator? I doubt that Mike intended that
> one.

(In reply to comment #14)
> Also, I think the separator is just beltzner's shameful ASCII art.  :)

He probably just took into account that drop-down menus have such a "separator" on Windows, i.e. the list is automatically separated from the field. (Though, then again, "Load my home page" is missing from the list ;)

Comment 16

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #14)
> Myk, we really don't want to expose that pref value, since "last" is nebulous
> with multiple windows and tabs.  Also, I think the separator is just beltzner's
> shameful ASCII art.  :)

Ok, I'll remove the separator.  And not exposing that pref value also makes sense, if we don't think it's useful enough (which seems reasonable).  But what do we do about users who are already using it?  If there isn't an entry for it in the menu, users who have previously set the preference to "2" will see "Load my home page" selected in the menu when they open their preferences (although the preference will remain set to "2" until they select an option from the menu).

Comment 17

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v2: updated per comments

> NB: People who have browser.link.open_newwindow set to 1 will get a wrong
> option as well. Yet it was intentionally chosen to remove/not show the UI.
> This case should be the same case.

Ok, then let's do the same here.  This patch removes the "last page" menu item and the bogus separator.  Otherwise it's the same as the previous patch.

A few more options for the "restore session" wording:

Show the pages I had open last time
Show the pages that were open when I quit

Comment 18

[Mike Connor [:mconnor]]

Comment on attachment 232615 [details] [diff] [review]
patch v2: updated per comments

>+<!ENTITY startupLastPage.label     "Show the last page I visited">

we don't need the string either, otherwise r=me

formal ui-review isn't needed since you're implementing beltzner's spec, so please just get this on the trunk.

Comment 19

[Myk Melez [:myk] [@mykmelez]]

Fix checked in to trunk.

Comment 20

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch that got checked in

Here's the patch that got checked in.  Per mconnor in comment 18, I removed the startupLastPage.label entity declaration.  Also, one chunk of changes in main.xul was no longer necessary, as jwalden checked in the same fix yesterday as v1.5 of that file.

Comment 21

[Jeff Walden [:Waldo]]

Comment on attachment 232615 [details] [diff] [review]
patch v2: updated per comments

>+      <preference id="browser.startup.page"
>+                  name="browser.startup.page"
>+                  type="int"/>

Could you add some documentation to main.js explaining what this preference does and what its values are?  Preferences with UI which needs no scripting are consistently documented in this way in the panel JS files now (I need to bludgeon the non-panel JS files into shape when I have the time).

Comment 22

[Jeff Walden [:Waldo]]

Comment on attachment 232996 [details] [diff] [review]
patch that got checked in

>Index: browser/locales/en-US/chrome/browser/preferences/main.dtd

> <!ENTITY useBookmark.accesskey     "B">
> <!ENTITY restoreDefault.label      "Restore to Default">
> <!ENTITY restoreDefault.accesskey  "R">
>+<!ENTITY startup.label             "When &brandShortName; Starts:">
>+<!ENTITY startup.accesskey         "S">
>+<!ENTITY startupHomePage.label     "Load my home page">
>+<!ENTITY startupBlankPage.label    "Show a blank page">
>+<!ENTITY startupPreviousSession.label  "Show the tabs and windows from last time">
> 
> <!ENTITY downloads.label     "Downloads">

Also, on trunk (and ideally on branch if we find a valid reason to touch the file) I'd like to see these strings moved to their logical position as laid out on the screen.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

I think he was right to ask for ui-r, actually, since I mocked some stuff up backwards, looks like. :)

I'd been trying to keep the section titled "Home Page", but really that doesn't make sense, since the home page is independent of the real issue which is "what does Firefox do when it starts up."

 Startup __________________________________________________________________

  When Firefox starts: [ Load my home page                      |v]

  Home Page: [____________________________________________________________]
                   ( Use Current Page ) ( Use Bookmark ) ( Restore Default)


The spacing should also work out better this way. The drop down strings should be:

 Show my home page
 Show a blank page
 Show my windows and tabs from last time

thanks, myk, and sorry for the churn :(

Comment 24

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #22)

> Also, on trunk (and ideally on branch if we find a valid reason to touch the
> file) I'd like to see these strings moved to their logical position as laid 
> out on the screen.

Isn't that where they are already?  In the panel, the startup preference UI appears inside the "home page" group box, right underneath the buttons that set the home page preference, and in the DTD file the entity declarations for it appear right underneath the declarations for those buttons.

They also seem to appear in the correct order, since the menulist label for the preference appears first in the XUL file, followed by the menuitem labels for the home page, blank page, and previous session options, respectively, and the entity declarations follow that order.

Comment 25

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v4: implements beltzner's new spec

> Could you add some documentation to main.js explaining what this preference
> does and what its values are?  Preferences with UI which needs no scripting
> are consistently documented in this way in the panel JS files now (I need to
> bludgeon the non-panel JS files into shape when I have the time).

Yup, added.  Check it out and let me know if it's what you're looking for.


> Also, on trunk (and ideally on branch if we find a valid reason to touch the
> file) I'd like to see these strings moved to their logical position as laid
> out on the screen.

They were in that order already, but I've now reordered them to sync up with the changes in ordering in beltzner's new spec.  I also renamed startupPreviousSession to startupLastSession to eliminate the space horkage the longer name created.


>  Startup __________________________________________________________________
>
>   ...
>
> thanks, myk, and sorry for the churn :(

No problemo, I'll help you with your demo, if you go to the store for me.

I backed out the previous patch.  Here's a new one that implements the new spec and contains the documentation jwalden asked for.

Comment 26

[Jeff Walden [:Waldo]]

Comment on attachment 233020 [details] [diff] [review]
patch v4: implements beltzner's new spec

>Index: browser/components/preferences/main.js
>    *   this will be those URLs separated by the pipe character "|"
>+   *

Nit: don't put a newline here, since none of the other pref docs have newlines in this situation.


>+   *   There are four options for this preference, three of which are exposed
>+   *   in the dropdown menu for it (the fourth is deprecated and not exposed):

This info is basically mirrored in the actual XUL and immediately below, so I'd remove this sentence.  Also, I'd personally rather not describe how a preference maps to UI here; I believe that should either be comments directly in the JavaScript methods backing the UI if the mapping is somewhat opaque or not in the code at all (which I believe is /mostly/ the case here; see below).


>+   *     0: a blank page
>+   *     1: the home page (as set by the browser.startup.homepage pref)
>+   *     2: the last page the user visited (DEPRECATED)
>+   *     3: windows and tabs from the last session (a.k.a. session restore)

I like this.  :-D  This is *exactly* what I want here -- for enum-type prefs like this, the preference type and a listing of its recognized values with their effects.  Bonus points for putting "DEPRECATED" by 2, since that's something I don't know that I'd have thought to do if I were doing this.


>+   *   Note: when this preference is set to the deprecated option, and the user
>+   *   opens the panel, the deprecated option won't show up in the dropdown menu
>+   *   for the preference. Rather, the first option in the menu (1: the user's
>+   *   home page) will be selected.
>+   *
>+   *   But that option won't actually take effect unless the user explicitly
>+   *   selects it from the menu. So users can retain their existing deprecated
>+   *   preference when visiting the panel, even though the panel won't show it
>+   *   properly.
>+   *
>+   *   (Per the review comments in bug 346044, this is intentional.)

Again, I'm not such a fan of commenting on the UI for a pref here.  Since there's really no good place to mention how the deprecated options is handled except here, tho, keeping it here seems reasonable.  I would like a little more brevity, tho -- how about "The deprecated option is not exposed in UI; however, if the user has it selected and doesn't change the UI for this preference, the deprecated option is preserved."?  (I don't think explaining how an option not displayed in UI is displayed in UI is really necessary. ;-) )

Also, I assume you've actually tested that the deprecated option is preserved?  I could have sworn the preference is read when the pane is displayed and written when the dialog closes, such that hidden options like this are actually overwritten.  (It's also possible that's just a quirk of how getting/setting the pref using menulist.value works, since the times where I remember this not working were all with checkboxes.)


>Index: browser/components/preferences/main.xul

>+      <preference id="browser.startup.page"
>+                  name="browser.startup.page"
>+                  type="int"/>
>+
>       <preference id="browser.startup.homepage"

Nit: also no newline here.


>Index: browser/themes/pinstripe/browser/preferences/preferences.css

>-#browserStartupHomepage {
>+#browserHomePage {
>   padding: 2px 2px 3px 4px;
> }
...
>-#browserStartupHomepage {
>+#browserHomePage {
>   padding: 0;
> }

So this looks wrong from just looking at patch-provided context.  ;-)  If there's something wrong, could you fix it?

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: a little tight on mac, but the right direction!

This is looking much better. The spacing is still a little tight between the menulist and the textbox, though, especially when compared to the spacing between other menulists and widgets in the rest of the prefpanels. Dunno exactly what's wrong here.

And a small nit: "When &brandShortName; starts: " should have the lower case "s".

Pref panels are such a pain in the arse ;)

Comment 28

[Mike Kaply [:mkaply]]

Please make sure that locking of this preference works correctly.

Comment 29

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v5: addresses review comments

> Nit: don't put a newline here, since none of the other pref docs have
> newlines in this situation.

Ok, newline removed.


> This info is basically mirrored in the actual XUL and immediately below,
> so I'd remove this sentence.

Yeah, it's redundant.  I've removed it.


> how about "The deprecated option is not exposed in UI; however,
> if the user has it selected and doesn't change the UI for this preference,
> the deprecated option is preserved."?  (I don't think explaining how
> an option not displayed in UI is displayed in UI is really necessary. ;-) )

Sounds fine.  I have replaced what was there before with this text.


>Also, I assume you've actually tested that the deprecated option is preserved?

Yes, it's preserved when I open and close the preferences dialog or switch between panels.  In order to actually change the preference, I have to select a new option from the dropdown menu.


> >+      <preference id="browser.startup.page"
> >+                  name="browser.startup.page"
> >+                  type="int"/>
> >+
> >       <preference id="browser.startup.homepage"
> 
> Nit: also no newline here.

Ok, I've removed it (and also the empty line below the <preference> tag for browser.startup.homepage).


> >Index: browser/themes/pinstripe/browser/preferences/preferences.css
> 
> >-#browserStartupHomepage {
> >+#browserHomePage {
> >   padding: 2px 2px 3px 4px;
> > }
> ...
> >-#browserStartupHomepage {
> >+#browserHomePage {
> >   padding: 0;
> > }
> 
> So this looks wrong from just looking at patch-provided context.  ;-)  If
> there's something wrong, could you fix it?

Good catch. :-)  Both sets of rules have been around since v1.2 in early 2005.  Neither set seems to make any significant difference (not anymore, at least; perhaps one of them mattered back then), and no other preference textbox uses non-default padding, so I've removed both rules.

The Winstripe rules, however, do need to stick around, since otherwise the textbox looks funky.


> a little tight on mac, but the right direction!

mconnor suggested I add a <separator class="thin"/> to the XUL, and that makes it look fine on the Mac, but it adds a little too much space on Linux.  I suspect that the problem is in the native styling for menulists, or possibly in Pinstripe, but it looks like we're using separators in other places, so I'll use one here, too.


> And a small nit: "When &brandShortName; starts: " should have the lower case
> "s".

Urk, sorry, missed that.  Fixed.


> Please make sure that locking of this preference works correctly.

Thanks for sending me that preference locking extension!  With the preference locked, the menulist is disabled; it displays the locked option, but it doesn't let me change it.  So it looks like the UI respects locking correctly.

Comment 30

[Jeff Walden [:Waldo]]

Comment on attachment 233179 [details] [diff] [review]
patch v5: addresses review comments

(In reply to comment #29)
> (and also the empty line below the <preference> tag for browser.startup.homepage).

Actually...

I consider the button preferences to be a different beast from the preferences which actually affect how the browser acts (outside of just a preference window), so I'd prefer they be separated here by a newline.  :-)  Just a nit. ;-)  And thanks!

Comment 31

[Myk Melez [:myk] [@mykmelez]]

Fix checked into the trunk with jwalden's final nit (from comment 30) fixed.  I'll investigate the spacing issue further and file a bug if needed.

Comment 32

[Myk Melez [:myk] [@mykmelez]]

Attachment: the version that was checked into the trunk

Here's the version that was checked into the trunk.  It's identical to v5 except for one added blank line.

Comment 33

[Adam Guthrie]

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

Comment 34

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 233268 [details] [diff] [review]
the version that was checked into the trunk

Notes for drivers considering this approval request:

This bug does two things:

1. It reinstates prefs UI for setting a blank page as your startup page (considered a regression from the new prefs panel, since it used to be obvious how to do this, and now you have to have arcane knowledge of about:blank);

2. It exposes prefs UI for turning on session restore (valuable new functionality whose exposure in prefs is considered to be high-value).

The patch touches only well-tested code pathways (the default prefs panel handlers) and has received extensive review (review marked on the previous patch, which differs from this patch only by a trivial nit that I added upon checkin).  It presents a low risk of regression.  It has been on the trunk since Friday, August 11.

Comment 35

[Mike Connor [:mconnor]]

Comment on attachment 233268 [details] [diff] [review]
the version that was checked into the trunk

a=mconnor on behalf of drivers for 1.8 branch checkin

Comment 36

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 233268 [details] [diff] [review]
the version that was checked into the trunk

a=drivers for the mozilla_1_8_branch

Comment 37

[Mike Beltzner [:beltzner, not reading bugmail]]

Damn, connor beat me to it.

Comment 38

[Nick Thomas [:nthomas] (UTC+12)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060815 BonEcho/2.0b1 ID:2006081500

After this change, the "When <app> starts:" selector is 1 pixel shorter than the autocomplete box for the "Home Page:", which puts the emphasis on the home page (and jars the eye a smidge). Could the menulist get a 1px height increment so they look like they have equal weight ?

Comment 39

[Marcelo Simon]

First really liked the solution on this bug, killed two bugs as far as I can see.

Now sorry if this is bug spam, but I thing that the UI implemetation is really poor ( don't know if I should fill another bug for this ).

I've attached a new screenshot as it looks like in winxp, the space between the new dropdown and the textfield is too high, and it should be, as far as I can tell, aligned to the right side with the text field.

Comment 40

[Marcelo Simon]

Attachment: Screenshot with win XP

Comment 41

[Myk Melez [:myk] [@mykmelez]]

> the space between the new dropdown and the textfield is too high,

Yup, this is a known problem because of a hack to prevent the space from being too small on Mac.  I've filed bug 348793 on the Mac problem.  When fixed, we can remove the hack and make this look right for Windows and Linux.


> and it should be, as far as I can tell, aligned to the right side with the 
> text field.

According to beltzner's UI specs, that's not the case, and I doubt we want to make the menulist much wider just so its right edge aligns with the right edge of the textbox.

Comment 42

[Marcelo Simon]

(In reply to comment #41)
> Yup, this is a known problem because of a hack to prevent the space from being
> too small on Mac.  I've filed bug 348793 on the Mac problem.  When fixed, we
> can remove the hack and make this look right for Windows and Linux.

Hmm, I know it's not my decision, and I'm completely ignorant about this type of decisions here, but it isn't better to make Windows and Linux correct, and only Mac with the problem ? Since it has a bug specially to fix this issue ? 

 
> According to beltzner's UI specs, that's not the case, and I doubt we want to
> make the menulist much wider just so its right edge aligns with the right edge
> of the textbox.

I wasn't thinking about widening it, but just right align it to the right, keeping the size, at least to me it looks better than without any alignment.

The only similar element on the pref panels that has something like this is in the feeds section, but the drop down is the 'rightest' of the elements on that page, so it doesn't look so 'out of place' to me.

I'm just attaching a fake photoshop so it's easier to choose, if you go with mine opinion.

Comment 43

[Marcelo Simon]

Attachment: Dropdown right aligned

Also I think that when the user select anything other than 'my homepage' the homepage textfield and it's buttons should be greyed out ( probably another bug )

Comment 44

[Adam Guthrie]

Marcelo, can you please file follow-up bugs for all the issues you've mentioned? Commenting in this bug isn't going to do a lot of good. Thanks!

Comment 45

[ronin.achilles]

(In reply to comment #43)
> 
> Also I think that when the user select anything other than 'my homepage' the
> homepage textfield and it's buttons should be greyed out ( probably another bug
> )
> 

I am not sure about this. Consider this scenario. I have 'Bloglines.com' as my homepage, but I have selected to 'Restore my Tabs and Windows from Last time' when browser starts. Now whenever I want to see my home page, I would click the 'Home' button or 'Alt+Home' or whatever. I would think this is the expected behavior too. Coz if we go by your solution, it will render the 'Home' button on the toolbar absolutely useless.

Comment 46

[Myk Melez [:myk] [@mykmelez]]

> Dropdown right aligned

For me it's more valuable to have a strong association between the menulist and its label than to have strong alignment down the right hand side of the page.  The latter might make the layout look better, but the former impacts usability.

> Also I think that when the user select anything other than 'my homepage' the
> homepage textfield and it's buttons should be greyed out

As comment 45 points out, there's a use for the home page pref even when the user isn't loading her home page at startup, so we should most likely leave it enabled.

Comment 47

[Myk Melez [:myk] [@mykmelez]]

> After this change, the "When <app> starts:" selector is 1 pixel shorter 
> than the autocomplete box for the "Home Page:", which puts the emphasis 
> on the home page (and jars the eye a smidge). Could the menulist get 
> a 1px height increment so they look like they have equal weight ?

I have filed this request as bug 353426.


> > the space between the new dropdown and the textfield is too high,
> 
> Yup, this is a known problem because of a hack to prevent the space
> from being too small on Mac.  I've filed bug 348793 on the Mac problem.
> When fixed, we can remove the hack and make this look right for Windows 
> and Linux.

I filed bug 353429 on removing the hack once bug 348793 is fixed.