Closed Bug 415890 Opened 17 years ago Closed 17 years ago

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

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Linux
defect
Not set
trivial

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: stefan.ritter, Assigned: mkmelin)

References

()

Details

Attachments

(1 file, 1 obsolete file)

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.
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.
Assignee: jwalden+fxhelp → nobody
Component: Help Documentation → Mail Window Front End
QA Contact: help-documentation → front-end
Version: unspecified → 2.0
Please reopen if you see this problem with a Thunderbird version downloaded from www.mozilla.com.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Actually, seems really stupid of us to make the APP part of that url dynamic...
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Help -> Release Notes points to an invalid address → Help -> Release Notes points to an invalid address for custom builds
Assignee: nobody → mkmelin+mozilla
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Attachment #301716 - Flags: review?(philringnalda)
Attached patch proposed fix (firefox) (obsolete) — Splinter Review
Same thing for firefox.
Attachment #301719 - Flags: review?
Status: NEW → ASSIGNED
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.
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.
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 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.)
Attachment #301716 - Flags: review?(philringnalda)
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.
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.
asac: any insight into why mozilla-thunderbird instead of simply thunderbird is used, and does bug 396209 change things regarding that?
(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.
Attachment #301719 - Attachment is obsolete: true
Attachment #301719 - Flags: review?
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.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: