Tags: qteam1/wpt
Tags
Delay restarting inline rAF loop until page is notified of session end Currently the inline rAF loop gets restarted before the page is notified that the immersive session has ended. This causes some flaky test cases where the inline callback is serviced before the page knows that it's okay, since the immersive session has ended. This change splits the FrameProvider's OnSessionEnded logic such that it can be notified of the fact that there is no longer an immersive session before the page is (so that the page is not blocked from requesting a new immersive session), while only re-starting the inline rAF loops after the page has been notified. Fixed: 1062195 Change-Id: I2ccf63d476b7f857bc53e9c15bedc07a13fdfed6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2354537 Reviewed-by: Brandon Jones <bajones@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Cr-Commit-Position: refs/heads/master@{#797812}
Workaround marionette 3.1.0 switch_to_window bug in Firefox 79 (web-p… …latform-tests#24992) Fixes web-platform-tests#24924
[lint] Disallow *.mojom.js in WPT (web-platform-tests#24980) We now have established a formal way to do this (more documentation will be available in Chromium, as this is Chrome-only) and should no longer accept these auto-generated files in WPT. Related to web-platform-tests#16455.
Add tests for disabled input clicks See whatwg/html#5805; this tests the scenario there plus others.
Add ElementInternals.shadowRoot which returns both open and closed roots See [1] for context. This CL adds the shadowRoot attribute to ElementInternals, which allows custom elements to access their own shadow roots, including in the case that the shadowRoot is closed. Without this capability, custom elements that use closed declarative shadow roots would have no ability to retrieve the contents of their own shadow root. Bug: 1042130 [1] WICG/webcomponents#871 (comment) Change-Id: I33606144bec3c27600d2e67f108d0344f7696dd2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2350739 Commit-Queue: Mason Freed <masonfreed@chromium.org> Auto-Submit: Mason Freed <masonfreed@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Cr-Commit-Position: refs/heads/master@{#797729}
Remove dragexit and test for its absence (web-platform-tests#24962) Follows whatwg/html#5809.
Add paint timing support for webgl2 canvas. Bug: 1112857 Change-Id: I2c76e95ecb139d3359877e71c6f3713f4d9f3c37 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2348694 Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Annie Sullivan <sullivan@chromium.org> Cr-Commit-Position: refs/heads/master@{#797698}
|request_initiator_site_lock = <opaque>| for the process-wide factory. The CL modifies URLLoaderFactoryParamsHelper::CreateForRendererProcess so that it sets |request_initiator_site_lock| of the process-wide factory to an opaque origin. This change is based on https://crbug.com/1105794 which shows that there are indeed no cases in the wild where a process-wide factory is used with a non-opaque initiator origin. This intuitively makes sense - the process-wide factory should only be used in frames that have not yet committed any navigation and such frame should not (yet) have a non-opaque origin. Additionally, thanks to the change described above, there is no longer a need for site/eTLD+1 comparisons in VerifyRequestInitiatorLock nor for SiteInstanceImpl::GetRequestInitiatorSiteLock. Fixed: 1098938 Change-Id: I9e8b53139a2418636c84e783f86ea8d7be34eed9 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2274591 Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org> Cr-Commit-Position: refs/heads/master@{#797542}
update python version, so it's compatible with both python2 and pytho… …n3 (web-platform-tests#24685)
Added hold_phase to Animation Prior to this change, effects are always given the current phase of the timeline associated with them. This fails in certain situations such as pausing and then scrolling, setting current time with an inactive timeline, and many other scenarios where hold_time is set. In order to fix this, we have introduced hold_phase. Anytime hold_time is updated, hold_phase will also be updated with the appropriate phase. Sometimes the phase is set explicitly and other times we pull from the timeline current time. Animation effects will be given the animation hold_phase if it is populated, otherwise it will calculate its current phase (similar to how current time is calculated). The WebAnimations spec is being updated to reflect this change. Bug: 1046833 Change-Id: I4bf1e42eaab684c18829a79acc1ab8911ec893af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2135336 Commit-Queue: Jordan Taylor <jortaylo@microsoft.com> Reviewed-by: Kevin Ellis <kevers@chromium.org> Reviewed-by: Majid Valipour <majidvp@chromium.org> Cr-Commit-Position: refs/heads/master@{#797835}
PreviousNext