In order to use DOMLocalization from C++ we need an XPIDL interface.
mozIDOMLocalization exposes the class and functionality allowing DocumentL10n to hook into it.
MozReview-Commit-ID: GPMhw61LPEg
--HG--
extra : rebase_source : 65d6e2b84379e78201f0c8b674630d1f485aaf8c
In order to use DOMLocalization from C++ we need an XPIDL interface.
mozIDOMLocalization exposes the class and functionality allowing DocumentL10n to hook into it.
MozReview-Commit-ID: GPMhw61LPEg
--HG--
extra : rebase_source : 65d6e2b84379e78201f0c8b674630d1f485aaf8c
In order to use DOMLocalization from C++ we need an XPIDL interface.
mozIDOMLocalization exposes the class and functionality allowing DocumentL10n to hook into it.
MozReview-Commit-ID: GPMhw61LPEg
--HG--
extra : rebase_source : 62d5909d9db8858c2ad1b4234d6f9b9be8da7efd
The changes affecting the docs include:
Rename of EXTERNAL_ARGUMENT to VARIABLE_REFERENCE
Addition of TERM_REFERENCE
Docs already talk about variable references, too.
MozReview-Commit-ID: KUwPSqJyBn0
--HG--
extra : rebase_source : d1b8b3aa42716ba9884422687c8ae8946805bb1f
Switch to cache FTLResources per FileSource. This allows us to minimize
the memory impact of dynamic additions/removals of l10n resources to
a context on fly.
MozReview-Commit-ID: B9fxbkaU3oX
--HG--
extra : rebase_source : bc268352965c721b5692f2062a063f7fba091136
`generateContextsForLocale` didn't have a condition for when `resolvedLength`
equals `resourcesLength` which triggeres an infinite recursion when `resourceIds` is
empty.
MozReview-Commit-ID: Csy1ROTfbE2
--HG--
extra : rebase_source : 587477279ed89bf17cd3243ae291222ecd9d34b4
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
Importing this object is unnecessary after the updates to the WebIDL console from Bug 1425574
and the follow-ups blocking Bug 1430810. There are still callers that access Console.jsm
to create custom ConsoleAPI objects, but those will be handled separately.
MozReview-Commit-ID: 9ojFxtkpPId
--HG--
extra : rebase_source : 971bf99f709b8d2afe300f3693665724f747aa5e
In order to allow localizations to produce different string depending on the
platform, we need to add a Gecko-specific built-in function to the MessageContext.
I'm explicitly listing the variables which we pass, rather than just passing the value
in order to ensure we don't start returning values we didn't plan for in case
the AppConstants.platform gets updated.
MozReview-Commit-ID: 1KZ6bf6zIY2
--HG--
extra : rebase_source : ce75c2c32bfb29b10b6ddbcaf6a71e2bf4cd4315
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b