Skip to content
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
wants to merge 4 commits into from
Closed

Conversation

spectranaut
Copy link
Collaborator

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:

  1. Install the acacia library
  2. (for debian) install python3-ua-parser (or pip install ua-parser)
  3. run a wpt server with ./wpt serve (see WPT docs)
  4. navigate to http://web-platform.test:8000/core-aam/acacia/test.html

or run:

./wpt run --force-renderer-accessibility chrome /core-aam/acacia/test.html
./wpt run --force-renderer-accessibility firefox /core-aam/acacia/test.html

@spectranaut
Copy link
Collaborator Author

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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants