⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Timeline



Oct 31, 2021:

11:20 PM Changeset in webkit [285100] by Antti Koivisto
  • 4 edits in trunk

Fix :host invalidation when combined with pseudo classes in descendant position
https://bugs.webkit.org/show_bug.cgi?id=232544

Reviewed by Simon Fraser.

LayoutTests/imported/w3c:

  • web-platform-tests/css/css-scoping/host-functional-descendant-invalidation-expected.txt:

Source/WebCore:

  • style/RuleSet.cpp:

(WebCore::Style::isHostSelectorMatchingInShadowTree):

Make more readable and accurate.

(WebCore::Style::RuleSet::addRule):

Compute m_hasHostPseudoClassRulesMatchingInShadowTree before bailing out for pseudo elements.

5:56 PM Changeset in webkit [285099] by Fujii Hironori
  • 25 edits
    12 copies
    18 adds in trunk

[WinCairo] New GraphicsLayer for GPU process mode
https://bugs.webkit.org/show_bug.cgi?id=228308

Reviewed by Don Olmstead.

.:

  • Source/cmake/OptionsWinCairo.cmake:

Source/WebCore:

  • PlatformWinCairo.cmake:
  • platform/graphics/RemoteGraphicsContextGLProxyBase.cpp:
  • platform/graphics/RemoteGraphicsContextGLProxyBase.h:
  • platform/graphics/wc/RemoteGraphicsContextGLProxyBaseWC.cpp: Added.

(WebCore::RemoteGraphicsContextGLProxyBase::platformInitialize):
(WebCore::RemoteGraphicsContextGLProxyBase::platformLayer const):
(WebCore::RemoteGraphicsContextGLProxyBase::setPlatformLayer):

  • platform/graphics/wc/WCPlatformLayer.h: Added.
  • platform/graphics/win/GraphicsContextWin.cpp:

(WebCore::GraphicsContext::getWindowsContext): DisplayList
GraphicsContext doesn't have a HDC. Do nothing for DisplayList
context.

  • platform/graphics/win/MediaPlayerPrivateMediaFoundation.cpp:

(WebCore::MediaPlayerPrivateMediaFoundation::Direct3DPresenter::paintCurrentFrame):
Paint a frame by using GraphicsContext::drawNativeImage instead of
Cairo API for DisplayList.

Source/WebKit:

Added a new GraphicsLayer implementation GraphicsLayerWC which
transfers GraphicsLayer tree to GPU process and runs the
compositor (TextureMapper) in GPU process.

In GPU process mode, WebGL is run in GPU process. So, the
compositor should be run in GPU process. Otherwise, the output
texture of WebGL has to be transferred from GPU process to the
compositor process (UI process or web process).

Because ANGLE isn't thread-safe, the compositor and WebGL should
be run in the same thread in GPU process.

Enabling gpu_process_webgl also enables GPU process compositing now.

reg add HKEY_CURRENT_USER\Software\WebKit /v gpu_process_webgl /t REG_DWORD /d 1 /f

gpu_process_canvas_rendering can also be enabled.

reg add HKEY_CURRENT_USER\Software\WebKit /v gpu_process_canvas_rendering /t REG_DWORD /d 1 /f

Enabling gpu_process_dom_rendering is still experimental.

reg add HKEY_CURRENT_USER\Software\WebKit /v gpu_process_dom_rendering /t REG_DWORD /d 1 /f

The following commands restore the non-GPU process mode.

reg delete HKEY_CURRENT_USER\Software\WebKit /v gpu_process_canvas_rendering /f
reg delete HKEY_CURRENT_USER\Software\WebKit /v gpu_process_webgl /f
reg delete HKEY_CURRENT_USER\Software\WebKit /v gpu_process_dom_rendering /f

  • GPUProcess/GPUConnectionToWebProcess.cpp:

(WebKit::GPUConnectionToWebProcess::createWCLayerTreeHost):
(WebKit::GPUConnectionToWebProcess::releaseWCLayerTreeHost):
(WebKit::GPUConnectionToWebProcess::findRemoteGraphicsContextGL):

  • GPUProcess/GPUConnectionToWebProcess.h:
  • GPUProcess/GPUConnectionToWebProcess.messages.in:
  • GPUProcess/GPUProcess.h:

(WebKit::GPUProcess::sharedSceneContext):

  • GPUProcess/graphics/RemoteGraphicsContextGL.h:

(WebKit::RemoteGraphicsContextGL::platformLayer const):

  • GPUProcess/graphics/ScopedWebGLRenderingResourcesRequest.cpp:

(WebKit::ScopedWebGLRenderingResourcesRequest::scheduleFreeWebGLRenderingResources):

  • GPUProcess/graphics/wc/RemoteWCLayerTreeHost.cpp: Added.

(WebKit::RemoteWCLayerTreeHost::create):
(WebKit::RemoteWCLayerTreeHost::RemoteWCLayerTreeHost):
(WebKit::RemoteWCLayerTreeHost::~RemoteWCLayerTreeHost):
(WebKit::RemoteWCLayerTreeHost::messageSenderConnection const):
(WebKit::RemoteWCLayerTreeHost::messageSenderDestinationID const):
(WebKit::RemoteWCLayerTreeHost::update):

  • GPUProcess/graphics/wc/RemoteWCLayerTreeHost.h: Added.
  • GPUProcess/graphics/wc/RemoteWCLayerTreeHost.messages.in: Added.
  • GPUProcess/graphics/wc/WCScene.cpp: Added.

(WebKit::WCScene::initialize):
(WebKit::WCScene::~WCScene):
(WebKit::WCScene::update):

  • GPUProcess/graphics/wc/WCScene.h: Added.
  • GPUProcess/graphics/wc/WCSceneContext.cpp: Added.

(WebKit::WCSceneContext::WCSceneContext):
(WebKit::WCSceneContext::makeContextCurrent):
(WebKit::WCSceneContext::createTextureMapper):
(WebKit::WCSceneContext::swapBuffers):

  • GPUProcess/graphics/wc/WCSceneContext.h: Added.
  • GPUProcess/graphics/wc/WCSharedSceneContextHolder.h: Added.

(WebKit::WCSharedSceneContextHolder::ensureHolderForWindow):
(WebKit::WCSharedSceneContextHolder::removeHolder):

  • GPUProcess/win/GPUProcessMainWin.cpp:

(WebKit::GPUProcessMain):

  • PlatformWin.cmake:
  • Scripts/webkit/messages.py:

(types_that_cannot_be_forward_declared):
(conditions_for_header):

  • Shared/DrawingAreaInfo.h:
  • UIProcess/wc/DrawingAreaProxyWC.cpp: Added.

(WebKit::DrawingAreaProxyWC::DrawingAreaProxyWC):
(WebKit::DrawingAreaProxyWC::paint):
(WebKit::DrawingAreaProxyWC::sizeDidChange):
(WebKit::DrawingAreaProxyWC::update):
(WebKit::DrawingAreaProxyWC::enterAcceleratedCompositingMode):
(WebKit::DrawingAreaProxyWC::incorporateUpdate):
(WebKit::DrawingAreaProxyWC::discardBackingStore):

  • UIProcess/wc/DrawingAreaProxyWC.h: Added.
  • UIProcess/win/PageClientImpl.cpp:

(WebKit::PageClientImpl::createDrawingAreaProxy):

  • UIProcess/win/WebView.cpp:

(WebKit::WebView::paint):

  • WebProcess/GPU/graphics/RemoteGraphicsContextGLProxy.cpp:

(WebKit::RemoteGraphicsContextGLProxy::RemoteGraphicsContextGLProxy):

  • WebProcess/GPU/graphics/wc/RemoteWCLayerTreeHostProxy.cpp: Added.

(WebKit::RemoteWCLayerTreeHostProxy::RemoteWCLayerTreeHostProxy):
(WebKit::RemoteWCLayerTreeHostProxy::~RemoteWCLayerTreeHostProxy):
(WebKit::RemoteWCLayerTreeHostProxy::messageSenderConnection const):
(WebKit::RemoteWCLayerTreeHostProxy::ensureGPUProcessConnection):
(WebKit::RemoteWCLayerTreeHostProxy::disconnectGpuProcessIfNeeded):
(WebKit::RemoteWCLayerTreeHostProxy::gpuProcessConnectionDidClose):
(WebKit::RemoteWCLayerTreeHostProxy::messageSenderDestinationID const):
(WebKit::RemoteWCLayerTreeHostProxy::update):
(WebKit::RemoteWCLayerTreeHostProxy::didUpdate):

  • WebProcess/GPU/graphics/wc/RemoteWCLayerTreeHostProxy.h: Added.

(WebKit::RemoteWCLayerTreeHostProxy::wcLayerTreeHostIdentifier const):

  • WebProcess/GPU/graphics/wc/RemoteWCLayerTreeHostProxy.messages.in: Added.
  • WebProcess/GPU/graphics/wc/WCLayerTreeHostIdentifier.h: Added.
  • WebProcess/GPU/graphics/wc/WCPlatformLayerGCGL.h: Added.

(WebKit::WCPlatformLayerGCGL::WCPlatformLayerGCGL):
(WebKit::WCPlatformLayerGCGL::graphicsContextGLIdentifier):

  • WebProcess/WebPage/DrawingArea.cpp:

(WebKit::DrawingArea::create):
(WebKit::DrawingArea::supportsGPUProcessRendering):

  • WebProcess/WebPage/DrawingArea.h:

(WebKit::DrawingArea::updateGeometry):

  • WebProcess/WebPage/DrawingArea.messages.in:
  • WebProcess/WebPage/wc/DrawingAreaWC.cpp: Added.

(WebKit::DrawingAreaWC::DrawingAreaWC):
(WebKit::DrawingAreaWC::~DrawingAreaWC):
(WebKit::DrawingAreaWC::graphicsLayerFactory):
(WebKit::DrawingAreaWC::updateRootLayers):
(WebKit::DrawingAreaWC::setRootCompositingLayer):
(WebKit::DrawingAreaWC::attachViewOverlayGraphicsLayer):
(WebKit::DrawingAreaWC::setLayerTreeStateIsFrozen):
(WebKit::DrawingAreaWC::updateGeometry):
(WebKit::DrawingAreaWC::setNeedsDisplay):
(WebKit::DrawingAreaWC::setNeedsDisplayInRect):
(WebKit::DrawingAreaWC::scroll):
(WebKit::DrawingAreaWC::triggerRenderingUpdate):
(WebKit::flushLayerImageBuffers):
(WebKit::DrawingAreaWC::isCompositingMode):
(WebKit::DrawingAreaWC::updateRendering):
(WebKit::DrawingAreaWC::sendUpdateAC):
(WebKit::shouldPaintBoundsRect):
(WebKit::DrawingAreaWC::sendUpdateNonAC):
(WebKit::DrawingAreaWC::graphicsLayerAdded):
(WebKit::DrawingAreaWC::graphicsLayerRemoved):
(WebKit::DrawingAreaWC::commitLayerUpateInfo):
(WebKit::DrawingAreaWC::createImageBuffer):
(WebKit::DrawingAreaWC::didUpdate):
(WebKit::DrawingAreaWC::RootLayerClient::RootLayerClient):
(WebKit::DrawingAreaWC::RootLayerClient::paintContents):
(WebKit::DrawingAreaWC::RootLayerClient::deviceScaleFactor const):

  • WebProcess/WebPage/wc/DrawingAreaWC.h: Added.
  • WebProcess/WebPage/wc/GraphicsLayerWC.cpp: Added.

(WebKit::GraphicsLayerWC::GraphicsLayerWC):
(WebKit::GraphicsLayerWC::~GraphicsLayerWC):
(WebKit::GraphicsLayerWC::generateLayerID):
(WebKit::GraphicsLayerWC::primaryLayerID const):
(WebKit::GraphicsLayerWC::setNeedsDisplay):
(WebKit::GraphicsLayerWC::setNeedsDisplayInRect):
(WebKit::GraphicsLayerWC::setContentsNeedsDisplay):
(WebKit::GraphicsLayerWC::setChildren):
(WebKit::GraphicsLayerWC::addChild):
(WebKit::GraphicsLayerWC::addChildAtIndex):
(WebKit::GraphicsLayerWC::addChildBelow):
(WebKit::GraphicsLayerWC::addChildAbove):
(WebKit::GraphicsLayerWC::replaceChild):
(WebKit::GraphicsLayerWC::removeFromParent):
(WebKit::GraphicsLayerWC::setMaskLayer):
(WebKit::GraphicsLayerWC::setReplicatedLayer):
(WebKit::GraphicsLayerWC::setReplicatedByLayer):
(WebKit::GraphicsLayerWC::setPosition):
(WebKit::GraphicsLayerWC::setAnchorPoint):
(WebKit::GraphicsLayerWC::setSize):
(WebKit::GraphicsLayerWC::setBoundsOrigin):
(WebKit::GraphicsLayerWC::setTransform):
(WebKit::GraphicsLayerWC::setChildrenTransform):
(WebKit::GraphicsLayerWC::setPreserves3D):
(WebKit::GraphicsLayerWC::setMasksToBounds):
(WebKit::GraphicsLayerWC::setOpacity):
(WebKit::GraphicsLayerWC::setContentsRect):
(WebKit::GraphicsLayerWC::setContentsClippingRect):
(WebKit::GraphicsLayerWC::setDrawsContent):
(WebKit::GraphicsLayerWC::setContentsVisible):
(WebKit::GraphicsLayerWC::setBackfaceVisibility):
(WebKit::GraphicsLayerWC::setContentsToSolidColor):
(WebKit::GraphicsLayerWC::setContentsToPlatformLayer):
(WebKit::GraphicsLayerWC::usesContentsLayer const):
(WebKit::GraphicsLayerWC::setShowDebugBorder):
(WebKit::GraphicsLayerWC::setDebugBorder):
(WebKit::GraphicsLayerWC::setShowRepaintCounter):
(WebKit::filtersCanBeComposited):
(WebKit::GraphicsLayerWC::setFilters):
(WebKit::GraphicsLayerWC::setBackdropFilters):
(WebKit::GraphicsLayerWC::setBackdropFiltersRect):
(WebKit::GraphicsLayerWC::noteLayerPropertyChanged):
(WebKit::GraphicsLayerWC::flushCompositingState):
(WebKit::GraphicsLayerWC::flushCompositingStateForThisLayerOnly):

  • WebProcess/WebPage/wc/GraphicsLayerWC.h: Added.
  • WebProcess/WebPage/wc/WCBackingStore.h: Added.

(WebKit::WCBackingStore::WCBackingStore):
(WebKit::WCBackingStore::imageBuffer):
(WebKit::WCBackingStore::setImageBuffer):
(WebKit::WCBackingStore::bitmap const):
(WebKit::WCBackingStore::encode const):
(WebKit::WCBackingStore::decode):

  • WebProcess/WebPage/wc/WCLayerFactory.cpp: Added.

(WebKit::WCLayerFactory::WCLayerFactory):
(WebKit::WCLayerFactory::createGraphicsLayer):

  • WebProcess/WebPage/wc/WCLayerFactory.h: Added.
  • WebProcess/WebPage/wc/WCUpateInfo.h: Added.

(WebKit::WCLayerUpateInfo::encode const):
(WebKit::WCLayerUpateInfo::decode):
(WebKit::WCUpateInfo::encode const):
(WebKit::WCUpateInfo::decode):

2:40 PM Changeset in webkit [285098] by Cameron McCormack
  • 14 edits in trunk/Source

Update Web IDL links to new URL
https://bugs.webkit.org/show_bug.cgi?id=232533
<rdar://problem/84842937>

Reviewed by Sam Weinig.

Source/JavaScriptCore:

  • wasm/js/WebAssemblyMemoryConstructor.cpp:

(JSC::JSC_DEFINE_HOST_FUNCTION):

  • wasm/js/WebAssemblyTableConstructor.cpp:

(JSC::JSC_DEFINE_HOST_FUNCTION):

Source/WebCore:

  • Modules/mediastream/OverconstrainedError.idl:
  • bindings/js/JSCallbackData.cpp:
  • bindings/js/JSDOMAbstractOperations.h:
  • bindings/js/JSDOMConvertPromise.h:
  • bindings/scripts/CodeGenerator.pm:
  • bindings/scripts/CodeGeneratorJS.pm:

(AddMapLikeAttributesAndOperationIfNeeded):
(AddSetLikeAttributesAndOperationIfNeeded):
(GenerateGetOwnPropertySlot):
(GenerateGetOwnPropertySlotByIndex):
(GenerateDeletePropertyCommon):
(GenerateDeleteProperty):
(GenerateDeletePropertyByIndex):
(GenerateNamedDeleterDefinition):
(AttributeShouldBeOnInstance):
(OperationShouldBeOnInstance):
(GenerateDictionaryImplementationContent):
(GenerateAttributeSetterBodyDefinition):
(GenerateOperationBodyDefinition):
(GenerateDefaultToJSONOperationDefinition):
(GenerateConstructorHelperMethods):

  • bindings/scripts/IDLAttributes.json:
  • bindings/scripts/IDLParser.pm:
  • bindings/scripts/preprocess-idls.pl:
  • dom/ExceptionCode.h:
1:31 PM Changeset in webkit [285097] by Fujii Hironori
  • 5 edits in trunk/LayoutTests

[WinCairo] Unreviewed test gardening

  • platform/wincairo/TestExpectations:
  • platform/wincairo/editing/selection/3690703-2-expected.txt:
  • platform/wincairo/editing/selection/3690703-expected.txt:
  • platform/wincairo/editing/selection/3690719-expected.txt:
