325741 - Wrong HREF in 1.5.0.1 "about:" page

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060202 Firefox/1.5.0.1
Build Identifier: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060202 Firefox/1.5.0.1", build ID:2006020204

Clicking on the big fat link (labeled "Firefox 1.5.0.1") under the Firefox logo leads to 1.5 release notes, not 1.5.0.1 release notes.

Reproducible: Always

Steps to Reproduce:
1. Type "about:" (without the quotes) in URL bar
2. Hit Enter -- the "about:" page displays
3. Click on the link saying "Firefox 1.5.0.1" between the Firefox logo and the User-Agent string

Actual Results:  
Release notes for 1.5 display: http://www.mozilla.com/firefox/releases/1.5.html

Expected Results:  
Release notes for 1.5.0.1 should display: http://www.mozilla.com/firefox/releases/1.5.0.1.html (Typing this URL into the URL bar shows that there is a page at that address).

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Seems like brand.dtd wasn't updated.

Comment 2

[Daniel Veditz [:dveditz]]

Reassigning this one to Rafael, CC Axel.

Updating the URL means a localization hit probably, and I wonder if that's what we really want to do anyway. Shouldn't the release notes stay in the same place and simply have updated sections at the top for the new releases?

  "Firefox 1.5.0.2 released to fix security bugs <link to vuln pages>"

The 1.5.0.1 release notes are pretty thin and we hope future 1.5.0.x changes shrink even more. And coming at it from the other side of the coin, someone who's jumped on the bandwagon at the 1.5.0.1 point will now miss the top chunk of information that was in the 1.5 release notes.  Then of course it's followed by duplicated System and installation information.

Best to "fix" this bug by making the current URL the correct one without having to change any code.

But Rafael's call (as perhaps influenced by Axel's concerns)

Comment 3

[J. Paul Reed [:preed]]

(In reply to comment #2)
> Best to "fix" this bug by making the current URL the correct one without having
> to change any code.
> 
> But Rafael's call (as perhaps influenced by Axel's concerns)

Agreed on Rafael's call, but I think it should be changed.

Actually, the right way to do this is to come up with a schema that is followed to release notes, and generate this URL based on that; we shouldn't need to update this every release.

But having a predictable URL lets us play games on the server side if we ever need to. I think it's confusing to have a 1.5.0.x build, and get 1.5 release notes (even if they're updated).

Comment 4

[Tony Mechelynck [:tonymec]]

