144706 - First-start and default Home page URLs should be distinct

Status: RESOLVED DUPLICATE of bug 521314

(SeaMonkey :: General, defect)

Description

[ralph]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; Q312461)
BuildID:    

Gerv said:
>>The current http://www.mozilla.org/start/ is both home page and
>>first-start page on the trunk. The same is true for
>>http://www.mozilla.org/start/1.0 on the branch.

If I'm understanding this correctly, the functionality exists to display a 
special first-start page that is distinct from the default home page, yet the 
URLs are hard coded or configured to be the same. Those who are writing the 
welcome / home page(s) should be able to create a welcome page that is distinct 
from the home page.

Gerv asked me to file a bug; here it is.

Reproducible: Always

Steps to Reproduce:
1. Run browser for first time
2. Run browser again

Actual Results:  Same page displayed both times. (This is what Gerv has said 
will happen; I have not tested this.)

Expected Results:  Welcome page displayed first time.
Home page displayed second and subsequent times.

Comment 1

[ralph]

I note that the trunk URLs both end in a slash and the branch URLs don't. I'm 
not sure that's intended. Gerv?

Comment 2

[Gervase Markham [:gerv]]

<sigh> That's another bug. A posse wanted the slashes added, so they added them
on the trunk. If we are changing these URLs again, we might as well add them on
the branch.

If someone could rustle up a patch for this, that would be great - my attempts
to do so last time weren't particularly successful.

Gerv

Comment 3

[Matthias Versen [:Matti]]

==> default owner

Comment 4

[Daniel Wang]

I think this bug is invalid. If a distributor wants to change the first
start page, all it has to do is chaning all.js

see
http://lxr.mozilla.org/mozilla/source/build/package/rpm/SOURCES/mozilla-redhat-home-page.patch

Comment 5

[ralph]

> If a distributor wants to change the first start page,
> all it has to do is chaning all.js

Right. A distributor can change many (all?) other settings this way.

This bug was about what the *default* settings should be, which is a legitimate 
question about any settings, independent of any ability to change it.

Further, the issues this bug raises applies separately to both SeaMonkey and to 
3rd-party distributions, and this bug is targeted at SeaMonkey, not 
distributions in general -- I filed it when I was involved in writing the 
Welcome and Home pages for SeaMonkey. (These pages ended up being conflated for 
SeaMonkey.)

Comment 6

[Daniel Wang]

gerv, can we default first-start to the release note page?

Comment 7

[Gervase Markham [:gerv]]

Actually, we want the first start page to be the same as all the other start
pages. User feedback on this "feature" suggests that it just leads to confusion.
They can't work out why their browser used to start on page A and now starts on
page B.

The default start page for all Mozillas is www.mozilla.org/start; this gets
redirected server-side to /start/1.x/ if there is a special start page for that
version. But you are right - these version-specific pages (used for final
releases) could and should give a link to release notes. Having a quick look, it
seems that 1.6 does, but 1.5 doesn't.

Gerv

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614