This is to fix the case where preference is restore to false when a testcase
ends, but nsDocument::DeleteShell is called afterwards. So, we make the
preference per-doc and set it when the document is created. The value does not
change for the lifetime of the document.
This is to fix the case where preference is restore to false when a
testcas ends, but nsDocument::DeleteShell is called afterwards. So, we
make the preference per-doc and once it is enabled for a document, it
stays enabled.
There's nothing preventing the flat tree from changing while the document
doesn't have a shell. In that case, we really really don't want to lose track
of elements with stale style data, since then we'll mess up.
It's ok to _not_ clear the style data when the document goes into the BFCache
though, because the document is thrown away if other document runs script and
touches the cached DOM.
MozReview-Commit-ID: 4W3xDAnnLPL
This flag would be used to help us decide whether website could be allowed the autoplay.
The media related implementation would be implemented in bug1382574.
MozReview-Commit-ID: GGIauBufs5A
--HG--
extra : rebase_source : c407ceed311fc3fb0140e5da44fd69e457a5098f
Add a new member mAllowPaymentRequest on nsIDocument and following related
methods,
bool AllowPaymentRequest() const
void SetAllowPaymentRequest(bool aAllowPaymentRequest)
mAllowPaymentRequest is used to check if PaymentRequest is allowed to use on
the document. According to the spec
https://html.spec.whatwg.org/multipage/iframe-embed-object.html#allowed-to-use
the mAllowPaymentRequest should be true under following situations
1. The document is the top level content document.
2. The document is the same origin with its parent document and its parent
document's mAllowPaymentRequest is true.
3. The document is different origin with its parent document but its
parent node is an iframe with allowpaymentrequest flag and the parent
document's mAllowPaymentRquest is true.
This patch also include following mochitests
1. test for allowpaymentrequest flag changing. The flag change effect should
not be applied to the document immediately, it should be updated while
the browsing context is updated.
2. test for effect propagation in the nested iframe.
Per spec, document objects have a throw-on-dynamic-markup-insertion counter,
which is used in conjunction with the create an element for the token algorithm
to prevent custom element constructors from being able to use document.open(),
document.close(), and document.write() when they are invoked by the parser.
--HG--
extra : rebase_source : 7cbc10c77765b84bbaf07a05f205f02169a79ee0
Since the presence of an entry with a null selector is different for Gecko and
Servo, this seemed easier, and mimics nsLayoutStyleSheetCache.
Also, this is going away soon anyway as soon as I get to implement the rest of
the methods for stylo.
MozReview-Commit-ID: DtHJbw8C0GX
--HG--
extra : rebase_source : dd450a6972054971eba8bba5bb022b74d07c2a0b
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This flag indicates that document can flush parent-document only or need to do
the normal flushing.
MozReview-Commit-ID: L9KZA6jNsOz
--HG--
extra : rebase_source : ac794a5dbcd4aab8d691ebcc3804ec208755a716
Right now every document in a docshell makes a copy of the list. In practice,
this list is usually pretty short (limited by depth of iframe nesting), so this
is probably not a problem. We could add a bit of complexity and have a
refcounted struct that contains the list... I wish we had something as simple
as Rust's Arc that we could use here.
MozReview-Commit-ID: 8jGIlkhp1DU
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.
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
nsTextFrame stores text as single byte character array if all characters are
less than U+0100. Although, this saves footprint, but retrieving and modifying
text needs converting cost. Therefore, if it's created for a text node in
<input> or <textarea>, it should store text as char16_t array.
MozReview-Commit-ID: 9Z82rketT7g
--HG--
extra : rebase_source : 59f59ac1488c21a57d95d253cc794a011d672c95
Our current machinery for enabling stylo requires a docshell - if there isn't
one, we default to the Gecko style system.
When getComputedStyle operates on an element without a presshell, it uses the
caller's presshell instead. If the element has previously been styled with
one style system (but no longer has a presshell), and the caller uses a
different style backend, using the caller's style system can cause crashes when
we pull bits of cached data off the DOM (like cached style attributes).
So we want to throw when window.getComputedStyle(element) is called for a
(window, element) pair with different style backends (which is what the next
patch in this bug does).
However, that causes a few failures where stylo-backed documents try to do
getComputedStyle on an XHR document (which, without a docshell, will use the
gecko style system).
So this patch does some work to propagate the creator's style backend into
various docshell-less documents. This should allow both chrome (which uses gecko)
and content (which uses stylo) to use getComputedStyle on the response document
for XHRs they create.
Note that the second patch in this bug will make
chromeWin.getComputedStyle(contentObj) throw. If we discover code that does
that, we can just make it invoke the content's getComputedStyle method over Xrays.
MozReview-Commit-ID: 5OsmHJKq5Ui