11:20 AM Changeset in webkit [285096] by mmaxfield@apple.com
  • 1 edit
    1 delete in trunk/Source/WebCore

Remove some straggling files after r280467
https://bugs.webkit.org/show_bug.cgi?id=232541

Reviewed by Sam Weinig.

Somehow I must have missed some files.

No new tests because there is no behavior change.

  • Modules/webgpu/WHLSL/AST/WHLSLStatement.cpp: Removed.
  • Modules/webgpu/WHLSL/AST/WHLSLStatementList.h: Removed.
  • Modules/webgpu/WHLSL/AST/WHLSLType.cpp: Removed.
  • Modules/webgpu/WHLSL/WHLSLProgram.cpp: Removed.
10:26 AM Changeset in webkit [285095] by Alan Bujtas
  • 3 edits in trunk/Source/WebCore

[LFC][IFC] Keep track of the text box offset in ubidi's paragraph content
https://bugs.webkit.org/show_bug.cgi?id=232540

Reviewed by Antti Koivisto.

This hashmap helps to map bidi boundary positions back to inline items.

The paragraph content string holds the InlineTextBox content (and injected control characters)
in DOM order. InlineTextItems hold start/end positions relative to their InlineTextBoxes.
We'll use this hashmap to figure out which InlineTextItems need splitting at bidi boundaries.

  • layout/formattingContexts/inline/InlineItemsBuilder.cpp:

(WebCore::Layout::InlineItemsBuilder::handleInlineBox):
(WebCore::Layout::InlineItemsBuilder::enterBidiContext):
(WebCore::Layout::InlineItemsBuilder::exitBidiContext):

  • layout/formattingContexts/inline/InlineItemsBuilder.h:
8:18 AM Changeset in webkit [285094] by Simon Fraser
  • 21 edits in trunk/Source

Scroll animations should run at 120Hz on 120Hz displays
https://bugs.webkit.org/show_bug.cgi?id=232534

Reviewed by Tim Horton.

Source/WebCore:

Scroll animations on the scrolling thread were driven by a 60Hz timer in
ScrollingTreeScrollingNodeDelegateMac. Replace that with a mechanism that drives them from
ThreadedScrollingTree::displayDidRefreshOnScrollingThread(), which is called at the maximum
display refresh frequency.

We leverage startAnimationCallback/stopAnimationCallback which update the HashSet of
animating nodes on scrolling tree, and iterate this set in the callback to service the
animations.

Change some ScrollingTree terminology from "AnimatedScroll" to "ScrollAnimation" to indicate
that they are about all kinds of scroll animations (e.g. rubberbanding), not just animated
scrolls.

A side effect of removing the ScrollingTreeScrollingNodeDelegateMac was that there was no
code path that triggered continual "displayDidRefresh" notifications (which originate in the
UI process). We need something to keep the displayDidRefresh notifications coming. To fix
this, have ScrollingCoordinatorMac call scheduleRenderingUpdate() when an animation starts,
and in each rendering update while there are active animations. This doesn't trigger
additional rendering updates; these will happen anyway as a side effect of scrolling tree
scrolls bouncing to the main thread. Also worth noting is that the scrolling thread will get
120Hz updates, even if we're only triggering main thread rendering updates, because of
existing WebPageProxy hasActiveAnimatedScroll state.

Exercised by existing tests.

  • page/scrolling/ScrollingTree.cpp:

(WebCore::ScrollingTree::isScrollAnimationInProgressForNode):
(WebCore::ScrollingTree::setScrollAnimationInProgressForNode):
(WebCore::ScrollingTree::hasNodeWithActiveScrollAnimations):
(WebCore::ScrollingTree::nodesWithActiveScrollAnimations):
(WebCore::ScrollingTree::isAnimatedScrollInProgressForNode): Deleted.
(WebCore::ScrollingTree::setAnimatedScrollInProgressForNode): Deleted.
(WebCore::ScrollingTree::hasNodeWithActiveAnimatedScroll): Deleted.

  • page/scrolling/ScrollingTree.h:
  • page/scrolling/ScrollingTreeScrollingNode.cpp:

(WebCore::ScrollingTreeScrollingNode::willStartAnimatedScroll):
(WebCore::ScrollingTreeScrollingNode::didStopAnimatedScroll):
(WebCore::ScrollingTreeScrollingNode::setScrollAnimationInProgress):

  • page/scrolling/ScrollingTreeScrollingNode.h:
  • page/scrolling/ScrollingTreeScrollingNodeDelegate.h:
  • page/scrolling/ThreadedScrollingTree.cpp:

(WebCore::ThreadedScrollingTree::scrollingThreadIsActive):
(WebCore::ThreadedScrollingTree::serviceScrollAnimations):
(WebCore::ThreadedScrollingTree::displayDidRefreshOnScrollingThread):

  • page/scrolling/ThreadedScrollingTree.h:
  • page/scrolling/mac/ScrollingCoordinatorMac.h:
  • page/scrolling/mac/ScrollingCoordinatorMac.mm:

(WebCore::ScrollingCoordinatorMac::didCompleteRenderingUpdate):
(WebCore::ScrollingCoordinatorMac::hasNodeWithAnimatedScrollChanged):

  • page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.h:
  • page/scrolling/mac/ScrollingTreeFrameScrollingNodeMac.mm:

(WebCore::ScrollingTreeFrameScrollingNodeMac::startAnimatedScrollToPosition):
(WebCore::ScrollingTreeFrameScrollingNodeMac::serviceScrollAnimation):
(WebCore::ScrollingTreeFrameScrollingNodeMac::currentScrollPositionChanged):

  • page/scrolling/mac/ScrollingTreeOverflowScrollingNodeMac.h:
  • page/scrolling/mac/ScrollingTreeOverflowScrollingNodeMac.mm:

(WebCore::ScrollingTreeOverflowScrollingNodeMac::serviceScrollAnimation):

  • page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.h:
  • page/scrolling/mac/ScrollingTreeScrollingNodeDelegateMac.mm:

