150900 - Help | Release Notes doesn't go to Release Notes

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Andrew Hagen]

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."

Comment 1

[Matthias Versen [:Matti]]

-> GUI features

Comment 2

[Blake Ross]

-> Help

Comment 3

[Blake Ross]

-> Help

Comment 4

[timeless]

not help, [mozillazine]helpwanted

Comment 5

[Greg K.]

Reproduced using FizzillaCFM/2002091014 on 10.1.5. Setting All/All.

Comment 6

[Jo Hermans]

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

Comment 7

[Sören 'Chucker' Kuklau (gone)]

> 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.

Comment 8

[Andrew Hagen]

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.

Comment 9

[Gervase Markham [:gerv]]

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

Comment 10

[Sören 'Chucker' Kuklau (gone)]

Attachment: Using same approach as about.xhtml (regexp'ing the rv string from UA string)

Not fully tested.

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: much better patch

Comment 12

[Asa Dotzler [:asa]]

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. 

Comment 13

[Gervase Markham [:gerv]]

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

Comment 14

[Gervase Markham [:gerv]]

Comment on attachment 115547 [details] [diff] [review]
much better patch

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

Gerv

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

while a sr from blake would surely be accepted, the xpfe module owner is jag
(see http://www.mozilla.org/owners.html)

Comment 16

[jag (Peter Annema)]

Comment on attachment 115547 [details] [diff] [review]
much better patch

sr=jag

Comment 17

[Gervase Markham [:gerv]]

Comment on attachment 115547 [details] [diff] [review]
much better patch

Requesting approval.

Gerv

Comment 18

[Asa Dotzler [:asa]]

Comment on attachment 115547 [details] [diff] [review]
much better patch

a=asa (on behalf of drivers) for checkin to the Mozilla 1.5 branch

Comment 19

[Gervase Markham [:gerv]]

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

Comment 20

[Michael Lefevre]

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...

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 22

[Michael Lefevre]

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.

Comment 23

[Gervase Markham [:gerv]]

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

Comment 24

[Gervase Markham [: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

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Should lang.version do the same thing as content.version?

Comment 26

[Gervase Markham [:gerv]]

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

Comment 27

[Robert Kaiser]

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 ;-)

Comment 28

[Daniel Wang]

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