Closed Bug 324758 Opened 18 years ago Closed 15 years ago

Updater should use brand name string and not hardcode Firefox

Categories

(Toolkit :: Application Update, defect)

defect
Not set
minor

Tracking

()

VERIFIED FIXED
mozilla1.9.1b4

People

(Reporter: bugzilla, Assigned: robert.strong.bugs)

References

Details

(Keywords: late-l10n, verified1.9.1)

Attachments

(2 files, 2 obsolete files)

I'm running nightly build so that's Deer Park. But when I get the update from the update channel and the update is applied it says "Firefox is updating".
So perhaps the dialog isn't using the correct appname term?
Severity: normal → minor
Version: unspecified → Trunk
shouldn't updater.ini be updated to that it doesn't contain a hardcoded product name?
If somebody wants to write the patch, sure... it's certainly not a priority.
*** Bug 334852 has been marked as a duplicate of this bug. ***
Summary: software update talks about Firefox not Deer Park → Updater should use brand name string and not hardwire Firefox
Something like this?

# browser/locales/en-US/updater/updater.ini.in
; This file is in the UTF-8 encoding
[Strings]
Title=Software Update
Info=@MOZ_APP_DISPLAYNAME@ is installing your updates and will start in a few mo                            ments ...

# configure.in
AC_OUTPUT(browser/locales/en-US/updater/updater.ini)
*** Bug 345596 has been marked as a duplicate of this bug. ***
Summary: Updater should use brand name string and not hardwire Firefox → Updater should use brand name string and not hardcode Firefox
Version: Trunk → 2.0 Branch
(In reply to comment #5)
> Something like this?
> 
> # browser/locales/en-US/updater/updater.ini.in
> ; This file is in the UTF-8 encoding
> [Strings]
> Title=Software Update
> Info=@MOZ_APP_DISPLAYNAME@ is installing your updates and will start in a few
> mo                            ments ...
> 
> # configure.in
> AC_OUTPUT(browser/locales/en-US/updater/updater.ini)

I don't think that will actually work with different locales.  You might need to change that to a %S and then set the displayname somewhere else that the updater code can get to it, then use sprintf to format the string.

It's possible that there's an easier way to do it, though.

OS: Windows XP → All
Hardware: PC → All
Product: Firefox → Toolkit
Attached patch patch rev 1Splinter Review
This fixes this bug for me on 1.9.0.x (the patch is against the trunk)... I only tested this on 1.9 since I have an l10n setup for for it and haven't set one up for hg yet.
Assignee: nobody → robert.bugzilla
Attachment #349065 - Flags: review?(ted.mielczarek)
Attachment #349065 - Attachment is obsolete: true
Attachment #349065 - Flags: review?(ted.mielczarek)
Comment on attachment 349065 [details] [diff] [review]
patch rev 1

Forgot to include changes for Linux and Mac
Comment on attachment 349065 [details] [diff] [review]
patch rev 1

I forgot we have a brain dead parser for ini files for Linux and Mac so this should be fine
Attachment #349065 - Attachment is obsolete: false
Attachment #349065 - Flags: review?(ted.mielczarek)
Attachment #349065 - Flags: review?(ted.mielczarek) → review+
Since this only affects nightly builds and requires a string change this should be landed (along with equivalent changes for other apps) after 3.1
Target Milestone: --- → mozilla2.0
Axel, this patch will change the l10n updater.ini file. How would you like to handle this change? Is it already checked in compare-locales? I could add a check to the existing verification of the installer l10n files if you like.
This should be fine as is, we already handle .ini files in compare-locales, at least the python versions handle it fine. And the perl versions aren't called into anymore anyway.
Attached patch comm-central patch (obsolete) — Splinter Review
Attachment #351084 - Attachment is obsolete: true
Comment on attachment 351087 [details] [diff] [review]
comm-central patch

Ause, could you review the SunBird portion of this patch? Thanks
Attachment #351087 - Flags: review?(ause)
Comment on attachment 351087 [details] [diff] [review]
comm-central patch

Phil, could you review the Thunderbird and Seamonkey portions of this patch? Thanks
Attachment #351087 - Attachment description: comm-central patch (not tested yet) take 2 → comm-central patch
Attachment #351087 - Flags: review?(philringnalda)
Comment on attachment 351087 [details] [diff] [review]
comm-central patch

Without incriminating myself about any times I may or may not have pretended to be able to do simple build config or installer reviews for SeaMonkey, let's have mcsmurf do the SM third of one, for the review trifecta.
Attachment #351087 - Flags: review?(bugzilla)
Mmm, this needs to be ifdeffed, since comm-central "trunk" is currently building against 1.9.1 rather than mozilla-central. Sadly, I don't actually know ifdef *what*, though.
Attachment #351087 - Attachment is obsolete: true
Attachment #351087 - Flags: review?(philringnalda)
Attachment #351087 - Flags: review?(bugzilla)
Attachment #351087 - Flags: review?(ause)
Phil, I can hold off for now if comm-central is going to move over soon or just change Info to InfoText and leave the hardcoded brandShortName. Are there plans to have comm-central build off of 1.9.1?
After asking Standard8 what I think, I think the best thing to do is to keep the Info string, add the InfoText string, and ifdef the Makefile.in lines, just as soon as someone figures out a convenient way to define MOZILLA_1_9_1_BRANCH in comm-central's configure.in if MOZILLA_VERSION starts with "1.9.1". Then once we branch comm-central, we can take out the Info string on the trunk (though we'll probably be string-frozen by then, and stuck with shipping the unused InfoText string in the 1.9.1 releases).
Version: 1.8 Branch → Trunk
Depends on: 467878
We now have comm-central building on 1.9.1 and we have MOZILLA_1_9_1_BRANCH.

Although all I think needs to be done here is to put both Info and InfoText in the locale file and just add a comment saying something along the lines of:

Info is only required for the MOZILLA_1_9_1_BRANCH

Then once we get to branching, we can clean up.
iirc the ini parser used for Mac OS X and Linux by the updater is extremely simplistic in that it relies on the position of the string in updater.ini and then just uses the string after the = sign. So, it will take a bit more than that. :(
The patch in bug 399153 makes all platforms use readstrings so changes to the names for the strings (e.g. Title and Info) no longer requires changes to progressui_win.cpp to reflect these changes. This means that each app will be able to fix this bug in the same way as I will be fixing it for Firefox at any time they choose so I'm removing the dependency on bug 467878.

I'll fix this on mozilla-central after bug 399153 lands.
Depends on: 399153
No longer depends on: 467878
With the changes made to progressui_win.cpp by the landing of bug 399153 the progressui_win.cpp changes are no longer needed to fix this.
Attachment #356140 - Flags: review+
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/6128896b6f98
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: mozilla2.0 → mozilla1.9.2a1
Attachment #356140 - Flags: approval1.9.1?
Comment on attachment 356140 [details] [diff] [review]
patch - as checked in

Bah, forgot this one
Comment on attachment 356140 [details] [diff] [review]
patch - as checked in

a191=beltzner
Attachment #356140 - Flags: approval1.9.1? → approval1.9.1+
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b4
verified FIXED on builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090413 Minefield/3.6a1pre ID:20090413031052

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shiretoko/3.5b4pre ID:20090413031313
Status: RESOLVED → VERIFIED
ack, here's the build ID for Shiretoko Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shiretoko/3.5b4pre ID:20090413031313
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: