forked from web-platform-tests/wpt
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Acacia experiments with python handlers #1
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closing as this was just an exploration, and ultimately not the right direction. |
schenney-chromium
pushed a commit
that referenced
this pull request
Jul 15, 2024
Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1891783 gecko-commit: 0f54a84c32d1c22d71ff7307944b824639adbd6f gecko-reviewers: jjaschke, smaug, dom-core
schenney-chromium
pushed a commit
that referenced
this pull request
Jul 15, 2024
Since @page border box layout objects aren't in the the layout tree, any code that wants to walk up the tree to find the containing block will be in for a surprise. This would happen if percentage-based @page padding was used [1]. Recomputing padding during painting when we have already done it during layout is rather pointless anyway. Read it out directly from the fragment. [1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent() #2 blink::LayoutBoxModelObject::ComputedCSSPadding() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1300711}
schenney-chromium
pushed a commit
that referenced
this pull request
Jul 15, 2024
WebRTC is one form of network communication that should be disabled when window.fence.disableUntrustedNetwork is called in a fenced frame. However, 1. We don't have any identified use cases for WebRTC in fenced frames 2. The revocation process would be more involved than other forms of network access, which would provide little benefit per #1. 3. Entirely disabling WebRTC PeerConnection instead is beneficial for privacy and does not break existing fenced frame use cases. This CL disables RTCPeerConnection construction entirely in fenced frames, regardless of whether window.fence.disableUntrustedNetwork was called or not. The change is behind an existing flag so that it does not ship until other forms of network revocation do. Disabling RTCPeerConnection *can* be handled entirely by the renderer, but a compromised renderer could potentially circumvent this to construct a peer connection anyway. A follow-up CL will add a browser-side control to ensure that this does not occur. Change-Id: Iaa2caaddeee70852179332dd89c5dbbac3ffcfbf Bug: 41488151 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5527514 Reviewed-by: Guido Urdaneta <guidou@chromium.org> Commit-Queue: Andrew Verge <averge@chromium.org> Reviewed-by: Liam Brady <lbrady@google.com> Reviewed-by: Shivani Sharma <shivanisha@chromium.org> Cr-Commit-Position: refs/heads/main@{#1319162}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This experiment currently only runs on linux -- works for both chrome and firefox, but not "chromium". The browser is derived from the UA string, and the UA string doesn't differentiate between chrome and chromium.
To run the test:
./wpt serve
(see WPT docs)http://web-platform.test:8000/core-aam/acacia/test.html
or run: