Closed Bug 294543 Opened 16 years ago Closed 16 years ago

Reporter Doesn't get the Correct Product Name/Version

Categories

(Other Applications Graveyard :: Reporter, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: raccettura, Assigned: raccettura)

Details

Attachments

(1 file, 3 obsolete files)

Thanks to bug 274928, we now need to use
general.useragent.extra.firefox

They pulled the carpet out from under us by nixing
window.navigator.vendor+'/'+window.navigator.vendorSub

Patch coming
Attached patch Patch (obsolete) — Splinter Review
Patch

I'm not quite ready to drop 1.0 support yet.  Still may come in handy, so I'm
leaving that.
Attachment #183862 - Flags: review?(mconnor)
Comment on attachment 183862 [details] [diff] [review]
Patch

a=asa pending review.
Attachment #183862 - Flags: approval1.8b2+
Comment on attachment 183862 [details] [diff] [review]
Patch

r=me, but use Unknown or something like that is what we want, less jarring in
results if that case ever gets hit.
Attachment #183862 - Flags: review?(mconnor) → review+
Checking in extensions/reporter/resources/content/reporter/reportWizard.js;
/cvsroot/mozilla/extensions/reporter/resources/content/reporter/reportWizard.js,v
 <--  reportWizard.js
new revision: 1.13; previous revision: 1.12
done
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
We aren't done here, we get "unknown" way to often to be satisfied.  I need a
bonified way to get product/version.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The first block of code at the URL below gets the info you likely want:
http://lxr.mozilla.org/mozilla/source/extensions/irc/js/lib/message-manager.js#54

Note this only works in FF 1.1 and above, but I take it that's more than fine
for this.

