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

Timeline



Mar 6, 2022:

10:43 PM Changeset in webkit [290877] by mmaxfield@apple.com
  • 28 edits in trunk/Source/WebGPU

[WebGPU] Use C++ references instead of pointers where applicable
​https://bugs.webkit.org/show_bug.cgi?id=237508

Reviewed by Tim Horton.

The header we're implementing uses pointers because it's a C header.
Our internal implementation can use references instead.

  • WebGPU/Adapter.h:
  • WebGPU/Adapter.mm:

(WebGPU::Adapter::getLimits):
(WebGPU::Adapter::getProperties):
(WebGPU::Adapter::requestDevice):
(wgpuAdapterGetLimits):
(wgpuAdapterGetProperties):
(wgpuAdapterRequestDevice):
(wgpuAdapterRequestDeviceWithBlock):

  • WebGPU/BindGroup.mm:

(WebGPU::Device::createBindGroup):

  • WebGPU/BindGroupLayout.mm:

(WebGPU::Device::createBindGroupLayout):

  • WebGPU/Buffer.mm:

(WebGPU::Device::createBuffer):

  • WebGPU/CommandEncoder.h:
  • WebGPU/CommandEncoder.mm:

(WebGPU::Device::createCommandEncoder):
(WebGPU::CommandEncoder::beginComputePass):
(WebGPU::CommandEncoder::beginRenderPass):
(WebGPU::CommandEncoder::copyBufferToTexture):
(WebGPU::CommandEncoder::copyTextureToBuffer):
(WebGPU::CommandEncoder::copyTextureToTexture):
(WebGPU::CommandEncoder::finish):
(wgpuCommandEncoderBeginComputePass):
(wgpuCommandEncoderBeginRenderPass):
(wgpuCommandEncoderCopyBufferToTexture):
(wgpuCommandEncoderCopyTextureToBuffer):
(wgpuCommandEncoderCopyTextureToTexture):
(wgpuCommandEncoderFinish):

  • WebGPU/ComputePipeline.mm:

(WebGPU::Device::createComputePipeline):
(WebGPU::Device::createComputePipelineAsync):

  • WebGPU/Device.h:
  • WebGPU/Device.mm:

(WebGPU::Device::getLimits):
(wgpuDeviceCreateBindGroup):
(wgpuDeviceCreateBindGroupLayout):
(wgpuDeviceCreateBuffer):
(wgpuDeviceCreateCommandEncoder):
(wgpuDeviceCreateComputePipeline):
(wgpuDeviceCreateComputePipelineAsync):
(wgpuDeviceCreateComputePipelineAsyncWithBlock):
(wgpuDeviceCreatePipelineLayout):
(wgpuDeviceCreateQuerySet):
(wgpuDeviceCreateRenderBundleEncoder):
(wgpuDeviceCreateRenderPipeline):
(wgpuDeviceCreateRenderPipelineAsync):
(wgpuDeviceCreateRenderPipelineAsyncWithBlock):
(wgpuDeviceCreateSampler):
(wgpuDeviceCreateShaderModule):
(wgpuDeviceCreateSwapChain):
(wgpuDeviceCreateTexture):
(wgpuDeviceGetLimits):

  • WebGPU/Instance.h:
  • WebGPU/Instance.mm:

(WebGPU::Instance::create):
(WebGPU::Instance::createSurface):
(WebGPU::Instance::requestAdapter):
(wgpuCreateInstance):
(wgpuInstanceCreateSurface):
(wgpuInstanceRequestAdapter):
(wgpuInstanceRequestAdapterWithBlock):

  • WebGPU/PipelineLayout.mm:

(WebGPU::Device::createPipelineLayout):

  • WebGPU/QuerySet.mm:

(WebGPU::Device::createQuerySet):

  • WebGPU/Queue.h:
  • WebGPU/Queue.mm:

(WebGPU::Queue::writeTexture):
(wgpuQueueWriteTexture):

  • WebGPU/RenderBundleEncoder.h:
  • WebGPU/RenderBundleEncoder.mm:

(WebGPU::Device::createRenderBundleEncoder):
(WebGPU::RenderBundleEncoder::finish):
(wgpuRenderBundleEncoderFinish):

  • WebGPU/RenderPassEncoder.h:
  • WebGPU/RenderPassEncoder.mm:

(WebGPU::RenderPassEncoder::setBlendConstant):
(wgpuRenderPassEncoderSetBlendConstant):

  • WebGPU/RenderPipeline.mm:

(WebGPU::Device::createRenderPipeline):
(WebGPU::Device::createRenderPipelineAsync):

  • WebGPU/Sampler.mm:

(WebGPU::Device::createSampler):

  • WebGPU/ShaderModule.h:
  • WebGPU/ShaderModule.mm:

(WebGPU::findShaderModuleParameters):
(WebGPU::Device::createShaderModule):
(WebGPU::ShaderModule::getCompilationInfo):
(wgpuShaderModuleGetCompilationInfo):
(wgpuShaderModuleGetCompilationInfoWithBlock):

  • WebGPU/SwapChain.mm:

(WebGPU::Device::createSwapChain):

  • WebGPU/Texture.h:
  • WebGPU/Texture.mm:

(WebGPU::Device::createTexture):
(WebGPU::Texture::createView):
(wgpuTextureCreateView):

7:52 PM Changeset in webkit [290876] by Lauro Moura
  • 2 edits in trunk/Tools

[Flatpak SDK] Fix key expired treatment with Python3
​https://bugs.webkit.org/show_bug.cgi?id=237509

Reviewed by Fujii Hironori.

  • flatpak/flatpakutils.py:

(FlatpakObject.flatpak_update):

9:39 AM Changeset in webkit [290875] by Wenson Hsieh
  • 4 edits
    1 add in trunk

[iOS] Layer tree can get indefinitely frozen if WKWebView is unparented underneath -[UIWindow dealloc]
​https://bugs.webkit.org/show_bug.cgi?id=237505
rdar://85563958

Reviewed by Tim Horton.

Source/WebKit:

It's currently possible for the web page to get permanently stuck in frozen state, due to the
BackgroundApplication layer tree freeze reason; this occurs when the web view is unparented from the view
hierarchy underneath the scope of UIWindow's -dealloc method.

During -[UIWindow dealloc], the backpointer underlying the implementation of -[UIView window] is set to nil
immediately before the subclassing method hook -willMoveToWindow: is invoked on the view hierarchy. This means
that when -willMoveToWindow: is invoked, self.window will return nil. This, in turn, puts
WKApplicationStateTrackingView in a bad state because we bail early before resetting _applicationStateTracker
in the early return below, since we (erroneously) believe that we've already been unparented from the view
hierarchy, so we don't need to do anything.

`

if (!self._contentView.window
newWindow)

return;

`

As a result, if the same web view is eventually moved back into another visible window, -didMoveToWindow bails
before setting up the _applicationStateTracker again, since it already exists from when the previous window
was still active. This means -_applicationWillEnterForeground is never called when the web view is
reintroduced to the view hierarchy, so LayerTreeFreezeReason::BackgroundApplication is never lifted.

To address this, we simply remove the debug assertion for _applicationStateTracker, and instead check whether
the application state tracker exists or not for the logic of the early return. Doing so also makes the early
return in -willMoveToWindow: consistent with the logic in one in -didMoveToWindow, which already consults
_applicationStateTracker:

`

  • (void)didMoveToWindow

{

if (!self._contentView.window
_applicationStateTracker)

return;

`

Test: ApplicationStateTracking.WindowDeallocDoesNotPermanentlyFreezeLayerTree

  • UIProcess/ios/WKApplicationStateTrackingView.mm:

(-[WKApplicationStateTrackingView willMoveToWindow:]): See above.

Tools:

Add an API test to exercise the bug. This API test is comprised of the following series of steps:

  1. Create the web view and add it under window #1.
  2. Post a "did enter background" notification.
  3. Deallocate window #1 (thereby unparenting the web view in the process).
  4. Post a "will enter foreground" notification.
  5. Add the web view under window #2.
  6. Load some HTML content and wait for a presentation update.

