toolkit/mozapps/update

firefox-main/toolkit/mozapps/update

	Name	Description	Size	Coverage
	AppUpdater.sys.mjs	`AbortablePromise`s automatically add themselves to this set on construction and remove themselves when they settle.	30848	80 %
	background_task_metrics.yaml		15375	-
	BackgroundTask_backgroundupdate.sys.mjs	Verify that pre-conditions to update this installation (both persistent and transient) are fulfilled, and if they are all fulfilled, pump the update loop. This means checking for, downloading, and potentially applying updates. @param {object} Optional parameters {boolean} checkOnly If specified as `true`, checks for updates but does not download them unless a flag from Balrog specifically overrides this behavior. @returns {any} - Returns AppUpdater status upon update loop exit.	24182	43 %
	BackgroundUpdate.sys.mjs	Whether this installation has an App and a GRE omnijar. Installations without an omnijar are generally developer builds and should not be updated. @returns {boolean} - true if this installation has an App and a GRE omnijar.	43708	69 %
	common			36 %
	components.conf		1388	-
	content			92 %
	docs			-
	jar.mn		611	-
	metrics.yaml		58326	-
	moz.build		1348	-
	nsIUpdateService.idl	An interface that describes an object representing a patch file that can be downloaded and applied to a version of this application so that it can be updated.	40038	-
	nsUpdateService.manifest		143	-
	pings.yaml		1591	-
	shared_metrics.yaml		5902	-
	shared_pings.yaml		2779	-
<1%	tests			26 %
	UpdateListener.sys.mjs		18223	76 %
	UpdateLog.sys.mjs	Update logging lives in its own module for several reasons. First, it avoids having some very similar logging code duplicated in several places. And second, we only want to open the update messages file once. Opening it multiple times from multiple files does not result in all those messages ending up in the same log file. Note that simply importing this module can cause the value of the `app.update.log.file` pref to change. This may seem a bit weird, but we are going to consider it to be acceptable because any other module that wants to interact with that pref really ought to be doing it by interacting with this module instead, making the pref more of an internal implementation detail. This option was chosen over doing this work more lazily (say, on a log message) because this initialization step has user-visible consequences (the log file moves) and we'd prefer that those happen close to startup so that the user doesn't observe it happening at a seemingly random time.	6552	54 %
	updater			54 %
	UpdateService.sys.mjs		256245	76 %
	UpdateServiceStub.sys.mjs	See nsIUpdateService.idl	16116	44 %
	UpdateTelemetry.sys.mjs	Values for the Glean.update.checkCodeNotify and Glean.update.checkCodeExternal custom_distribution metrics.	21940	75 %

Revision control

Other Tools