(WebCore::ScrollingTreeScrollingNodeDelegateMac::createTimer):
(WebCore::ScrollingTreeScrollingNodeDelegateMac::startAnimationCallback):
(WebCore::ScrollingTreeScrollingNodeDelegateMac::stopAnimationCallback):
(WebCore::ScrollingTreeScrollingNodeDelegateMac::serviceScrollAnimation):
(WebCore::ScrollingTreeScrollingNodeDelegateMac::scrollControllerAnimationTimerFired): Deleted.

  • page/scrolling/nicosia/ScrollingTreeScrollingNodeDelegateNicosia.cpp:

(WebCore::ScrollingTreeScrollingNodeDelegateNicosia::animationTimerFired):
(WebCore::ScrollingTreeScrollingNodeDelegateNicosia::serviceScrollAnimation):

  • page/scrolling/nicosia/ScrollingTreeScrollingNodeDelegateNicosia.h:

Source/WebKit:

  • UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.h:
  • WebProcess/WebPage/mac/TiledCoreAnimationScrollingCoordinator.mm:

(WebKit::TiledCoreAnimationScrollingCoordinator::hasNodeWithAnimatedScrollChanged):

7:25 AM Changeset in webkit [285093] by Alan Bujtas
  • 3 edits in trunk/Source/WebCore

[LFC][IFC] Add unicode-bidi control characters
https://bugs.webkit.org/show_bug.cgi?id=232538

Reviewed by Antti Koivisto.

This is preparation for injecting entering/exiting control characters into the paragraph string used by ubidi.

  • layout/formattingContexts/inline/InlineItemsBuilder.cpp:

(WebCore::Layout::InlineItemsBuilder::handleInlineBox):
(WebCore::Layout::InlineItemsBuilder::enterBidiContext):
(WebCore::Layout::InlineItemsBuilder::exitBidiContext):

  • layout/formattingContexts/inline/InlineItemsBuilder.h:
6:41 AM Changeset in webkit [285092] by Andres Gonzalez
  • 15 edits in trunk/Source/WebCore

Move handling of ChildrenChanged notifications out of the AccessibilityObjects into AXObjectCache.
https://bugs.webkit.org/show_bug.cgi?id=232503
<rdar://problem/84820154>

Reviewed by Chris Fleizach.

ChildrenChanged notifications were handled in
AXObjectCache::performDeferredCacheUpdate by calling into an AX object
method. While in principle this may seem as a good design, it obscures
significantly what exactly happens in response to a notification. This
is aggravated by the fact that the object's handlers may call back into
the AXObjectCache to post or further defer notifications to platform
clients.
This patch atempts to straightline this flow by handling the
ChildrenChanged notifications in AXObjectCache.

  • accessibility/AXObjectCache.cpp:

(WebCore::AXObjectCache::textChanged):
(WebCore::AXObjectCache::handleChildrenChanged):
The name indicates that this is the actual handler for the notification
as opposed as the other childrenChanged(...) methods that just queue
the notifications for a later time.

(WebCore::AXObjectCache::childrenChanged):
(WebCore::AXObjectCache::notificationPostTimerFired):
(WebCore::AXObjectCache::handleAriaRoleChanged):
(WebCore::AXObjectCache::recomputeIsIgnored):
(WebCore::AXObjectCache::performDeferredCacheUpdate):

  • accessibility/AXObjectCache.h:
  • accessibility/AccessibilityMenuList.cpp:

(WebCore::AccessibilityMenuList::childrenChanged):
Deleted, now handled in AXObjectCache::handleChildrenChanged.

  • accessibility/AccessibilityMenuList.h:
  • accessibility/AccessibilityMenuListPopup.cpp:

(WebCore::AccessibilityMenuListPopup::handleChildrenChanged):
(WebCore::AccessibilityMenuListPopup::childrenChanged):
Renamed handleChildrenChanged. It is the only AXObject subclass that
still has this method to update its children. It does not post or
schedule any platform client notification.

  • accessibility/AccessibilityMenuListPopup.h:
  • accessibility/AccessibilityNodeObject.cpp:

(WebCore::AccessibilityNodeObject::updateAccessibilityRole):
(WebCore::AccessibilityNodeObject::childrenChanged): Deleted.

  • accessibility/AccessibilityNodeObject.h:
  • accessibility/AccessibilityObject.cpp:

(WebCore::AccessibilityObject::hasIgnoredValueChanged):
(WebCore::AccessibilityObject::notifyIfIgnoredValueChanged):
Renamed hasIgnoredValueChanged since the actual notifications are posted
in AXObjectCache.

  • accessibility/AccessibilityObject.h:

(WebCore::AccessibilityObject::updateAccessibilityRole):

  • accessibility/AccessibilityObjectInterface.h:

Several methods can now be removed from the AXCoreObject interface since
they are internal to the AXObject class hierarchy.

  • accessibility/AccessibilityTable.cpp:

(WebCore::AccessibilityTable::addChildren):

  • accessibility/isolatedtree/AXIsolatedObject.cpp:

Now able to delete several unnecessary methods from the isolated objects.
(WebCore::AXIsolatedObject::childrenChanged): Deleted.
(WebCore::AXIsolatedObject::updateAccessibilityRole): Deleted.
(WebCore::AXIsolatedObject::lastKnownIsIgnoredValue): Deleted.
(WebCore::AXIsolatedObject::setLastKnownIsIgnoredValue): Deleted.
(WebCore::AXIsolatedObject::notifyIfIgnoredValueChanged): Deleted.

  • accessibility/isolatedtree/AXIsolatedObject.h:
1:49 AM Changeset in webkit [285091] by Cameron McCormack
  • 2 edits in trunk/Source/WebCore

Change some bitwise OR operators to logical OR
https://bugs.webkit.org/show_bug.cgi?id=232537
<rdar://problem/84845378>

Reviewed by Alexey Proskuryakov.

  • html/canvas/CanvasRenderingContext2DBase.cpp:

