As part of the normalization process for WebExtension API calls, we need to
extract and validate the full set of value properties (including properties
X-rays would normally deny access to) from cross-compartment objects. This
currently involves waiving X-rays, enumerating property descriptors, and
unwaiving X-rays - all through X-ray wrappers and waivers - and generating a
lot of expensive and short-lived wrappers in-between.
This helper reads out the list of safe properties from within the object's
compartment, and then copies them over to an object in the target compartment,
without any X-ray overhead, or any unnecessary intermediate wrappers or
compartment switches. It cuts about 40% off the overhead of our normalization
code.
MozReview-Commit-ID: H582oAYocaX
--HG--
extra : rebase_source : 7f7d5df605bc6544cb7f1c0c7e224d81b211e09c
extra : histedit_source : f980a03413b5e65fc6fa272c012a769d2764d89b
Like part a, but for `choices` messages rather than error messages.
MozReview-Commit-ID: 7dJ0NL2fUh5
--HG--
extra : rebase_source : 477f1364c0904bde78d54eae083bdb8e49ee5732
extra : histedit_source : 38c336b3a59481b6f2523798367159fb757c6485
For choices types, when one choice fails, we don't need the original error
string, since another choice may succeed, and we generate the final error
based on all of the options. Nevertheless, we spend a lot of time generating
JSON strings for the failed inputs in those cases, which adds up to about 12%
of the remaining overhead at this point.
MozReview-Commit-ID: 6nXBAv2W20V
--HG--
extra : rebase_source : 5894bc4b9e8d64ac9505f27240ea4fabfcb5f02f
extra : histedit_source : 0e8b5e0315abd672a57a60420453a1e0681c9df6
The Array and ArrayBuffer type checks we do in getBaseType add up to a
significant amount of overhead given the number of times we call them,
especially when X-ray overhead comes into play. These changes allow us to
avoid X-ray overhead altogether.
MozReview-Commit-ID: KlRuxeElIfp
--HG--
extra : rebase_source : c7f00fb8c35965476e7c7b888b6af36714c1323f
extra : histedit_source : fc559e665e60e9bbb688eebe6c6e6da5dacec748
In the code that I'm profiling, the XPC WrappedNative overhead of calling
these functions adds up to about a quarter of the time spent executing the
code. The overhead of the WebIDL versions is negligible.
MozReview-Commit-ID: 30qJy5RtP9d
--HG--
extra : rebase_source : 4fe73f4b9bde052a0eadf7d5634f792e16ca1c94
extra : histedit_source : ec61152a0181f3b0e28023c951e7181c43216d2f
Original issue is that Microsoft Dynamics CRM uses invalid lang attribute in <xsl:sort>.
<xsl:sort order="descending"
select="@displayname[$sortColumnName='displayname'] |
@name[$sortColumnName='name'] |
exslt:node-set($FriendlyTypeNames)/types/type[@xmlName=current()/@datatype and $sortColumnName='datatype']"
lang="$languageName"/>
Our XSLT implementation detects "$languageName" as locale name, then use it to nsICollation.
Until Gecko 54 for Windows, even if using invalid locale name for nsICollation, it uses platform locale as fallback. But from 55, we use same implementation as macOS's to use ICU. So this issue occurs. ICU implementation doesn't use fallback locale if it is invalid.
We should use fallback locale if locale is invalid. Most code for fallback locale such as FallbackEncoding uses application locale, so use it.
MozReview-Commit-ID: EKYkZG7Hnz0
--HG--
extra : rebase_source : fec89c67317d7df041f3b237122fb7e20e32fe1b
This prevents naming conflicts if a paused or blocked download is retried from the original page.
MozReview-Commit-ID: 4rFZ5rP8saJ
--HG--
extra : rebase_source : c392fc62cb33b2c2d70a1c3a8a975ddf93d394ea
Per mixed-content-blocked spec, [1], <img srcset> and <picture> should
be blocked. However we still fetch <img srcset> and <picture> in image
preload, because they are fetched with contentPolicyType
TYPE_INTERNAL_IMAGE_PRELOAD and won't be rejected by nsMixedContentBlocker.cpp.
So I updated the image preloading code, and use the type TYPE_IMAGESET
if the image request is for <picture> or <img srcset>, otherwise for
normal image load we still use TYPE_INTERNAL_IMAGE_PRELOAD.
[1]: https://w3c.github.io/webappsec-mixed-content/#should-block-fetch
4. Return allowed if one or more of the following conditions are met:
request’s type is "image", and initiator is not "imageset".
5. Return blocked.
As we already do security check in asyncOpen2 in bug 1206961, also
we've removed calling nsContentUtils::CanLoadImage() in bug 1267075, so
here we do the same thing for nsDocument.
