Prior to the first patch for this bug, users with non-ascii characters
in the path to their profile directory got bad data in extensions.json.
With that bug fixed, now force a rebuild to rescue those users.
MozReview-Commit-ID: F3l87A67Ojc
--HG--
extra : rebase_source : d28322dafdcdff4dcc00e9b816f3f47b8f425de6
This is necessary before we enable the ESLint rule to require using
ChromeUtils for module imports rather than older methods.
MozReview-Commit-ID: mKqByUS0o2
--HG--
extra : rebase_source : d4b856aac7ff7eddc37cbf591c4e6522c45453e2
extra : histedit_source : 1ca2b6031e480fb44a15991241901224acc9e52f
When we detect a new add-on during a directory scan, we initially add a
skeleton XPIStates entry for it, and rely on the database reconciliation to
fill in the details later in startup. In the case of extensions with invalid
install.rdf files, though, this doesn't happen, and the entry remains as we
initially created it. Since those entries are currently marked enabled by
default, and the XPIStates entries determine what non-bootstrapped chrome
manifests we load at startup, that leads to us mistakenly loading resources
that we shouldn't.
This change marks newly-detected entries disabled by default, and leaves it to
later startup stages to enable them if necessary. We still leave the XPIStates
entry in place, since removing it would cause us to rebuild the database on
every subsequent startup, when we re-detect it.
MozReview-Commit-ID: AvBmj79Ro2W
--HG--
extra : rebase_source : a1b1f531406522d5ab51dd71f45d3c4d7f9331cf
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
Indeed, using zlib gives different results which mismatch with the one from
releng.
The next step would be to have releng use a zlib based solution.
MozReview-Commit-ID: LwxHk84Ajp4
--HG--
extra : rebase_source : 8f1570d4ff432232664012f97715d27eeba185da
Indeed, using zlib gives different results which mismatch with the one from
releng.
The next step would be to have releng use a zlib based solution.
MozReview-Commit-ID: LwxHk84Ajp4
--HG--
extra : rebase_source : 51d6efc5d3f84069e09f0e0c119118f1ea59dddf
This is a follow-up to bug 1409249. There are a lot of places where our
factory singleton constructors either don't correctly handle their returned
references being released by the component manager, or do handle it, but in
ways that are not obvious.
This patch handles a few places where we can sometimes wind up with dangling
singleton pointers, adds some explanatory comments and sanity check
assertions, and replaces some uses of manual refcounting with StaticRefPtr and
ClearOnShutdown.
There are still some places where we may wind up with odd behavior if the
first QI for a getService call fails. In those cases, we wind up destroying
the first instance of a service that we create, and re-creating a new one
later.
MozReview-Commit-ID: ANYndvd7aZx
--HG--
extra : rebase_source : acfb0611a028fef6b9387eb5d1d9e285782fbc7c
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
Bug 1024110 changed the WM class, and bug 1333826 removed the SDK and
the createdevel and related variables.
--HG--
extra : rebase_source : 599ab1998a5d6d471ab7928d782dde1c79ad4734
The nsGIOService now provides GetAppsForURIScheme which is used to append handlers
for specific scheme in handler list dialog (toolkit/mozapps/handling/content/dialog.js)
and also in Applications section in preferences. In case the default system handler
or user added handler has same name as one of the GIO handlers, the GIO handler
is not appended. The check for not adding handler is by using handler name.
The nsGIOMimeApp class now implements nsIHandlerApp interface. Instead overloaded
GetName methods (nsCString and nsString) we now use nsString variant everywhere.
This require change of nsGNOMERegistry::GetFromType which if fact leads to code
simplification.
The implementation of nsGNOMEShellService::SetDefaultBrowser has been changed
because implementation of CreateAppFromCommand has changed.
The CreateAppFromCommand no longer tries to find the application,
for that FindAppFromCommand has been introduced.
MozReview-Commit-ID: KmfFWRPqV3
--HG--
extra : source : 9660ff09c2212cb7456e50cb166752f42e0a0669
extra : amend_source : 3c5fc61fe09b9b68bdfbb9683335cedd4d706744
The nsGIOService now provides GetAppsForURIScheme which is used to append handlers
for specific scheme in handler list dialog (toolkit/mozapps/handling/content/dialog.js)
and also in Applications section in preferences. In case the default system handler
or user added handler has same name as one of the GIO handlers, the GIO handler
is not appended. The check for not adding handler is by using handler name.
The nsGIOMimeApp class now implements nsIHandlerApp interface. Instead overloaded
GetName methods (nsCString and nsString) we now use nsString variant everywhere.
This require change of nsGNOMERegistry::GetFromType which if fact leads to code
simplification.
The implementation of nsGNOMEShellService::SetDefaultBrowser has been changed
because implementation of CreateAppFromCommand has changed.
The CreateAppFromCommand no longer tries to find the application,
for that FindAppFromCommand has been introduced.
MozReview-Commit-ID: KmfFWRPqV3
--HG--
extra : rebase_source : 36d254cbc45cbe6929cc469cd531211f7ddd6a64
In the test of temporary installation of webextension experiments,
the test certificate shim code was marking the test addon as
privileged which allowed it to be loaded, fix that here.
MozReview-Commit-ID: IaZshrMNr3v
--HG--
extra : rebase_source : 34bcd94c6e687c63aadce7cb8d6b07a9ce525597
Zibi Braniecki
Andrew Swan
Gurzau Raul
Hector Zhao
Kris Maglione
Magnus Melin
Mike Hommey
Boris Zbarsky
Dustin J. Mitchell
Noemi Erli
Csoregi Natalia
Coroiu Cristina
Sylvestre Ledru
Narcis Beleuzu
Margareta Eliza Balazs
Martin Giger
Florian Quèze
Tiberius Oros
Myk Melez
Andreea Pavel
Jan Horak
Cosmin Sabou
Tom Prince
Sebastian Hengst
Dorel Luca
Robert Strong
Ting-Yu Chou