Closed Bug 150900 Opened 18 years ago Closed 17 years ago
Help | Release Notes doesn't go to Release Notes
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."
-> GUI features
Assignee: Matti → blaker
Component: Browser-General → XP Apps: GUI Features
QA Contact: imajes-qa → paw
Component: XP Apps: GUI Features → Help
Assignee: blaker → oeschger
QA Contact: paw → tpreston
not help, [mozillazine]helpwanted
Reproduced using FizzillaCFM/2002091014 on 10.1.5. Setting All/All.
OS: Windows 98 → All
Hardware: PC → All
*** Bug 175485 has been marked as a duplicate of this bug. ***
Summary: Help | Release Notes menu doesn't work right → Help | Release Notes goes to releases, not release notes
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.
Not fully tested.
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: 184.108.40.206; 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?
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. ***
You need to log in before you can comment on or make changes to this bug.