(In reply to comment #3)
[...]
> But having a predictable URL lets us play games on the server side if we ever
> need to. I think it's confusing to have a 1.5.0.x build, and get 1.5 release
> notes (even if they're updated).
> 

... especially since 1.5 and 1.5.0.1 correspond to separate code branches, with separate sets of nightlies (see http://ftp.mozilla.org/firefox/nightly/latest-mozilla1.8/ and http://ftp.mozilla.org/firefox/nightly/latest-mozilla1.8.0/ -- plus similar l10n builds). Both of them were updated less than 24 hours ago.

Comment 5

[Tony Mechelynck [:tonymec]]

(In reply to comment #4)
Oops...

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/ and
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.0/

Comment 6

[Daniel Veditz [:dveditz]]

(In reply to comment #3)
> I think it's confusing to have a 1.5.0.x build, and get 1.5 release
> notes (even if they're updated).

The URL would say "1.5" but who's really going to notice that? the content would start off with the latest 1.5.0.x stuff and say the latest version. 1.5.0.1 *is* a version 1.5 release, there should be absolutely no functional difference between the two to the casual observer.
 * This helps cut dev work necessary for security updates
 * Reduces required l10n work tremendously (unless, as it appears, they just
   leave their URL not updated, which is what I'm proposing en-US do).
 * Reduce QA work to make sure the URL is updated correctly
   (still have to check that the content changes land)
 * Eliminates worry about where the "more details" link in the update
   dialog should point -- don't need to update it, just point at the
   release notes.
 * Bonus: someone using an old version to visit the release notes would
   see the new version number there, and could even be given a sniff-driven
   warning box at the top that they need to upgrade (in case they've turned
   off update checking).

As long as the new version's content doesn't replace any of the old content (for that same base version; 1.5 would still completely replace 1.0) but is merely added to the top we're not losing any history value.

I guess that's not how we handled the 1.0.x series though, and the release notes menu item has been updated to point at the new location.

Comment 7

[Axel Hecht [:Pike]]

Seconding dveditz here.

Plus, if we add an ever-changing URL to the language packs, we need to patch them
for each of our non-l10n-impact releases, thus adding the whole patch logic to
the download size of the incremental update.

I really prefer a server-side solution for this. I guess it'd be good to wiki
out some of the requirements here, and alternative solutions. Anybody got a 
good idea for where to hook that up? Topics include l10n, disabling js and 
whatsnew-like pages, real server negotiated redirect, where to, who etc.
And this is not just for release notes.

Adding beltzner, I'm not sure if that link should actually go to release notes
from a UE pov in the first place.

Comment 8

[Rafael Ebron (:rebron)]

I'm trying to flush out trademark review via this document: http://wiki.mozilla.org/L10n:Firefox_Trademark_Review

We can put some of the requirements there.

I do agree that maybe we should consider pointing that link to something else.

I don't agree on the release notes being one release note page and adding to it as we have new releases.  We've gone down that path before.  The release notes url will remain predictable: http://www.mozilla.com/firefox/releases/[version #].html

I guess the question is how do we get that page localized?

Comment 9

[Axel Hecht [:Pike]]

I'm not that much concerned about where the release notes are actually hosted,
but I would prefer to not include that URL in the build, but rather have a 
server side redirect to it.
Esp for things like release notes, I'd like to get out of the corner of 
all-or-nothing and not having to decide whether we can localize the content or
not three weeks before release.
Having something dynamic on the server sounds much more appropriate, maybe even
something like 
http://www.mozilla.com/redirect?key=releasenotes&version=1.5.0.2&lang=ab-CD

Comment 10

[Tony Mechelynck [:tonymec]]

    (In reply to comment #7)

    Seconding preed.

    Firefox "knows" if it should call himself "1.0.7", "1.5", "1.5.0.1", or whatever, doesn't it? So why not build up the URL from smaller building blocks, where one part would be "1.5" "1.5.0.1" etc.; if different URLs are needed for different languages, then another part would be "en_US" "fr_BE" "zh_TW" etc. (or maybe the page itself can determine which language it should display); most would be constant even across releases. Once streamlined, the only change from one version to the next would be writing the new "release notes" page, which is already done anyway. No need to ever-repatch the URL itself since the building blocks are already there, they are assembled in a constant manner, and _their_ values already need to be changed (in a predictable way) for other reasons.

    If a single page must do double duty for more than one release, then the target of one of the URLs can always be a redirect (zero-seconds refresh or whatever).

Comment 11

[Steffen Wilberg]

I've already fixed this in bug 318991 for the trunk and the 1.8.1 branch.

about: now links to http://www.mozilla.com/firefox/releases/__MOZ_APP_VERSION__.html, like the Release Notes menu item in the Help menu already does on the 1.8.0 branch (http://lxr.mozilla.org/mozilla1.8.0/source/browser/base/content/utilityOverlay.js#443).

So I'd suggest to check in the patch from bug 318991 on the 1.8.0 branch as well, and fix the brand.dtd in all locales by search-and-replace.

Concerning multiple languages, that can be solved server-side with content negotiation, so that the link to foo.html results in foo.html.AB, depending on the Accept-Language header; if foo.html.AB is not available, use foo.html.en as a fallback. http://httpd.apache.org/docs/2.0/content-negotiation.html

Comment 12

[Rafael Ebron (:rebron)]

->Gavin

Can you check in the patch that was applied on the trunk?

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch for the 1.8.0 branch

Comment 14

[Axel Hecht [:Pike]]

veto, this busts all l10n builds. I reopened bug 318991, too, as that patch
is a semantic change to the entity and should change its key.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 212963 [details] [diff] [review]
patch for the 1.8.0 branch

Argh, sorry, this clearly won't do for the 1.5.0 branch since it's involves a localization change (making other localizations URLs invalid).

Comment 16

[:Gavin Sharp [email: [e-mail]]]

Given the fact that this is a minor issue (is there even a way to get to about: without knowing about it beforehand?) and involves localization changes to fix correctly, I think this should be WONTFIX for 1.5.0.2, at least on the client side. Bug 318991 handles doing this correctly on the 1.8 branch and trunk, and a server-side redirect or re-shuffling of the release notes mentioned in previous comments can be used if this really is determined to be an issue for 1.5.0.x.

Comment 17

[Daniel Veditz [:dveditz]]

If you go to the release notes from the "release notes" help menu item you get the correct page. The about: page is obscure hidden functionality and is not worth the l10n pain.

If Rafael doesn't want to go for a content change as in comment 2 and comment 6 (or a server UA sniff) then this bug isn't appropriate for the 1.5.0.x branch.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

Going to mark this WONTFIX for the 1.5.0.x branch. A solution to bug 318991 covers the 2.0 branch and trunk. Feel free to re-open if there's disagreement.