WindowWatcher allows for either nsIArray or nsISupports array to be passed in
for the arguments param. This converts all internal usage to nsIArray.
MozReview-Commit-ID: DQjtIkobik0
Upload symbols when --enable-artifact-build-symbols is specified.
Add --enable-artifact-build-symbols to artifact config for linux, linux64,
win32, win64, macosx64.
MozReview-Commit-ID: LpuwfzWXPBH
--HG--
extra : rebase_source : 137466aa3c8c327cf1932e012927fceb451d82ab
This introduces LoginFormFactory which wraps FormLikeFactory for use with login-specific contexts.
MozReview-Commit-ID: 6rPz5JOy3Yp
--HG--
rename : toolkit/components/passwordmgr/LoginManagerContent.jsm => toolkit/modules/FormLikeFactory.jsm
extra : rebase_source : b2a28803def0dce3de4a01db5bdbc3217c5d0f83
Actually, we don't turn of xinput2 on content process. So, although chrome process cannot detect touch screen device, content process can detect it.
So if we turn off xinput2 on chrome process, content process should be turned off.
MozReview-Commit-ID: 1kfsDBpqhC1
--HG--
extra : rebase_source : 6fc8ccb1b15065fc9ba0a25ddd934adc3bf21c6b
Currently, we use the gzip default of 6. Our history with zlib tells
us that reducing the compression level to 5 or 4 often yields
significantly faster operations while only sacrificing a little
storage. Measurement here shows similar results.
On libxul.so.dbg:
level time compressed
6 21.0s 231,045,158
5 15.8s 232,926,435
4 12.2s 237,587,011
3 11.1s 245,104,157
Changing the level from 6 to 4 increases the size of the compressed
file by 6,541,853 bytes, or 2.83%. But it saves ~10s from the long
pole of builds in automation. And that's just from libxul.
When you factor in all compressed files, this change has a significant
impact on symbol generation.
Before: 221s wall; 150s CPU; 311,424,856 bytes
After: 192s wall; 130s CPU; 318,085,885 bytes
That's on my machine, which has a 4.0 GHz CPU. CPU time savings in
automation will likely be more significant.
MozReview-Commit-ID: 7CbRSZvUayj
--HG--
extra : rebase_source : 87c33d6bb57c9a43613800ca13d91a54f5a95317
`makeFilteringListener` uses the listener as a key for a WeakMap, so we
cannot blindly use the listener as a WeakMap key. addEventListener and
removeEventListeer only accept objects/functions (and undefined/null),
so not wrapping will lead to a descriptive error message from
addEventListener/removeEventListeer.
MozReview-Commit-ID: HF2WAyXDeD9
--HG--
extra : rebase_source : 5574c118cf0881ddc1477ceeb1b9c979814d67d6
In our current Rust world, we have the following dependency structure:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust
|
+--> gkrust-gtest
This structure results in link errors with multiply-defined symbols
between gkrust-gtest and gkrust with newer Rust releases when linking
xul-gtest.so. So we have to do something different.
Our new structure is:
xul.so --------------------------+
|
xul-gtest.so -+--> xul.a --------+-> gkrust --+-> gkrust-shared
| |
+--> gkrust-gtest --------------+
and we enforce that a given shared library can only have at most one
Rust library that it depends on. Said Rust library is assumed to
include all significant Rust dependencies of the dependent static
libraries as well. (In the above structure, gkrust is simply a wrapper
around gkrust-shared, so gkrust-gtest doesn't have to include gkrust as
a dependency.)