(WebCore::CanvasRenderingContext2DBase::translate):
(WebCore::CanvasRenderingContext2DBase::transform):
(WebCore::CanvasRenderingContext2DBase::setTransform):
(WebCore::validateRectForCanvas):
(WebCore::CanvasRenderingContext2DBase::canDrawText):

Oct 30, 2021:

8:22 PM Changeset in webkit [285090] by mmaxfield@apple.com
  • 9 edits in trunk/Source

Migrate the first few callers from ImageBuffer::truncatedLogicalSize() to ImageBuffer::logicalSize()
https://bugs.webkit.org/show_bug.cgi?id=232528

Reviewed by Tim Horton.

Source/WebCore:

These are the callers which seem obviously correct to migrate from truncatedLogicalSize() to logicalSize(),
because these are the callers that immediately cast the result to FloatSize. That means, before this patch,
these callers are going from float -> int -> float.

This patch is the fourth step in https://bugs.webkit.org/show_bug.cgi?id=225377. There is no situation where
truncating the logical size is meaningful - we either want the float logical size, or we want the physical
number of texels in the image (which is the logical size, times the resolution, rounded up to an int size).
Eventually, we should move all callers off of truncatedLogicalSize() and on to either logicalSize() or
a yet-to-be-written physicalSize()/texelCount()/bikeshedName().

  • platform/graphics/GraphicsContext.cpp:

(WebCore::GraphicsContext::drawImageBuffer):
(WebCore::GraphicsContext::drawConsumingImageBuffer):

  • platform/graphics/displaylists/DisplayListImageBuffer.h:

(WebCore::DisplayList::ImageBuffer::ImageBuffer):

  • platform/graphics/filters/FEBlend.cpp:

(WebCore::FEBlend::platformApplySoftware):

  • platform/graphics/filters/FEComposite.cpp:

(WebCore::FEComposite::platformApplySoftware):

  • rendering/CSSFilter.cpp:

(WebCore::CSSFilter::allocateBackingStoreIfNeeded):

  • rendering/svg/RenderSVGResourcePattern.cpp:

(WebCore::RenderSVGResourcePattern::buildPattern):

Source/WebKit:

  • WebProcess/GPU/graphics/RemoteImageBufferProxy.h:

(WebKit::RemoteImageBufferProxy::RemoteImageBufferProxy):

8:19 PM Changeset in webkit [285089] by Wenson Hsieh
  • 13 edits
    2 adds in trunk

Layer tree should not be stuck in frozen state after explicitly stopping a page load
https://bugs.webkit.org/show_bug.cgi?id=232532
rdar://84522357

Reviewed by Tim Horton.

Source/WebCore:

Add WEBCORE_EXPORT to a method. See WebKit/ChangeLog for more details.

Test: http/tests/navigation/unfreeze-layer-tree-after-stopping-load.html

  • loader/FrameLoader.h:

Source/WebKit:

From diagnostic logs gathered in rdar://84522357, it's apparently possible for the layer tree to be stuck in a
state where it's indefinitely frozen after the user explicitly stops the page load (e.g. by tapping on the "x"
button in Safari). Specifically, these logs indicate that the PageTransition layer tree freeze reason may
persist even after the user has canceled the load, leading to situations where content may be visible but
unresponsive.

From code inspection, this may happen for multiple reasons, one of which is that a media element has incremented
the load event delay count, which in turn prevents us from transitioning to completed state inside
FrameLoader::checkLoadCompleteForThisFrame(). It's unknown whether this (in particular) is the cause of
unresponsiveness observed by the reporter of rdar://84522357, but we can at least use this in order to come up
with a layout test; to mitigate all instances where the PageTransition reason may persist after the load has
been stopped, we make WebPage::stopLoading() complete the page transition (thereby lifting the freeze reason)
if needed.

  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::stopLoading):

Tools:

Add support for TestRunner.stopLoading(), which immediately stops the page load, emulating what would normally
happen if the user taps or clicks the "x" button to cancel loading in Safari. See the layout test for more
details.

  • DumpRenderTree/TestRunner.cpp:

(stopLoadingCallback):
(TestRunner::staticFunctions):

  • DumpRenderTree/TestRunner.h:
  • DumpRenderTree/mac/TestRunnerMac.mm:

(TestRunner::stopLoading):

  • DumpRenderTree/win/TestRunnerWin.cpp:

(TestRunner::stopLoading):

  • WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
  • WebKitTestRunner/InjectedBundle/TestRunner.cpp:

(WTR::TestRunner::stopLoading):

  • WebKitTestRunner/InjectedBundle/TestRunner.h:

LayoutTests:

Add a test that verifies that a requestAnimationFrame() callback fires even after stopping page load. This
test fails without the fix in this patch, since the layer tree ends up in a permanently frozen state.

  • http/tests/navigation/unfreeze-layer-tree-after-stopping-load-expected.txt: Added.
  • http/tests/navigation/unfreeze-layer-tree-after-stopping-load.html: Added.
7:37 PM Changeset in webkit [285088] by mmaxfield@apple.com
  • 3 edits in trunk/Source/WebKit

Web process shouldn't crash if ImageBuffer::ensureBackendCreated() fails
https://bugs.webkit.org/show_bug.cgi?id=232520
<rdar://problem/84829717>

Reviewed by Simon Fraser.

Guard against the possibility of it returning null.

No new tests because there shouldn't be any behavior change after https://bugs.webkit.org/show_bug.cgi?id=232470.
It's still good to do this, though, to be defensive.

  • Shared/RemoteLayerTree/RemoteLayerBackingStore.mm:

(WebKit::RemoteLayerBackingStore::encode const):

  • WebProcess/GPU/graphics/RemoteImageBufferProxy.h:

(WebKit::RemoteImageBufferProxy::createImageBufferBackendHandle):

7:24 PM Changeset in webkit [285087] by mmaxfield@apple.com
  • 3 edits
    2 adds in trunk

[GPU Process] Small ImageBuffers cause the web process to crash
https://bugs.webkit.org/show_bug.cgi?id=232470
<rdar://problem/84626560>

Reviewed by Tim Horton.

Source/WebKit:

The problem is when the (floating point) size < 1x1, but the size*resolution is >= 1x1.
In this situation, calculateSafeBackendSize() is correctly determining that this
isn't a zero-sized ImageBuffer, but when we go to actually pass the size to the GPU
process, we call this:

IntSize logicalSize() const override { return IntSize(m_parameters.logicalSize); }

So, the logical size gets truncated down to 0, and then the GPU process fails to allocate
the ImageBuffer, and then the web process blocks on the GPU process indefinitely, and then
eventually times out and then crashes. I'm going to deal with that last step (the crash
itself) in a secondary patch - if the web process doesn't hear from the GPU process, it
shouldn't crash.

This patch simply exposes a floatLogicalSize() function on ImageBuffer, so we can get
the full-fidelity logical size to pass that to the GPU process.

Test: compositing/device-pixel-image-buffer-hidpi.html

  • WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp:

(WebKit::RemoteRenderingBackendProxy::createRemoteImageBuffer):

LayoutTests:

  • compositing/device-pixel-image-buffer-hidpi-expected.html: Added.
  • compositing/device-pixel-image-buffer-hidpi.html: Added.
6:24 PM Changeset in webkit [285086] by Chris Dumez
  • 7 edits in trunk

Improve error handling in sendWithAsyncReply()
https://bugs.webkit.org/show_bug.cgi?id=232508

Reviewed by Darin Adler.

Source/WebKit:

  • Platform/IPC/Connection.cpp:

(IPC::Connection::invalidate):
We stop delivering messages as soon as |m_valid| becomes false. It is
thus a good idea to cancel any pending async reply handlers as soon
as we set m_isValid to false. We were doing it correctly in connectionDidClose()
but not in invalidate(). The Connection destructor would eventually call
the async reply handlers. However, I have noticed when investigating a leak
that this may delay the calling of the reply handler for a long time if
something keeps the Connection alive (or forever in case of a leak).

  • Platform/IPC/Connection.h:

(IPC::Connection::sendWithAsyncReply):
Return early if the connection is no longer valid and call the
completion handler right away (but asynchronously). Previously,
we'd register the async reply handler and then the call to
sendMessage() would fail.

  • UIProcess/API/Cocoa/WKWebView.mm:

(-[WKWebView _getContentsAsStringWithCompletionHandlerKeepIPCConnectionAliveForTesting:]):

  • UIProcess/API/Cocoa/WKWebViewPrivate.h:

Add helper SPI for API test.

Tools:

Add API test coverage.

  • TestWebKitAPI/Tests/WebKitCocoa/WKWebViewGetContents.mm:

(TEST):

6:18 PM Changeset in webkit [285085] by Chris Dumez
  • 4 edits in trunk

[ BigSur wk2 Debug arm64 ] webaudio/AudioBufferSource/audiobuffersource-playbackrate.html is a flaky crash
https://bugs.webkit.org/show_bug.cgi?id=232500
<rdar://problem/84816843>

Reviewed by Eric Carlson.

Source/WebCore:

The call to HashSet::remove() may cause a memory allocation so we need to extend the scope of the
DisableMallocRestrictionsForCurrentThreadScope to avoid assertion hits in debug builds.

No new tests, unskipped existing test.

  • Modules/webaudio/AudioSummingJunction.cpp:

(WebCore::AudioSummingJunction::removeOutput):

LayoutTests:

Unskip test that is no longer crashing.

  • platform/mac-wk2/TestExpectations:
3:58 PM Changeset in webkit [285084] by commit-queue@webkit.org
  • 9 edits
    2 adds in trunk

Selection extend() should trigger exception with no ranges
https://bugs.webkit.org/show_bug.cgi?id=232420

Patch by Brandon Stewart <Brandon> on 2021-10-30
Reviewed by Chris Dumez.

LayoutTests/imported/w3c:

Verify extend() will throw an exception when the Selection object
contains no Range objects. Chrome and Firefox will also throw an
exception in this scenario.

https://w3c.github.io/selection-api/#dom-selection-extend

  • web-platform-tests/selection/extend-exception-expected.txt: Added.
  • web-platform-tests/selection/extend-exception.html: Added.

Source/WebCore:

The 'extend' method in the Selection API should throw an exception upon
being called if there are no ranges present in the Selection object.

https://w3c.github.io/selection-api/#dom-selection-extend

Test: imported/w3c/web-platform-tests/selection/extend-exception.html

  • page/DOMSelection.cpp:

(WebCore::DOMSelection::extend):

LayoutTests:

Resolve errors in test cases introduced by new exception being thrown by extend()
when no ranges are present.

  • editing/execCommand/null_calc_primitive_value_for_css_property.html:
  • editing/execCommand/transpose-backslash-with-euc.html:
  • editing/inserting/insert-html-crash-02.html:
  • editing/selection/DOMSelection-crossing-document-expected.txt:
  • editing/selection/DOMSelection-crossing-document.html:
12:57 PM Changeset in webkit [285083] by Alan Bujtas
  • 7 edits in trunk/Source/WebCore

[LFC][IFC] Add bidi level to InlineDisplay::Box
https://bugs.webkit.org/show_bug.cgi?id=232531

Reviewed by Antti Koivisto.

InlineItem -> Line::Run -> InlineDisplay::Box.

  • layout/formattingContexts/inline/InlineDisplayContentBuilder.cpp:

(WebCore::Layout::InlineDisplayContentBuilder::build):
(WebCore::Layout::InlineDisplayContentBuilder::createBoxesAndUpdateGeometryForLineContent):
(WebCore::Layout::InlineDisplayContentBuilder::createBoxesAndUpdateGeometryForLineSpanningInlineBoxes):

  • layout/formattingContexts/inline/InlineLine.cpp:

(WebCore::Layout::Line::appendTextContent):
(WebCore::Layout::m_bidiLevel):
(WebCore::Layout::Line::Run::Run):
(WebCore::Layout::Line::Run::expand):

  • layout/formattingContexts/inline/InlineLine.h:

