Closed Bug 224351 Opened 21 years ago Closed 14 years ago

Set browser.startup.homepage to www.mozilla.org/startup/

Categories

(SeaMonkey :: UI Design, enhancement)

x86
Windows 2000
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED
Future

People

(Reporter: danielwang, Assigned: jag+mozilla)

References

()

Details

Don't know how stable 1.6 will be, but we could use another start page.
The 1.4 start page is mostly updated and is ready to be ported over.

Can someone copy 1.4 content to 1.6 (I cannot create new directory in start/
partition) and change the startup page link to start/1.6/ ?
Blocks: start1.6
We need to find a better way of doing this than creating more and more copies of
mostly-the-same content.

We also need a mechanism whereby we can independently move the start page for a
release after the fact. I.e. something like a system where the URL used is tied
to the version number, and there's some server-side stuff which does an
intelligent and programmable redirect to the most appropriate page.

But I think there's a bug on that already.

Gerv
Sounds like php with sql (or something similar) is needed.  Do the servers have
any scripting language setup?
It can be done with Apache rewrite rules, too (which would probably be much
easier than setting up scripts to handle it).

We have the technology on hand to pull off just about anything now though.
Can it though?  (I'm just reading up on it now - I had never heard of this
before)  I mean the FAQ changes slightly from version to version as
features/bugs are added/removed and the faq needs to change based on the
version.  From what I can tell from the rewrite rules, it allows you to display
different pages based on location or another factor.  Can it pick and choose
which parts of the faq to display depending on the version?
I think the idea wasn't to have a single unified FAQ for all versions, but to
only create a new one when the information changed in such a way to make it
irrelevant to an older version.  Say for example 1.5 is out.  Nothing major
happens between it and 1.6 to cause the pages to have to be redone.  But 1.6
still spits out its own version number in the url coming to the start page.  The
RewriteRule can tell Apache to display the 1.5 start page when someone tries to
access 1.6.  Say a month or so later, someone discovers something weird in 1.6
which requires it to have a new start page separate from 1.5.  We can change
that rewrite rule and give 1.6 its own page.  The browser doesn't know the
difference, and it saves creating new content before its actually needed.
-> future. The start page needs a complete overhaul (see bug 224352)

but please continue the discussion :-)
Summary: Update browser.startup.homepage to new 1.6 start page → Update browser.startup.homepage to new 1.[?] start page
Target Milestone: --- → Future
Currently we are linking to start page content from Mozilla Help. There's
concern of bad publicity to link to 1.5 content from 1.6 release. This is what
I'm thinking:

* default seamonkey start page to http://www.mozilla.org/startup/ (like Opera)
* put a user-oriented welcome message on this page
* put FAQ and troubleshooting in separate places.
* one each FAQ and troubleshooting item, we identify the version applicability,
like 1.5 and later, 1.4 only, 1.0 - 1.4, etc.
* we need to move add-on page to somewhere else. specifically we need some place
for langauge packs and langauge builds. We need to be careful not to make bug
226064 worse as it is now though. (also, anyone got comment for fantasai's
download page at bug 222514?)

comments?
Summary: Update browser.startup.homepage to new 1.[?] start page → Set browser.startup.homepage to www.mozilla.org/startup/
Product: Core → Mozilla Application Suite
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
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.