Closed Bug 150900 Opened 18 years ago Closed 17 years ago

Help | Release Notes doesn't go to Release Notes

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.5final

People

(Reporter: contact2009, Assigned: bugzilla)

References

Details

(Keywords: fixed1.5, helpwanted, useless-UI)

Attachments

(1 file, 1 obsolete file)

Using 1.1alpha Build ID: 2002060704, Windows 98, the Help | Release Notes menu
sends the browser to the Releases page, not the Release Notes page. Preferably,
that should send the user to the Release Notes page. Alternatively, we could
change the name of the menu item to "Releases."
Keywords: mozilla1.0.1
-> GUI features
Assignee: Matti → blaker
Component: Browser-General → XP Apps: GUI Features
QA Contact: imajes-qa → paw
-> Help
Component: XP Apps: GUI Features → Help
-> Help
Assignee: blaker → oeschger
QA Contact: paw → tpreston
not help, [mozillazine]helpwanted
Assignee: oeschger → blaker
Component: Help → XP Apps: GUI Features
Keywords: mozilla1.0.1helpwanted
QA Contact: tpreston → paw
Reproduced using FizzillaCFM/2002091014 on 10.1.5. Setting All/All.
OS: Windows 98 → All
Hardware: PC → All
Keywords: mozilla1.2
*** Bug 175485 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3
Summary: Help | Release Notes menu doesn't work right → Help | Release Notes goes to releases, not release notes
> Alternatively, we could change the name of the menu item to "Releases."

No point in linking to the releases page (how does that 'help' the user?).

What we need is a variable for the version string that can be accessed from
chrome javascript, returning a value such as "1.0" or "1.2b".

Assuming that variable were to be called $version, we would make Help | Release
Notes point to "http://www.mozilla.org/releases/mozilla" & $version & "/" . This
would work around the problem of having to update the URL every time we do a new
release.
Summary: Help | Release Notes goes to releases, not release notes → Help | Release Notes doesn't go to Release Notes
Let's not create a new variable for the version. Instead, let's point to a PHP
file on the mozilla.org web site, then do browser sniffing and redirect the user
to the appropriate page. 

This leads to only two issues, neither one real. The first concerns users who
are spoofing their user agent identity. The second concerns Mozilla users who
want to see release notes for versions other than those of their current
browsers. All of the actual release notes pages will still be static HTML files,
They can see an index page listing all release notes. Thus, people can still see
their release notes. It's just that if you take the trouble to spoof your user
agent, you will have to manually select which release notes you want to see.
Flags: blocking1.4a?
Keywords: useless-UI
The Mozilla website does not support PHP, or any dynamic content, for that
matter. Let's do the simple thing, please:

> What we need is a variable for the version string that can be accessed from
> chrome javascript, returning a value such as "1.0" or "1.2b".

We have one. It's called the user agent.

Gerv
Flags: blocking1.4a? → blocking1.4a-
Flags: blocking1.4.x?
If a patch in this bug gets proper reviews, feel free to request approval to
land in 1.4.x but we're not going to hold the 1.4.1 release for this. 
Flags: blocking1.4.x? → blocking1.4.x-
Comment on attachment 115547 [details] [diff] [review]
much better patch

r=gerv, for what that's worth - I've tested it and it works.

Gerv
Attachment #115547 - Flags: review+
Comment on attachment 115547 [details] [diff] [review]
much better patch

Requesting sr= from blake (who is also the module owner.)

Gerv
Attachment #115547 - Flags: superreview?(blake)
while a sr from blake would surely be accepted, the xpfe module owner is jag
(see http://www.mozilla.org/owners.html)
Comment on attachment 115547 [details] [diff] [review]
much better patch

sr=jag
Attachment #115547 - Flags: superreview?(blake) → superreview+
Comment on attachment 115547 [details] [diff] [review]
much better patch

Requesting approval.

Gerv
Attachment #115547 - Flags: approval1.5?
Comment on attachment 115547 [details] [diff] [review]
much better patch

a=asa (on behalf of drivers) for checkin to the Mozilla 1.5 branch
Attachment #115547 - Flags: approval1.5? → approval1.5+
Fixed.

Checking in allmakefiles.sh;
/cvsroot/mozilla/allmakefiles.sh,v  <--  allmakefiles.sh
new revision: 1.436.4.1; previous revision: 1.436
done
Removing xpfe/global/resources/locale/en-US/region.dtd;
/cvsroot/mozilla/xpfe/global/resources/locale/en-US/region.dtd,v  <--  region.dtd
new revision: delete; previous revision: 1.19.6
done
RCS file: /cvsroot/mozilla/xpfe/global/resources/locale/en-US/Attic/region.dtd.in,v
done
Checking in xpfe/global/resources/locale/en-US/region.dtd.in;
/cvsroot/mozilla/xpfe/global/resources/locale/en-US/Attic/region.dtd.in,v  <-- 
region.dtd.in
new revision: 1.1.2.1; previous revision: 1.1
done

Gerv
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.5final
I'm not sure this was such a great idea.  First release after this goes in, and
we have a page with the wrong link (bug 219566).

Having a link to a generic page is better than linking to the wrong thing...
Why did this land on the 1.5 branch but not on the trunk?

Are you sure that content.version should be tied to the Mozilla release version?
 (It would be nice if it's true, but I'm not sure it is.)
If this is going to go in to the trunk, there should really be placeholder pages
or something for future releases.  e.g. current trunk builds would point to
http://www.mozilla.org/releases/mozilla1.6a/ but that is currently 404.
I emailed kairo to check very carefully that this was the right thing for
content.version.

Michael: good point. We should have placeholder pages.

Gerv
This has now been checked into the trunk, and a placeholder page for 1.6a has
been checked into www.mozilla.org CVS.

Gerv
Should lang.version do the same thing as content.version?
Keywords: fixed1.5
dbaron: quite possibly, I don't know. There are other bugs open on using the
same technique for other places in the tree where the version number is required.

Gerv
dbaron:
Ideally, lang.version should follow this approach as well as all contents.rdf
that contain a localeVersion string.
We could get rid of my big patches for every release with this approach and
would fix bug 154927 - look into that for more info. I'd really love to see a
patch for this ;-)
*** Bug 102423 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.