As for Mozilla, not so sure on the "best" way...
Actually, if you only want the product /name/, the branding code below it will
be fine for suite as well - but it wont give you a version. :(
Version is critical for any layout use.  So that we can track regressions
between what effects 1.1 users, and say 1.5 users.
I guessed it probably was, but this bug is therefore incorrectly summaried. :P
Summary: Reporter Doesn't get the Correct Product Name → Reporter Doesn't get the Correct Product Name/Version
The Gecko version is the "rv:..." part of the UA string, no?  That's the part
you need for layout issues.
Makes me wonder why nsIXULAppInfo exposes the 2005nnnnnn number, and not the rv:
one.
darin or bsmedberg, do either of you know how we can reliably and easily get
accurate product/version information from our app?
chrome://global/content/build.dtd has the build id, in case you need it (may be
seamonkey only)
(In reply to comment #12)
> darin or bsmedberg, do either of you know how we can reliably and easily get
> accurate product/version information from our app?

I think best is to query nsIXULAppInfo for it, and if that fails, try to do some
hackery that gets us the Mozilla suite version info (basically name="Mozilla",
and I hope we're able to get the Gecko version somewhere - I guess the same
place that is used for assembling the UA string).
We currently try to get something working for future suite (SeaMonkey) in bug
294943 and it looks like we can go for a static JS implementation of
nsIXULAppInfo, so above way would work nicely with what is to come from our side
(as we just won't go into the failover then).
KaiRo's plan sounds good to me.
(In reply to comment #14)
> 
> I think best is to query nsIXULAppInfo for it, and if that fails, try to do some
> hackery that gets us the Mozilla suite version info (basically name="Mozilla",
> and I hope we're able to get the Gecko version somewhere - I guess the same
> place that is used for assembling the UA string).
> We currently try to get something working for future suite (SeaMonkey) in bug
> 294943 and it looks like we can go for a static JS implementation of
> nsIXULAppInfo, so above way would work nicely with what is to come from our side
> (as we just won't go into the failover then).

A few issues here:

1.  Detecting SeaMonkey isn't the problem.  AFAIK we have no SeaMonkey isn't
effected at all.  We can do that already using:
  if ('nsIChromeRegistrySea' in Components.interfaces) {}

2.  The #1 issue is getting the Firefox release version # in a way that won't die.

3.  Gecko version number is a separate issue.  When someone has a way of getting
that reliably (frozen method), open a bug against me with info on that, and
we'll add it in.  reporter is designed to handle it when it, we just don't use it.


Myk donated the following via a blog comment, but we still don't get the version
number (apparantly that's the worst issue):
var gAppName;
function getAppName() {
    if (gAppName)
        return gAppName;

    try {
        // Aviary 1.1 apps store application meta-data in the app info component.
        var appInfo =
          Components
            .classes["@mozilla.org/xre/app-info;1"]
              .getService(Components.interfaces.nsIXULAppInfo);
        if (appInfo &amp;&amp; appInfo.ID ==
"{3550f703-e582-4d05-9a08-453d09bdfdc6}") {
            gAppName = "Thunderbird";
            debug("determined application to be Thunderbird via nsIXULAppInfo");
            return gAppName;
        }
        debug("could not determine application via nsIXULAppInfo: " + appInfo);
    }
    catch(e) {
        debug(e);
    }
    
    try {
        // Aviary 1.0 apps store application meta-data in a preference.
        var id =
          Components
            .classes["@mozilla.org/preferences-service;1"]
              .getService(Components.interfaces.nsIPrefService)
                .getBranch("app.")
                  .getCharPref("id");
        if (id &amp;&amp; id == "{3550f703-e582-4d05-9a08-453d09bdfdc6}") {
            gAppName = "Thunderbird";
            debug("determined application to be Thunderbird via app.id pref");
            return gAppName;
        }
        debug("could not determine application via app.id pref: " + id);
    }
    catch(e) {
        debug(e);
    }

    // Non-aviary apps (f.e. Seamonkey) don't store application meta-data.
    debug("could not determine application; assuming Seamonkey");
    gAppName = "Seamonkey";
    return gAppName;

(In reply to comment #16)
Did you miss the code I linked to in comment 6? nsIXULAppInfo returns not only
the application name (you can use the ID if you like too), but the version,
*and* the gecko ID! (app.geckoBuildID)

That still leaves suite, but work is afoot in bug 294943 to add nsIXULAppInfo to it.
(In reply to comment #17)
> (In reply to comment #16)
> Did you miss the code I linked to in comment 6? nsIXULAppInfo returns not only
> the application name (you can use the ID if you like too), but the version,
> *and* the gecko ID! (app.geckoBuildID)

Was away for a few hours, and didn't reread the bug from the very beginning,
just the new stuff.  Yea, I see that...

> 
> That still leaves suite, but work is afoot in bug 294943 to add nsIXULAppInfo
to it.

I'm still not really crazy about using something unfrozen.  I'm leaning towards
avoiding it until it freezes.  

Right now I just want to get the app version # in Firefox 1.0 and later, and
SeaMonkey 1.8 and later.

I care about Gecko... just not at the moment.
Attached patch Patch v2 (obsolete) — Splinter Review
Attachment #183862 - Attachment is obsolete: true
Attachment #184157 - Flags: review?(benjamin)
From what I can tell, the new patch should correctly find:

Firefox 1.0 and later
SeaMonkey 1.8 and later
Status: REOPENED → ASSIGNED
Caveat: vendors are supposed to use "vendor" stuff.  So, you will get things
like "Fedora/1.0.4-1.3.1" etc for Fedora builds.  That was the whole point of
the patch to bug 274028.  So you may wish to query the extra.firefox stuff
first, then if that doesn't exist checking the vendor stuff, though that still
may not be as reliable as you like for seamonkey.
Attached patch Patch v3 (obsolete) — Splinter Review
Attachment #184157 - Attachment is obsolete: true
Attachment #184157 - Flags: review?(benjamin)
Attachment #184207 - Flags: review?(benjamin)
Comment on attachment 184207 [details] [diff] [review]
Patch v3

Same problem as with other patch: no need for "if (appInfo)" after getService.
Attachment #184207 - Flags: review?(benjamin) → review-
Attached patch Patch v3.1Splinter Review
Address review comment
Attachment #184207 - Attachment is obsolete: true
Attachment #184214 - Flags: review?(benjamin)
Attachment #184214 - Flags: review?(benjamin)
Attachment #184214 - Flags: review+
Attachment #184214 - Flags: approval-aviary1.1a1+
Attachment #184214 - Flags: approval1.8b2?
Comment on attachment 184214 [details] [diff] [review]
Patch v3.1

a=asa
Attachment #184214 - Flags: approval1.8b2? → approval1.8b2+
Checking in extensions/reporter/resources/content/reporter/reportWizard.js;
/cvsroot/mozilla/extensions/reporter/resources/content/reporter/reportWizard.js,v
 <--  reportWizard.js
new revision: 1.16; previous revision: 1.15
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.