Closed Bug 273417 Opened 21 years ago Closed 21 years ago

Make toolkit code use the app id, app version, app buildid from nsXULAppAPI instead of requiring prefs.

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: benjamin, Assigned: benjamin)

Details

Attachments

(1 file)

We now have a scriptable interface version of nsXULAppAPI. To make app setup and bootstrap more sane, we shouldn't require the app id/version/buildid in prefs also. This patch fixes things.
Attachment #168049 - Flags: first-review?(darin)
Comment on attachment 168049 [details] [diff] [review] use nsXULAppAPI data >Index: toolkit/mozapps/plugins/content/pluginInstallerDatasource.js >+ var app = Components.classes["@mozilla.org/xre/app-info;1"] >+ .getService(Components.interfaces.nsIXULAppInfo); >+ this.appID = app.ID; >+ /* xxxbsmedberg: should this be geckobuildid? aren't plugins versioned per-gecko, not per-app? */ >+ this.buildID = app.appBuildID; yes, make it so :) >Index: toolkit/mozapps/plugins/content/pluginInstallerWizard.js >+ // xxxbsmedberg: should this be geckoBuildID intead of appBuildID? ditto >Index: toolkit/xre/nsAppRunner.cpp >+ id = {0,0,{0,0,0,0,0,0,0,0}}; memset(&id, 0, sizeof(id)); > NS_IMETHODIMP >+nsXULAppInfo::GetID(nsID** aResult) >+{ >+ *aResult = NS_Alloc(sizeof(nsID)); >+ if (!*aResult) >+ return NS_ERROR_OUT_OF_MEMORY; >+ >+ **aResult = gAppData->id; >+ >+ return NS_OK; >+} For interfaces that expose an nsID getter, we often provide a noscript version that returns a shared pointer (nsIInterfaceInfo::getIIDShared) r=darin with those changes
Attachment #168049 - Flags: first-review?(darin) → first-review+
Fixed on trunk, without the noscript iid-getter. We don't have any non-scripted callers yet, and it doesn't look likely that we will. I can add one later if necessary.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
http://lxr.mozilla.org/seamonkey/source/toolkit/xre/nsIXULAppInfo.idl#42 Right now the comment says it's unstable. Is there any timeline when this will be stable? SeaMonkey 1.8? Firefox 1.1? Or is this further out?
Yes, I intend to have a stable interface by 1.8/1.1, and it is likely that I will try to freeze it.
Cool. I could make good use of that appBuildID.
The patch seems to have ommited one gPref.getCharPref(PREF_EM_APP_VERSION) -> gApp.version ( http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in&rev=1.73#4256 )
Dorando, thanks for noticing that, I have fixed it also.
Flags: in-testsuite-
Component: XRE Startup → Startup and Profile System
QA Contact: nobody → startup
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: