If ComputedValues.custom_properties differs between the old and new
ComputedValues, indicate that we have to propogate changes to
descendants by setting child_cascade_requirement to
MustCascadeDescendants in cascade_primary.
style::matching::TElement::cascade_primary already calls
accumulate_damage, which eventually calls
ServoRestyleDamage::compute_style_difference in order to check if other
properties' computed values changed. If any of those change, we signal
that we need to propogate changes for inherited properties.
With Properties & Values, some custom properties will not be inherited,
and we will need to revisit this.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#17283
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 81275234aa225d1011bad7eca126af800ff0d4fc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4bf31d42c75dfd84f06e4545bbac6df70739e356
It appears that neither Chrome, Safari or Edge support this feature,
and it's causing web-compat issues for us, e.g. bug 1373417.
MozReview-Commit-ID: AP5LMgL6QmR
We test the expected behavior base on the pref,
"security.data_uri.unique_opaque_origin".
We run the legacy test when the pref is off, however if the pref is on,
we run the new behavior, loading an iframe with X-FRAME-OPTIONS in a
data: URI should be blocked.
Move the data URI in 'if_no_scripts' and 'if_scripts' to seperate files.
Also remove the test 'if_19', as it seems redundant, it tests the same
thing with the iframe 'if_scripts', and it also lacks of 'allow-scripts'
in its sandbox flag.
A mochitest browser test for image blocking.
We query the blocking status by reading imageBlockingStatus.
See nsImageLoadingContent.cpp for the logic of blocking image.
In this test we verified the following behavior:
1. image is loaded.
2. image is blocked.
3. mCurrentRequest doesn't have size yet, so it should be replaced.
4. mCurrentRequest already got size, the following request should be a
pendingRequest.
Use a boolean to prevent calling SetBlockedRequest asynchronously.
Also use the same boolean to prevent some evil code reenters LoadImage.
Then we should redesign the correct bahavior in those follow-up bugs,
Bug 1353685 - Should ServiceWorker call SetBlockedRequest
Bug 1353683 - consider calling SetBlockedRequest in nsCORSListenerProxy::UpdateChannel
Bug 1371237 - consider calling SetBlockedRequest in nsContentSecurityManager::CheckChannel
The problem is if we found a cache hit, then we could go through
ValidateRequestWithNewChannel to validate the cache.
Then if the CSP check fail(asyncOpen2() will fail), then the
imgRequestProxy will remain there, and cause the timeout.
I run into problem when running mochitest
browser/base/content/test/general/browser_aboutHome.js in non-e10s mode.
In the beginning, browser.xul will load defaultFavicon.png, will create
an image cache there.
Next time when the test starts to run, when it loads about:home, then it
will try to load defaultFavicon.png, it will found an image cache hit
(loaded previously by browser.xul), and call
ValidateRequestWithNewChannel there, however the asyncOpen2 call failed,
and the imgRequestProxy is added to the loadGroup of about:home, and
never be notified until timeout.
As a follow-up from bug 1206961, we will remove calling CanLoadImage in
this bug. Also in the case of CSP check failed, we will call
SetBlockedRequest in those cases.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1267075#c30 for the
analysis between the old and new setup.
Now that the side effects of parsing have been relocated to BeforeSetAttr and AfterSetAttr (Bug 1365092), we can easily switch nsGenericHTMLElement::CopyInnerTo from reparsing attributes to cloning them. They are still reparsed, however, in the case where the owning document is changing since Base URIs may have changed.
MozReview-Commit-ID: 2TlUUyBx6bL
--HG--
extra : rebase_source : b581e797a24230d012cf79c1fc567c05d9acc746
In order to avoid the leak checker complaining about missing output,
we restart the browser before running tests that are expected to
crash. But as part of that restart we end up checking again if a
restart is required and so end up in an infinite loop. To break out of
that loop we simply check if this is the same test as during the last
iteration, and don't ask to restart in that case.
MozReview-Commit-ID: 90gsmqVCRsD
--HG--
extra : rebase_source : 9cf625e9cd1861b25b72e5c39ce070981b84046e
