337823 - Help -> Release Notes doesn't use url from brand.dtd

Status: RESOLVED DUPLICATE of bug 348076

(Firefox :: Menus, defect)

Description

[Steffen Wilberg]

Help -> Release Notes calls openReleaseNotes(), which uses releaseNotesURL from region.properties, which is http://www.mozilla.org/products/firefox/releases/%S.html:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/utilityOverlay.js&rev=1.32.2.5&mark=435-442#428
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/locales/en-US/chrome/browser-region/region.properties&rev=1.9.2.3&mark=6

On the other hand, about: uses releaseBaseURL from brand.dtd, which is either http://www.mozilla.org/projects/bonecho/releases/__MOZ_APP_VERSION__.html or
http://www.mozilla.com/firefox/releases/__MOZ_APP_VERSION__.html, depending on whether official branding is enabled or not:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/content/about.xhtml&rev=1.8.8.2&mark=82#82
http://lxr.mozilla.org/mozilla1.8/source/browser/locales/en-US/chrome/branding/brand.dtd#6
http://lxr.mozilla.org/mozilla1.8/source/other-licenses/branding/firefox/locales/en-US/brand.dtd#6

This divergence already caused bug 337818.

So Help -> Release Notes should use the releaseBaseURL from brand.dtd.

Comment 1

[Steffen Wilberg]

Attachment: patch

Similar to bug 337834, but more elegant since it gets rid of openReleaseNotes() and releaseNotesURL, which aren't used anywhere else:
http://lxr.mozilla.org/mozilla1.8/search?string=openReleaseNotes
http://lxr.mozilla.org/mozilla1.8/search?string=releaseNotesURL

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 3

[Mike Connor [:mconnor]]

Comment on attachment 221908 [details] [diff] [review]
patch

So, I don't think the right fix here is to hardcode the URL into content.  Its better to include releaseBaseURL into the localized string and expand that.

Comment 4

[Steffen Wilberg]

I don't understand. What part of the url is hardcoded? &releaseBaseURL; is an entity from brand.dtd and MOZ_APP_VERSION is expanded by the preprocessor. The only fixed part is ".html".

And what do you mean by "include releaseBaseURL into the localized string and expand that"? Pass releaseBaseURL as an argument to openReleaseNotes(), which appends nsIXULAppInfo.version and ".html" to it? How does that make a difference? It just moves code from content/baseMenuOverlay.xul to content/utilityOverlay.js. And it queries the app version each time despite the fact that it can't change since it's already hardcoded in nsBrowserApp.cpp.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/app/nsBrowserApp.cpp&rev=1.31.2.3&mark=51#46
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/app/Makefile.in&rev=1.85.2.6&mark=172,173#172

I did the same to about.xhtml in bug 318991 and bsmedberg liked it a lot.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

If this can get resolved for beta fine, for now we'll go with the less elegant fix.

Comment 6

[Steffen Wilberg]

Since nobody bothered to check in beltzner's fix from bug 337834 (or answer my questions in comment 4), this hit us again for alpha 3. I've reopened bug 337818 to add another server redirect.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

renominating for beta1 so we don't get screwed; it's either a patch like the one offered here, or a less elegant solution as offered in attachment 221901 [details] [diff] [review]

Comment 8

[Mike Connor [:mconnor]]

Need to decide what, if anything, we're doing here.

Comment 9

[Mike Connor [:mconnor]]

Not going to block on this, negative side is that we have to keep URLs in sync, but we can live with that.

Comment 10

[Steffen Wilberg]

Fixed by bug 348076.

*** This bug has been marked as a duplicate of 348076 ***