405553 - make it so when updater.exe throws up the UAC prompt it is branded as "Firefox Updater" / "<brandShortName> Updater"

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[(not reading, please use [e-mail] instead)]

beltzner writes:

I'm sure I'm re-treading old ground here, but is there any way we can get updater renamed or presenting itself as Mozilla Product Updater or brandShortName Updater? 

rstrong wrote:

I believe we all we would need to change is the File Description which
is used in the UAC dialog when the binary has been signed. Nightly users
would just see updater.exe of course.

Comment 1

[Robert Strong (they/them - no direct email)]

(In reply to comment #0)
>...
> rstrong wrote:
> 
> I believe we all we would need to change is the File Description which
> is used in the UAC dialog when the binary has been signed. Nightly users
> would just see updater.exe of course.
I verified the statement above

Comment 2

[(not reading, please use [e-mail] instead)]

note, right now (with unsigned nightlies) it is branded as "updater.exe"

Comment 3

[Robert Strong (they/them - no direct email)]

note 2: if the binary isn't signed it will display the binary name otherwise it will display the file description.

Comment 4

[Benjamin Smedberg]

Note to self: just need a module.ver

Comment 5

[Benjamin Smedberg]

Attachment: Change module.ver, rev. 1

The "old ground" is bug 369125, where we made the description "Software Updater". This patch will make it use MOZ_APP_DISPLAYNAME. This has the unfortunate side effect of making "XULRunner software updater" when you're building XR apps, but I bet songbird will just patch it in any case.

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

You could maybe expose and use the xulrunner-stub-name value if it is set... although the case would be wrong probably.

Comment 7

[Benjamin Smedberg]

Well really for XR it should just be "Mozilla Software Updater" I think, or the current "Software Updater".

Comment 8

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

Comment on attachment 296960 [details] [diff] [review]
Change module.ver, rev. 1

I'd be keen with Mozilla Software Updater in the brandless case.

Comment 9

[Benjamin Smedberg]

Comment on attachment 296960 [details] [diff] [review]
Change module.ver, rev. 1

Huh, this got lost along the way.

Comment 10

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

Comment on attachment 296960 [details] [diff] [review]
Change module.ver, rev. 1

a1.9=beltzner

Comment 11

[Reed Loden [:reed]]

Checking in toolkit/mozapps/update/src/updater/module.ver;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/module.ver,v  <--  module.ver
new revision: 1.2; previous revision: 1.1
done

Comment 13

[Aakash Desai [:aakashd]]

We're only testing major updates on litmus, so this bug is out of the scope of the testgroup created there. Marked as in-litmus-

Comment 14

[Benjamin Smedberg]

Well we'd like it to end up in litmus, so renominating ;-)

Comment 15

[Aakash Desai [:aakashd]]

verified FIXED on builds via Windows XP:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729) ID:20090715094852

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090728 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090728045737

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2pre) Gecko/20090728 Shiretoko/3.5.2pre (.NET CLR 3.5.30729) ID:20090728050008


Also, https://litmus.mozilla.org/show_test.cgi?id=6714 was updated to reflect this bug.