415890 - Help -> Release Notes points to an invalid address for custom builds

Status: RESOLVED WONTFIX

Description

[Stefan Ritter]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1.11) Gecko/20071128 Iceweasel/2.0.0.11 (Debian-2.0.0.11-1)
Build Identifier: 2.0.0.9

Hi, this bug is forwarded from bugs.debian.org:

Help->Release Notes points to an invalid Web page:
http://en-us.www.mozilla.com/en-US/mozilla-thunderbird/2.0.0.0/releasenotes/
The correct link should be
http://en-us.www.mozilla.com/en-US/thunderbird/2.0.0.0/releasenotes/

In the German Version:

http://de.www.mozilla.com/de/mozilla-thunderbird/2.0.0.9/releasenotes/
should be
http://de.www.mozilla.com/de/thunderbird/2.0.0.9/releasenotes/

How you can see, this Bug exists since 2.0.0.0.

Regards, Stefan

Reproducible: Always

Steps to Reproduce:
1.Help 
2. Releasenotes
3.



Tested with the german version of Thunderbird.

Comment 1

[Steffen Wilberg]

The release notes url is specified here:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mail/app/profile/all-thunderbird.js&rev=1.44.2.46#104

The pref app.releaseNotesURL is set to http://%LOCALE%.www.mozilla.com/%LOCALE%/%APP%/%VERSION%/releasenotes/.

So if Debian changes the app name from thunderbird to mozilla-thunderbird, they need to hardcode "thunderbird" in that pref.

Comment 2

[Steffen Wilberg]

Please reopen if you see this problem with a Thunderbird version downloaded from www.mozilla.com.

Comment 3

[Magnus Melin]

Actually, seems really stupid of us to make the APP part of that url dynamic...

Comment 4

[Magnus Melin]

Created attachment 301716 [details] [diff] [review]
proposed fix (thunderbird)

Hardcode appname in the URL. Should affect primarily linux distros, if they change the name but don't bother having special urls for release notes etc.

Comment 5

[Magnus Melin]

Created attachment 301719 [details] [diff] [review]
proposed fix (firefox)

Same thing for firefox.

Comment 6

[Phil Ringnalda (:philor)]

Does this actually really help? From what I hear, a fair number of distros will be releasing a 1.5.0.15, which I wouldn't expect to have a mozilla.com set of release notes (though it might, I guess), and I know some released Tb versions for the 2.0.0.x things that we skipped. My first inclination is to say that if you're deep enough in the guts of what you're distributing to change the appInfo.name, you should probably think long and hard about whether you want your own release notes (if any: Debian already fixed their parallel issue with Iceweasel, by just removing the Release Notes menuitem and the link they had in about:).

I do think it would be a good thing to be sure the menuitem can survive having a blank URI pref (ideally by disappearing, or at least disabling), put the mozilla.com pref somewhere that's obviously branded, and either blank the unofficial branding one or give it a "you'll probably want to change me" comment, but without hearing from Mike or someone at another distro saying this is something they need, I'm just not sure that making it easier to not realize that you're distributing something with a menuitem that may or may not go anywhere useful at some random future time outside your control is an improvement.

Comment 7

[Phil Ringnalda (:philor)]

s/Mike/Mike or Alexander/ - I looked right at the third line in the Debian bug report, and *still* listened to someone's bad advice about who maintains Icedove for Debian.

Comment 8

[Magnus Melin]

Yeah, it doesn't completely catch edge cases like a possible 1.5.0.15, but I don't see the point of allowing the url to break just to make them provide their own url. The release notes would be pretty much the same anyway, given that the only real reason they change the name would be for trademark issues. Or maybe it's just some naming convention, I don't know.

Comment 9

[Phil Ringnalda (:philor)]

Comment on attachment 301716 [details] [diff] [review]
proposed fix (thunderbird)

You're already bitrotted for this approach, by the get add-ons pane. And I'd expect you to continue to be, bitrotted and then regressed, unless you remove support for %APP% from the urlformatter - you're saying that it's unusable, but leaving it around to be used, which seems pretty fragile. (And within the confines of this patch, you wouldn't want to change the app.update URLs, since they are unusable for anyone who would need your changes, but if you did you would need to also change app.update.url, since %PRODUCT% is the same replacement as done by the update code rather than the urlformatter.)

Comment 10

[Phil Ringnalda (:philor)]

And having spent too much of the last two days reading Debian and Ubuntu changesets, I still don't think this is the place to fix this issue. The mozilla-thunderbird thing (which seems to have been to change where profiles are stored, near as I can tell) is already a significant change, requiring a hardcoded icedove here, and a $(MOZ_APP_NAME) there, and if fixing this needs either a pref with a different URL in debian/icedove.js|thunderbird.js, or better yet (since it has the potential to also fix broken extensions who weren't expecting this) another hack to hardcode "thunderbird" as the urlformatter's idea of appname, that just doesn't strike me as being the straw that will break the changeset's back.

Whether or not asac wants to link to the official release notes isn't really any of my business, but having both looked at the scope of changes (including changes in -n releases that don't even map to a Mozilla release) and the tiny little percentage of the release notes that actually applies (since they are mostly about where to download from mozilla.com, and how to install on Windows, and workarounds for Fedora Core 3), if it was me I'd sure think seriously about following Iceweasel's example of using a README plus maybe a link to the changeset instead.

In any case, I really think we should wait to hear from him what he wants and plans, before we give up on %APP% in general.

Comment 11

[Phil Ringnalda (:philor)]

And to the extent (still unknown, since you and I are the only ones talking here) that the mozilla-thunderbird thing is there to move the profile, INVA since bent made it possible to specify a profile location without mucking with the name, in bug 396209.

Comment 12

[Magnus Melin]

asac: any insight into why mozilla-thunderbird instead of simply thunderbird is used, and does bug 396209 change things regarding that?

Comment 13

[Alexander Sack]

(In reply to comment #12)
> asac: any insight into why mozilla-thunderbird instead of simply thunderbird is
> used, and does bug 396209 change things regarding that?
> 

This is a legacy thing. The current plan is to migrate users back to thunderbird when we get to tbird 3.

Comment 14

[Magnus Melin]

Ok, still not convinced not having hardcoded names in urls is the best way, but let's wontfix this though as it would seem not to affect ~ anyone anymore.