(WebCore::Layout::Line::Run::bidiLevel const):

  • layout/formattingContexts/inline/display/InlineDisplayBox.h:

(WebCore::InlineDisplay::Box::Box):
(WebCore::InlineDisplay::Box::bidiLevel const):

  • layout/integration/InlineIteratorBoxModernPath.h:

(WebCore::InlineIterator::BoxModernPath::bidiLevel const):

  • layout/integration/LayoutIntegrationPagination.cpp:

(WebCore::LayoutIntegration::makeAdjustedContent):

10:26 AM Changeset in webkit [285082] by Alan Bujtas
  • 5 edits in trunk/Source/WebCore

[LFC][IFC] Add skeleton implementation for bidi content handling
https://bugs.webkit.org/show_bug.cgi?id=232524

Reviewed by Antti Koivisto.

Add dedicated functions for inline content types that need separate bidi handling (text vs. inline box vs. atomic etc).

  • layout/formattingContexts/inline/InlineFormattingContext.cpp:

(WebCore::Layout::InlineFormattingContext::collectContentIfNeeded):

  • layout/formattingContexts/inline/InlineFormattingState.h:

(WebCore::Layout::InlineFormattingState::addInlineItems):
(WebCore::Layout::InlineFormattingState::addInlineItem): Deleted.

  • layout/formattingContexts/inline/InlineItemsBuilder.cpp:

(WebCore::Layout::InlineItemsBuilder::build):
(WebCore::Layout::InlineItemsBuilder::collectInlineItems):
(WebCore::Layout::InlineItemsBuilder::breakInlineItemsAtBidiBoundaries):
(WebCore::Layout::InlineItemsBuilder::handleTextContent):
(WebCore::Layout::InlineItemsBuilder::handleInlineBox):
(WebCore::Layout::InlineItemsBuilder::handleInlineLevelBox):
(WebCore::Layout::InlineItemsBuilder::createAndAppendTextItems): Deleted.

  • layout/formattingContexts/inline/InlineItemsBuilder.h:

(WebCore::Layout::InlineItemsBuilder::root const):
(WebCore::Layout::InlineItemsBuilder::formattingState const): Deleted.

10:09 AM Changeset in webkit [285081] by Sam Sneddon
  • 5 edits in trunk/Tools

Ensure we stop LayoutTest servers without them becoming zombies
https://bugs.webkit.org/show_bug.cgi?id=225189
<rdar://problem/77604119>

Reviewed by Jonathan Bedard.

Also increase the polling frequency in HttpServerBase._wait_for_action, as this is a major
source of delay when running run-webkit-tests --dry-run due to the number of servers we're
starting nowadays.

  • Scripts/webkitpy/common/system/executive_mock.py:

(MockProcess.init): Rename self.returncode to _returncode
(MockProcess.returncode): returncode should be None if process is still running

  • Scripts/webkitpy/layout_tests/servers/http_server.py:

(Lighttpd._spawn_process): Store Popen object
(Lighttpd._check_and_kill): Skip "kill" if process has returned
(Lighttpd._is_server_running_on_all_ports): Correctly raise ServerError if it has returned

  • Scripts/webkitpy/layout_tests/servers/http_server_base.py:

(HttpServerBase.start): Change polling frequency for cygwin from 0.1Hz to default
(HttpServerBase._wait_for_action): Increase default polling frequency to 10Hz from 1Hz

  • Scripts/webkitpy/layout_tests/servers/web_platform_test_server.py:

(WebPlatformTestServer._stop_running_server): Poll first so we don't have zombies keeping references to pipes

9:08 AM Changeset in webkit [285080] by Kate Cheney
  • 5 edits in trunk

[iOS 15] Loads after WKWebView session restore are marked as app-initiated
https://bugs.webkit.org/show_bug.cgi?id=232486
<rdar://problem/84811692>

Reviewed by Brent Fulgham.

Source/WebKit:

Return app initiated value in the page's SessionState so it can be restored
by third party apps using the [WKWebView setInteractionState] API.

  • UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::sessionState const):

  • UIProcess/mac/LegacySessionStateCoding.cpp:

(WebKit::encodeLegacySessionState):
(WebKit::decodeLegacySessionState):

Tools:

  • TestWebKitAPI/Tests/WebKitCocoa/AppPrivacyReport.mm:
6:44 AM Changeset in webkit [285079] by Alan Bujtas
  • 6 edits in trunk/Source/WebCore

[LFC][IFC] InlineItem should not cross bidi level boundary
https://bugs.webkit.org/show_bug.cgi?id=232509

Reviewed by Antti Koivisto.

Every inline item has a bidi level even when the content is not considered strictly as bidi (i.e. we don't call into ubidi to figure level information).

  • layout/formattingContexts/inline/InlineItem.h:

(WebCore::Layout::InlineItem::bidiLevel const):
(WebCore::Layout::InlineItem::InlineItem):

  • layout/formattingContexts/inline/InlineItemsBuilder.cpp:

(WebCore::Layout::InlineItemsBuilder::createAndAppendTextItems):

  • layout/formattingContexts/inline/InlineSoftLineBreakItem.h:

(WebCore::Layout::InlineSoftLineBreakItem::createSoftLineBreakItem):
(WebCore::Layout::InlineSoftLineBreakItem::InlineSoftLineBreakItem):

  • layout/formattingContexts/inline/InlineTextItem.cpp:

(WebCore::Layout::InlineTextItem::InlineTextItem):
(WebCore::Layout::InlineTextItem::left const):
(WebCore::Layout::InlineTextItem::right const):

  • layout/formattingContexts/inline/InlineTextItem.h:

(WebCore::Layout::InlineTextItem::createWhitespaceItem):
(WebCore::Layout::InlineTextItem::createNonWhitespaceItem):
(WebCore::Layout::InlineTextItem::createEmptyItem):

Note: See TracTimeline for information about the timeline view.