Before the fix, this test times out because the layer tree is permanently frozen after step (3), due to the
BackgroundApplication reason, so the presentation update in step (6) never finishes.

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/ios/ApplicationStateTracking.mm: Added.

(TestWebKitAPI::TEST):

9:28 AM Changeset in webkit [290874] by eric.carlson@apple.com
  • 14 edits in trunk/Source

Push HTMLMediaElement renderer's contentBox rect to GPU process
​https://bugs.webkit.org/show_bug.cgi?id=237444
rdar://84869202

Reviewed by Jer Noble.

Source/WebCore:

No new tests. This is a speculative fix, with new logging, for an issue I haven't
been able to reproduce.

  • html/HTMLMediaElement.cpp:

(WebCore::HTMLMediaElement::updateRenderer): Push mediaPlayerContentBoxRect to the
media player.

  • platform/graphics/MediaPlayer.cpp:

(WebCore::MediaPlayer::playerContentBoxRectChanged): Pass rect to platform player.

  • platform/graphics/MediaPlayer.h:
  • platform/graphics/MediaPlayerPrivate.h:

(WebCore::MediaPlayerPrivateInterface::playerContentBoxRectChanged):

Source/WebKit:

  • GPUProcess/media/RemoteMediaPlayerProxy.cpp:

(WebKit::RemoteMediaPlayerProxy::RemoteMediaPlayerProxy): Configuration now has
playerContentBoxRect.
(WebKit::RemoteMediaPlayerProxy::mediaPlayerContentBoxRect const):
(WebKit::RemoteMediaPlayerProxy::playerContentBoxRectChanged): Update playerContentBoxRect.

  • GPUProcess/media/RemoteMediaPlayerProxy.h:
  • GPUProcess/media/RemoteMediaPlayerProxy.messages.in:
  • GPUProcess/media/RemoteMediaPlayerProxyConfiguration.h:

(WebKit::RemoteMediaPlayerProxyConfiguration::encode const):
(WebKit::RemoteMediaPlayerProxyConfiguration::decode):

  • GPUProcess/media/cocoa/RemoteMediaPlayerProxyCocoa.mm:

(WebKit::RemoteMediaPlayerProxy::setVideoInlineSizeIfPossible): Convert from static
function so we can log.
(WebKit::RemoteMediaPlayerProxy::mediaPlayerFirstVideoFrameAvailable): Add logging.
(WebKit::RemoteMediaPlayerProxy::mediaPlayerRenderingModeChanged): Ditto.
(WebKit::RemoteMediaPlayerProxy::setVideoInlineSizeFenced): Ditto.
(WebKit::setVideoInlineSizeIfPossible): Deleted.

  • WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:

(WebKit::MediaPlayerPrivateRemote::playerContentBoxRectChanged):

  • WebProcess/GPU/media/MediaPlayerPrivateRemote.h:
  • WebProcess/GPU/media/RemoteMediaPlayerManager.cpp:

(WebKit::RemoteMediaPlayerManager::createRemoteMediaPlayer):

Mar 5, 2022:

10:59 PM Changeset in webkit [290873] by mark.lam@apple.com
  • 2 edits in trunk/Source/JavaScriptCore

Fix JITOperationList::addPointers() to support JIT_OPERATION_VALIDATION_ASSERT_ENABLED.
​https://bugs.webkit.org/show_bug.cgi?id=237504
<rdar://problem/89770507>

Reviewed by Saam Barati.

According to tagJSCCodePtrImpl(), we will only use an operation's validation entry
if Options::useJITCage(). Make JITOperationList::addPointers() conform to this.

  • assembler/JITOperationList.cpp:

(JSC::JITOperationList::addPointers):

10:50 PM Changeset in webkit [290872] by Simon Fraser
  • 13 edits
    1 delete in trunk/Source/WebCore

Replace IntRectExtent with RectEdges<int>
​https://bugs.webkit.org/show_bug.cgi?id=237495

Reviewed by Sam Weinig.

IntRectExtent was just like RectEdges<int>, so remove it.

Add operator+= for RectEdges<>, and helpers to convert from RectEdges<int> to RectEdges<LayoutUnit>.

Code that previously added a IntRectExtent to a rect now uses .expand().

For some reason initializing a RectEdges<T> with arguments std::max<T> fails to
compile, so use intermediate variables in two places.

  • Headers.cmake:
  • WebCore.xcodeproj/project.pbxproj:
  • platform/LengthBox.cpp:

(WebCore::operator<<):

  • platform/LengthBox.h:

(WebCore::toLayoutBoxExtent):

  • platform/RectEdges.h:

(WebCore::RectEdges::isZero const):
(WebCore::operator+=):

  • platform/graphics/IntRectExtent.h: Removed.
  • platform/graphics/filters/FEDropShadow.cpp:

(WebCore::FEDropShadow::outsets const):

  • platform/graphics/filters/FilterFunction.h:
  • platform/graphics/filters/FilterOperations.cpp:

(WebCore::FilterOperations::outsets const):

  • platform/graphics/filters/FilterOperations.h:
  • rendering/CSSFilter.h:
  • rendering/RenderLayer.cpp:

(WebCore::RenderLayer::setFilterBackendNeedsRepaintingInRect):
(WebCore::transparencyClipBox):
(WebCore::RenderLayer::calculateClipRects const):

  • rendering/RenderLayerFilters.cpp:

(WebCore::RenderLayerFilters::beginFilterEffect):

1:55 PM Changeset in webkit [290871] by mark.lam@apple.com
  • 3 edits in trunk/Source/JavaScriptCore

Optimize VMTraps::maybeNeedHandling().
​https://bugs.webkit.org/show_bug.cgi?id=237503

Reviewed by Saam Barati.

There's no need for VMTraps::maybeNeedHandling() to mask the VMTraps bits for
events. Under normal circumstances, there are no traps firing and the traps bits
are 0 anyway. We should optimize for this and do away with the masking. Clients
who use VMTraps::maybeNeedHandling() should and current do call VMTraps::needHandling()
to get the real story on whether there are actually traps to handle or not. Hence,
the masking in VMTraps::maybeNeedHandling() is also not needed for correctness.

We know from experience that changes in RETURN_IN_EXCEPTION can have an impact on
performance. Perhaps this change can also help performance.

  • runtime/ExceptionScope.h:
  • runtime/VMTraps.h:

(JSC::VMTraps::maybeNeedHandling const):

1:24 PM Changeset in webkit [290870] by Alan Bujtas
  • 4 edits in trunk

Remove non-standard display:block UA stylesheet rule for <layer>
​https://bugs.webkit.org/show_bug.cgi?id=236730
<rdar://problem/89372670>

Reviewed by Antti Koivisto.

Source/WebCore:

This looks to be an old WebKit (khtml?) quirk.
See also ​https://bugs.chromium.org/p/chromium/issues/detail?id=1298197

  • css/html.css:

(address, article, aside, div, footer, header, hgroup, main, nav, section):
(address, article, aside, div, footer, header, hgroup, layer, main, nav, section): Deleted.

LayoutTests:

  • inspector/css/shadow-scoped-style-expected.txt:
10:55 AM Changeset in webkit [290869] by mark.lam@apple.com
  • 8 edits in trunk/Source

Fix broken SuspendExceptionScope and remove redundant VM::DeferExceptionScope.
​https://bugs.webkit.org/show_bug.cgi?id=237441
<rdar://problem/89769627>

Reviewed by Yusuke Suzuki.

Source/JavaScriptCore:

SuspendExceptionScope was meant to do exactly the same thing that VM::DeferExceptionScope
does, except that SuspendExceptionScope hasn't been updated to handle exception
handling via VMTraps bits.

This patch will fix SuspendExceptionScope to work like VM::DeferExceptionScope,
and remove the now redundant VM::DeferExceptionScope. SuspendExceptionScope is
the better name here because the scope actually suspends any pending exception.
This is different from other Defer scopes where we prevent some new event from
arising and defer the event to a later time.

  • interpreter/FrameTracers.h:

