Closed Bug 972872 Opened 6 years ago Closed 6 years ago

[mozversion] Allow to retrieve the application code name (Nightly / Aurora / Firefox)

Categories

(Testing :: Mozbase, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla30

People

(Reporter: cosmin-malutan, Assigned: andrei)

References

Details

Attachments

(1 file, 3 obsolete files)

This blocks bug 911257, where I need the application title so I can set it as a default application in order to ran testruns on metro.
The official brand name is kept in a browser.dtd so we won't get proper results mapping the brand name against the source branches.

We'll probably need to read it from the dtd file.

See for example:
http://mxr.mozilla.org/l10n-mozilla-aurora/search?string=brandShortName&find=brand.dtd&findi=&filter=%5E%5B%5E%5C0%5D*%24&hitlimit=&tree=l10n-mozilla-aurora

I'll install and some localised builds in Metro to confirm that we will actually need this.
We're safe. Tested an `ar` build where the name is localised, but we're getting the default names in the Default Programs on metro. Tested with both an Aurora and a Beta build.

Se the mapping we need is:
mozilla-release > Firefox
mozilla-beta > Firefox
mozilla-aurora > Aurora
mozilla-central > Nightly
Please keep in mind that you cannot blindly assume that the given branch has always this specific name. Also it would fail for project builds, and other gecko based applications. So we cannot do a mapping from the hg branch. This path doesn't look correct to me.
OS: Linux → All
Hardware: x86_64 → All
(In reply to Henrik Skupin (:whimboo) from comment #4)
> Please keep in mind that you cannot blindly assume that the given branch has
> always this specific name. Also it would fail for project builds, and other
> gecko based applications. So we cannot do a mapping from the hg branch. This
> path doesn't look correct to me.

Right.

So I have a working patch, also added tests. But exactly as you say this is limited as it will fail getting the proper Brand Name for any builds that have been build from another tree (like UX or Holly).

Any ideas where we could get the Brand Name from at this low level?
(In reply to Andrei Eftimie from comment #5)
> Any ideas where we could get the Brand Name from at this low level?

As you already have mentioned above, you can get it from brand.dtd.
Unfortunately this doesn't work.
Windows doesn't use the name from brand.dtd for the Application Name.

It appears to use VisualElementsManifest.xml
I've been able to customise its name by changing the name from this XML file.

But I wasn't yet able to have this work consistently.
Windows caches previously used entries in the select Default App modal dialog.

I've customised the both brand.dtd and VisualElementsManifest.xml to get a custom name.
I've managed to get a custom name in both the modal set Default Application and in how Firefox sees itself (Help > About Custom Name).

But in the windows Set Default Programs window its still called Aurora.

==

Given all this I'm not sure _where_ to take the name from.
VisualElementsManifest.xml is only available on Windows builds, so we might not want to take this as a general way, and only affects the name in _some_ places.
brand.dtd affects the name in other places, but not where wee need it.
(In reply to Andrei Eftimie from comment #7)
> Unfortunately this doesn't work.
> Windows doesn't use the name from brand.dtd for the Application Name.
> 
> It appears to use VisualElementsManifest.xml

So what does it use instead? You missed to specify what you are actually seeing. The information above doesn't help a lot if you are seeking for further input.
(In reply to Henrik Skupin (:whimboo) from comment #8)
> So what does it use instead? 

That's the problem. I haven't found exactly where the name of the running application is taken from.

VisualElementsManifest.xml is out, this is only available under Windows.
This name _is_ used for the Metro interface, (and the select Default Application modal window).
But we apparently don't care for this as we use the window located in `Control Panel\All Control Panel Items\Default Programs\Set Associations` to check our selection.

===

We might use brand.dtd.
The locales that cusomize it appear to no longer be build:
http://mxr.mozilla.org/l10n-mozilla-aurora/search?string=brandShortName+&find=chrome%2Fbranding%2Fbrand.dtd&findi=&filter=%5E%5B%5E%5C0%5D*%24&hitlimit=&tree=l10n-mozilla-aurora
(see only those entries under `browser`, due to some limits in mxr couldn't easily filter only these)

These are the affected locales: ne-NP, nr, ss, st, ts, ve
But none have any recent builds available.

So we _might_ use that. If some locale will customize it we will fail to properly detect this.

---

If we'll go trough the brands.dtd route, I'm not sure how to check this file.
We are closee to the metal here, so we can't use any Service. We'll need to manually take the omni.ja file, extract it in a temp location, take the /chrome/%locale%/branding/brand.dtd file and parse it.

I'm not sure that this is a good approach either.
Depends on: 949600
Attached patch WIP v1 patch (obsolete) — Splinter Review
This is a WIP patch based on the last idea in comment 9

It doesn't work out of the box since python's zipfile module isn't able to extract omni.ja (this fails with `zipfile.BadZipfile: Bad magic number for central directory`)

It does work if you manually extract and recompress omni.ja
We correctly retrieve the shortBrandName from brands.dtd

I still have todo:
- find a way to extract omni.ja (this is a blocker)
- write some tests
- cleanup/tidy the code & add some exception handling
- rebase this on top of mozilla-central once bug 949600 is done
Assignee: nobody → andrei.eftimie
Status: NEW → ASSIGNED
Attachment #8378305 - Flags: feedback?(hskupin)
Benjamin and Michael, would you have some alternatives in mind how to fetch the brand name of a Firefox build without finding workarounds to unzip the omni.ja file (which has a broken zip header)? We need the brand name for bug 911257 to set Firefox as default browser via AutoIT.
Flags: needinfo?(mwu)
Flags: needinfo?(benjamin)
Could we just produce an extra file during packaging that contains the brand name? If we don't ship it, that seems like the easiest solution.

We have code in python/mozbuild/mozpack/mozjar.py that can read file content from omni.ja. That's how we do repacks :)

Switching needinfo to glandium, who knows this field better than everyone.
Flags: needinfo?(benjamin) → needinfo?(mh+mozilla)
(In reply to Gregory Szorc [:gps] from comment #12)
> We have code in python/mozbuild/mozpack/mozjar.py that can read file content
> from omni.ja. That's how we do repacks :)

That sounds great. But then it would need to become part of mozbase. Not sure if that's easily doable or what other pros and cons it has.
(In reply to Henrik Skupin (:whimboo) from comment #13)
> That sounds great. But then it would need to become part of mozbase. Not
> sure if that's easily doable or what other pros and cons it has.

Probably not possible given all the dependencies to mozbuild.
(In reply to Gregory Szorc [:gps] from comment #12)
> Could we just produce an extra file during packaging that contains the brand
> name? If we don't ship it, that seems like the easiest solution.

Sorry, but I missed that part. So we would need a solution for any kind of build, which also includes beta and release builds.
(In reply to Gregory Szorc [:gps] from comment #12)
> Could we just produce an extra file during packaging that contains the brand
> name? If we don't ship it, that seems like the easiest solution.

We already have a file containing related info: application.ini. Let's just use it.
Attachment #8378669 - Flags: review?(benjamin)
With that patch, you just need to read App.CodeName from application.ini, or App.Name is App.CodeName is not present.
Flags: needinfo?(mh+mozilla)
Thanks Mike.  That sounds great. But I think the patch should have been uploaded to a separate bug given that this bug is part of our mozbase work. Would you mind filing a new one?
Attachment #8378669 - Attachment is obsolete: true
Attachment #8378669 - Flags: review?(benjamin)
Filed bug 974830
Depends on: 974830
Comment on attachment 8378305 [details] [diff] [review]
WIP v1 patch

Review of attachment 8378305 [details] [diff] [review]:
-----------------------------------------------------------------

It would have been great if a new patch would be up here given the recent changes. Please follow-up ASAP.
Attachment #8378305 - Flags: feedback?(hskupin)
Added support for the new CodeName information available in application.ini
Also added support for it in the test_binary.py test.

Running mozversion against a recent tinderbox build yields:
> application_buildid: 20140221004327
> application_changeset: 05a5f08f1278
> application_code_name: Nightly
> application_name: Firefox
> application_repository: https://hg.mozilla.org/integration/mozilla-inbound
> application_version: 30.0a1
> platform_buildid: 20140221004327
> platform_changeset: 05a5f08f1278
> platform_repository: https://hg.mozilla.org/integration/mozilla-inbound
Attachment #8378305 - Attachment is obsolete: true
Attachment #8379659 - Flags: review?(hskupin)
Comment on attachment 8379659 [details] [diff] [review]
0001-Bug-972872.-Added-support-for-the-new-CodeName-infor.patch

Review of attachment 8379659 [details] [diff] [review]:
-----------------------------------------------------------------

Only a nit here to fix. Also please make sure to bump the version of the package. So we can directly release a new version which will unblock us. r=me with the requested changes.

::: testing/mozbase/mozversion/mozversion/mozversion.py
@@ +50,1 @@
>                                  'SourceStamp': 'changeset'}

While we are on it, the name_map definition can be moved out of the for loop. We don't have to re-create it each time.
Attachment #8379659 - Flags: review?(hskupin) → review+
Flags: needinfo?(mwu)
Summary: [mozversion] We need to be able to retrieve the application title Ex(Nightly/Aurora/Firefox) → [mozversion] Allow to retrieve the application code name (Nightly / Aurora / Firefox)
Bumped version to 0.2 and moved the map out of the loop. (we could actually moved it out further, but I think its good  to keep it close to the place it gets used)
Attachment #8379659 - Attachment is obsolete: true
Attachment #8379671 - Flags: review?(hskupin)
Released version 0.2 to pypi:

Submitting dist/mozversion-0.2.tar.gz to http://pypi.python.org/pypi
Server response (200): OK
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Keywords: leave-open
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.