A significant chunk of migration jank that I observe locally
happens due to login encryption. This patch reduces the locally
observed jank (measured importing 100 logins) from 180ms to 25ms.
Try is green, and as far as I can tell I don't see any thread
safety issues, but I'm not 100% sure on that. I don't see any
red flags inside the SecretDecoderRing::Encrypt implementation.
I only moved Chrome logins over since I wanted to frontload any
potential issues with the whole approach. It shouldn't be too
hard to move the MSMigrationUtils and IEProfileMigrator uses
over though.
MozReview-Commit-ID: 75edUqJlk8x
--HG--
extra : rebase_source : 0a8e16c46e05972fb01c9703b52cdb5755b0b40b
Since encryption can be somewhat CPU intensive, if we're encrypting
a large number of strings we want to be able to do so in a background
thread. This will be consumed by the profile migrators when importing
logins.
MozReview-Commit-ID: JoJGOgMzZ4u
--HG--
extra : rebase_source : 4677482b4e9b1df7c7ca70a0e817204ef6638cdf
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
With emulated flex display we wrap inline-level children into anonymous
wrapper-blocks, and those wrapper blocks serve as the flex items. Using
display: block and then resetting the hardcoded width/height does the trick.
MozReview-Commit-ID: Grh1KsSmngP
--HG--
extra : rebase_source : d0792b19387e50d7c70a50a741c060655d4a3669
There are still known issues with the browser chrome when emulating, but this changeset is
done in service of getting the UI to be close enough to start running Talos tests against
it in Bug 1425330.
MozReview-Commit-ID: B0w1aOmi4FJ
--HG--
extra : rebase_source : e8b13f9203f0e368fb6f36bc9d2059fff7061b54
This is a short-term solution to our inability to apply CSP to
chrome-privileged documents.
Ideally, we should be preventing all inline script execution in
chrome-privileged documents, since the reprecussions of XSS in chrome
documents are much worse than in content documents. Unfortunately, that's not
possible in the near term because a) we don't support CSP in system principal
documents at all, and b) we rely heavily on inline JS in our static XUL.
This stop-gap solution at least prevents some of the most common vectors of
XSS attack, by automatically sanitizing any HTML fragment created for a
chrome-privileged document.
MozReview-Commit-ID: 5w17celRFr
--HG--
extra : rebase_source : 1c0a1448a06d5b65e548d9f5362d06cc6d865dbe
extra : amend_source : 7184593019f238b86fd1e261941d8e8286fa4006
This adds a dignostic assertion that the name pointer is actually within the
static name table.
--HG--
extra : rebase_source : 4f82f72c83444a3ccd5be270080837f60110766e
This switches from `nsDependentCString` to `nsLiteralCString` when adding
histograms to the table. It will help save some memory and should avoid the OOM
smalls we have been seeing.
--HG--
extra : rebase_source : b59725b1ffa40353d4dd5b3016d201b8a65325d4
Don't use the parent node options when creating new folder nodes, since they should retain
their original options.
Additionally, we can filter nodes in the queries rather than building a lot of nodes that
will be filtered out.
MozReview-Commit-ID: MmlGDe5QgV
--HG--
extra : rebase_source : 66eea325825007266e08424630b092b9e8d75b67
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
This patch also adds the capitalization patch file to the chromium patches
MozReview-Commit-ID: BzAkEtCKAi4
--HG--
extra : rebase_source : 8f24d2b855e721f354f12b0d3fca5783cc66702e