(JSC::SuspendExceptionScope::SuspendExceptionScope):
(JSC::SuspendExceptionScope::~SuspendExceptionScope):

  • interpreter/Interpreter.cpp:

(JSC::UnwindFunctor::notifyDebuggerOfUnwinding):

  • runtime/TypeProfilerLog.cpp:

(JSC::TypeProfilerLog::processLogEntries):

  • runtime/VM.h:

(JSC::VM::restorePreviousException): Deleted.
(JSC::VM::DeferExceptionScope::DeferExceptionScope): Deleted.
(JSC::VM::DeferExceptionScope::~DeferExceptionScope): Deleted.

Source/WebCore:

  • inspector/InspectorFrontendAPIDispatcher.cpp:

(WebCore::InspectorFrontendAPIDispatcher::evaluateExpression):

  • inspector/InspectorFrontendHost.cpp:

(WebCore::InspectorFrontendHost::evaluateScriptInExtensionTab):

9:18 AM Changeset in webkit [290868] by Alan Bujtas
  • 5 edits in trunk

[IFC][Integration] Do not bail out on IFC content with floats inside.
​https://bugs.webkit.org/show_bug.cgi?id=237494

Reviewed by Antti Koivisto.

Source/WebCore:

We have support for such content now.
(This gives a noticeable coverage boost on PLT5 content.)

  • layout/integration/LayoutIntegrationCoverage.cpp:

(WebCore::LayoutIntegration::canUseForChild):

LayoutTests:

  • platform/ios/css2.1/t0905-c5525-fltcont-00-d-g-expected.txt:
  • platform/mac/css2.1/t0905-c5525-fltcont-00-d-g-expected.txt:
8:57 AM Changeset in webkit [290867] by Antti Koivisto
  • 24 edits in trunk

Resolve ::first-line style eagerly
​https://bugs.webkit.org/show_bug.cgi?id=237362

Reviewed by Alan Bujtas.

Source/WebCore:

Compute ::first-line style during style resolution instead of lazily in render tree.
This fixes bugs and clarifies the architecture in ways that a helpful for features like
container queries.

As a side effect it also makes ::first-line style animatable.

  • rendering/RenderBlock.cpp:

(WebCore::RenderBlock::firstLineBlock const): Deleted.

  • rendering/RenderBlock.h:
  • rendering/RenderElement.cpp:

(WebCore::RenderElement::RenderElement):
(WebCore::RenderElement::firstLineStyle const):
(WebCore::RenderElement::styleWillChange):
(WebCore::RenderElement::computeFirstLineStyle const): Deleted.
(WebCore::RenderElement::invalidateCachedFirstLineStyle): Deleted.

  • rendering/RenderElement.h:
  • rendering/RenderObject.cpp:

(WebCore::RenderObject::firstLineBlock const): Deleted.

  • rendering/RenderObject.h:
  • rendering/RenderRubyRun.cpp:

(WebCore::RenderRubyRun::firstLineBlock const): Deleted.

  • rendering/RenderRubyRun.h:
  • rendering/RenderTable.cpp:

(WebCore::RenderTable::firstLineBlock const): Deleted.

  • rendering/RenderTable.h:
  • rendering/RenderText.cpp:

(WebCore::RenderText::findByDisplayContentsInlineWrapperCandidate): Deleted.

  • rendering/RenderText.h:
  • rendering/style/RenderStyle.cpp:

(WebCore::RenderStyle::getCachedPseudoStyle const):

  • rendering/style/RenderStyle.h:

(WebCore::generatesBox):

  • rendering/svg/RenderSVGText.cpp:

(WebCore::RenderSVGText::firstLineBlock const): Deleted.

  • rendering/svg/RenderSVGText.h:
  • rendering/updating/RenderTreeUpdaterGeneratedContent.cpp:

(WebCore::RenderTreeUpdater::GeneratedContent::updatePseudoElement):

  • style/StyleTreeResolver.cpp:

(WebCore::Style::TreeResolver::resolveElement):
(WebCore::Style::TreeResolver::resolvePseudoElement):
(WebCore::Style::TreeResolver::resolveInheritedFirstLinePseudoElement):
(WebCore::Style::TreeResolver::makeResolutionContextForInheritedFirstLine):
(WebCore::Style::TreeResolver::boxGeneratingParent const const):
(WebCore::Style::TreeResolver::parentBoxStyle const):
(WebCore::Style::TreeResolver::resolveComposedTree):
(WebCore::Style::TreeResolver::resolvePseudoStyle): Deleted.

  • style/StyleTreeResolver.h:

LayoutTests:

8:26 AM Changeset in webkit [290866] by Alan Bujtas
  • 2 edits in trunk/Source/WebCore

[LFC][Integration] RenderInline should use ADD_REASONS_AND_RETURN_IF_NEEDED
​https://bugs.webkit.org/show_bug.cgi?id=237492

Reviewed by Antti Koivisto.

Content inside RenderInline should be accounted for when collecting coverage information.
(This patch also has a bit of a printModernLineLayoutCoverage&co refactoring.)

  • layout/integration/LayoutIntegrationCoverage.cpp:

(WebCore::LayoutIntegration::printTextForSubtree):
(WebCore::LayoutIntegration::contentLengthForSubtreeStayWithinBlockFlow):
(WebCore::LayoutIntegration::contentLengthForBlockFlow):
(WebCore::LayoutIntegration::printModernLineLayoutBlockList):
(WebCore::LayoutIntegration::printModernLineLayoutCoverage):
(WebCore::LayoutIntegration::canUseForChild):
(WebCore::LayoutIntegration::textLengthForSubtree): Deleted.
(WebCore::LayoutIntegration::collectNonEmptyLeafRenderBlockFlows): Deleted.
(WebCore::LayoutIntegration::collectNonEmptyLeafRenderBlockFlowsForCurrentPage): Deleted.

3:33 AM Changeset in webkit [290865] by youenn@apple.com
  • 5 edits in trunk

Implement remote-inbound-rtp packetsLost
​https://bugs.webkit.org/show_bug.cgi?id=237443

Reviewed by Eric Carlson.

Source/WebCore:

Take benefit of latest backend to expose RemoteInboundRtpStreamStats values inherited from ReceivedRtpStreamStats.
Covered by updated test.

  • Modules/mediastream/libwebrtc/LibWebRTCStatsCollector.cpp:

(WebCore::fillReceivedRtpStreamStats):
(WebCore::fillInboundRtpStreamStats):
(WebCore::fillRemoteInboundRtpStreamStats):

LayoutTests:

  • platform/mac/TestExpectations:
  • webrtc/video-stats.html:
3:18 AM Changeset in webkit [290864] by Oriol Brufau
  • 3 edits
    2 adds in trunk

[css-cascade] Let 'revert-layer' in lowest layer roll back to user styles
​https://bugs.webkit.org/show_bug.cgi?id=237486

Reviewed by Antti Koivisto.

LayoutTests/imported/w3c:

Add test. It still has some remaining failures due to bug 236272.

  • web-platform-tests/css/css-cascade/all-prop-revert-layer-noop-expected.txt: Added.
  • web-platform-tests/css/css-cascade/all-prop-revert-layer-noop.html: Added.

Source/WebCore:

When 'revert-layer' was used in the lowest @layer, then it would behave
as 'unset'. This patch fixes ensureRollbackCascadeForRevertLayer() to
not return nullptr and instead return ensureRollbackCascadeForRevert()
in that case. This imples that 'revert-layer' will behave like 'revert'
and roll back to user (or UA) styles.

Test: imported/w3c/web-platform-tests/css/css-cascade/all-prop-revert-layer-noop.html

  • style/StyleBuilder.cpp:

(WebCore::Style::Builder::ensureRollbackCascadeForRevertLayer):

Note: See TracTimeline for information about the timeline view.