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

Timeline



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):

Mar 4, 2022:

11:22 PM Changeset in webkit [290863] by sihui_liu@apple.com
  • 3 edits in trunk/Source/WebKit

Stop setting NSURLIsExcludedFromBackupKey attribute for localSorageDirectory in UI process
​https://bugs.webkit.org/show_bug.cgi?id=237447

Reviewed by Chris Dumez.

Let's do that on storage thread in network process when the directory is used.

Covered by existing test: WKWebView.LocalStorageDirectoryExcludedFromBackup.

  • NetworkProcess/storage/OriginStorageManager.cpp:

(WebKit::OriginStorageManager::StorageBucket::resolvedLocalStoragePath):

  • UIProcess/WebsiteData/WebsiteDataStore.cpp:

(WebKit::WebsiteDataStore::parameters):

10:48 PM Clangd edited by Brandon
(diff)
10:02 PM Changeset in webkit [290862] by sihui_liu@apple.com
  • 4 edits in trunk

Add null check for path in makeAllDirectories
​https://bugs.webkit.org/show_bug.cgi?id=237477

Reviewed by Darin Adler.

Source/WTF:

  • wtf/posix/FileSystemPOSIX.cpp:

(WTF::FileSystemImpl::makeAllDirectories):

Tools:

  • TestWebKitAPI/Tests/WTF/FileSystem.cpp:

(TestWebKitAPI::TEST_F):

9:39 PM Changeset in webkit [290861] by Simon Fraser
  • 3 edits in trunk/Source/WebCore

Optimize the padding in StyleRareInheritedData
​https://bugs.webkit.org/show_bug.cgi?id=237488

Reviewed by Cameron McCormack.

Shrink StyleRareInheritedData from 280 bytes to 264 bytes on macOS.

Also fix a missing comparison of wordSpacing in operator==.

  • rendering/style/StyleRareInheritedData.cpp:

(WebCore::StyleRareInheritedData::StyleRareInheritedData):
(WebCore::StyleRareInheritedData::operator== const):

  • rendering/style/StyleRareInheritedData.h:
6:38 PM Changeset in webkit [290860] by Tyler Wilcock
  • 2 edits in trunk/Source/WebCore

AX: Protect incoming object with Ref in AXObjectCache::textChanged
​https://bugs.webkit.org/show_bug.cgi?id=237475

Reviewed by Chris Fleizach.

This is better practice as ascending the hierarchy could cause
the object to get deleted.

  • accessibility/AXObjectCache.cpp:

(WebCore::AXObjectCache::textChanged):

6:21 PM Changeset in webkit [290859] by commit-queue@webkit.org
  • 3 edits in trunk/Source/WebKit

Change app launch scheme
​https://bugs.webkit.org/show_bug.cgi?id=237480
rdar://89781553

Patch by Harrison Weinerman <​hweinerman@apple.com> on 2022-03-04
Reviewed by Brady Eidson.

We need to change the app launch scheme and remove an entitlement that is no longer required.

  • Scripts/process-entitlements.sh:
  • webpushd/WebPushDaemon.mm:

(WebPushD::Daemon::notifyClientPushMessageIsAvailable):

6:03 PM Changeset in webkit [290858] by Tyler Wilcock
  • 9 edits
    3 adds in trunk

AX: [WebAccessibilityObjectWrapperMac AXAttributeStringSetFont] crashes when given a font with a nil postscript name, font family, or display name
​https://bugs.webkit.org/show_bug.cgi?id=237373

Reviewed by Chris Fleizach and Andres Gonzalez.

Source/WebCore:

[WebAccessibilityObjectWrapperMac AXAttributeStringSetFont] crashes when given a font with a
nil postscript name, font family, or display name. This can be
triggered with a custom SVG @font-face -- for example:

@font-face {

font-family: 'Litherum';
src: url("resources/Litherum.svg") format(svg);

}

  • { font-family: 'Litherum'; }

We fix this by checking if these values are nil before trying to add
them to a dictionary.

This patch also centralizes application of fonts to attributed strings
by moving AXAttributeStringSetFont to the base wrapper. In doing so,
we fix a bug where if [WebAccessibilityObjectWrapperBase AXAttributeStringSetStyle] was
called from a Mac-context, it set iOS font properties (e.g.
UIAccessibilityTokenFontFamily instead of NSAccessibilityFontFamilyKey).

Test: accessibility/svg-font-face.html

  • accessibility/mac/WebAccessibilityObjectWrapperBase.h:
  • accessibility/mac/WebAccessibilityObjectWrapperBase.mm:

(AXAttributedStringRangeIsValid): Added.
(AXAttributedStringSetFont): Added.

  • accessibility/mac/WebAccessibilityObjectWrapperMac.mm:

(AXAttributeStringSetStyle):
(AXAttributedStringAppendText):
(AXAttributedStringRangeIsValid):
Moved to base wrapper.
(AXAttributeStringSetFont):
Moved to base wrapper.

LayoutTests:

  • accessibility/resources/Litherum.svg: Added.
  • accessibility/svg-font-face-expected.txt: Added.
  • accessibility/svg-font-face.html: Added.
  • platform/glib/TestExpectations: Skip new test.
  • platform/ios/TestExpectations: Enable new test.
  • platform/win/TestExpectations: Skip new test.
  • platform/mac/accessibility/element-line-rects-and-text-expected.txt:

Before this patch, [WebAccessibilityObjectWrapperBase AXAttributeStringSetStyle] called the iOS
version of AXAttributeStringSetFont. This patch fixes this. The expectation for this test is updated as a result.

5:44 PM Changeset in webkit [290857] by Russell Epstein
  • 18 edits
    2 deletes in branches/safari-613-branch/Source/bmalloc

Apply patch. rdar://problem/89071706

5:06 PM Changeset in webkit [290856] by Patrick Angle
  • 16 edits in trunk/Source

REGRESSION (r284472): [ Monterey ] http/tests/websocket/tests/hybi/inspector/send-and-recieve-debugger.html is failing
​https://bugs.webkit.org/show_bug.cgi?id=237280

Reviewed by Devin Rousso.

Source/WebCore:

Covered by existing http/tests/websocket/tests/hybi/inspector/* test cases.

On macOS Monterey we use NSURLSession-based WebSockets by default, unlike earlier versions of macOS. The channel
for these sockets is implemented in WebKit::WebSocketChannel. The non-NSURLSession WebSockets channel (at
least on Cocoa platforms) is implemented in WebCore::WebSocketChannel.

As of r284472 the logic to delay the dispatch of received WebSocket message on platforms using
NSURLSession-based WebSockets is handled by WebCore::WebSocket, not the WebKit::WebSocketChannel.
WebKit::WebSocketChannel now immediately does the work it needs to, and only the delegated work to WebSocket
is queued and taken care of when the socket has resumed. This resulted in some of the instrumentation in
WebKit::WebSocketChannel being able to be called while the socket was suspended leading to events being logged
in the frontend "in the future" (e.g. before the paused script would have been able to be aware of them). To
correct this the WebKit::WebSocketChannel now provides a hook into its helper WebSocketChannelInspector
object to allow the WebCore::WebSocket to notify Web Inspector of events at the same time it is being
logically handled by the page.

Other ThreadableWebSocketChannel implementations will instead provide nullptr in place of a pointer to a
WebInspectorChannelInspector. WebCore::WebSocketChannel was not affected by the changes in r284472 as it has
a different way to guarantee that the methods containing InspectorInstrumentation were not called while the
channel was suspended (and enforced with numerous ASSERT(!m_suspended) checks).

  • Modules/websockets/ThreadableWebSocketChannel.h:

(WebCore::ThreadableWebSocketChannel::channelInspector const):

  • Modules/websockets/WebSocketChannelClient.h:
  • Add reason for error messages so they can be sent to Web Inspector.
  • Modules/websockets/WebSocket.cpp:

(WebCore::WebSocket::didReceiveMessage):
(WebCore::WebSocket::didReceiveBinaryData):
(WebCore::WebSocket::didReceiveMessageError):
(WebCore::WebSocket::didClose):

  • Modules/websockets/WebSocket.h:
  • Move inspector instrumentation calls from WebKit::WebSocketChannel to here so that they are not called until

the socket is resumed.

  • We also now wrap these instrumentation calls in an unlikely check for frontends to avoid allocating the

simulated call frames when Web Inspector isn't even open.

  • Modules/websockets/WebSocketChannelInspector.cpp:

(WebCore::WebSocketChannelInspector::WebSocketChannelInspector):
(WebCore::WebSocketChannelInspector::didCreateWebSocket const):
(WebCore::WebSocketChannelInspector::willSendWebSocketHandshakeRequest const):
(WebCore::WebSocketChannelInspector::didReceiveWebSocketHandshakeResponse const):
(WebCore::WebSocketChannelInspector::didCloseWebSocket const):
(WebCore::WebSocketChannelInspector::didReceiveWebSocketFrame const):
(WebCore::WebSocketChannelInspector::didSendWebSocketFrame const):
(WebCore::WebSocketChannelInspector::didReceiveWebSocketFrameError const):
(WebCore::WebSocketChannelInspector::createFrame):
(WebCore::WebSocketChannelInspector::didCreateWebSocket): Deleted.
(WebCore::WebSocketChannelInspector::willSendWebSocketHandshakeRequest): Deleted.
(WebCore::WebSocketChannelInspector::didReceiveWebSocketHandshakeResponse): Deleted.
(WebCore::WebSocketChannelInspector::didCloseWebSocket): Deleted.
(WebCore::WebSocketChannelInspector::didReceiveWebSocketFrame): Deleted.
(WebCore::WebSocketChannelInspector::didSendWebSocketFrame): Deleted.
(WebCore::WebSocketChannelInspector::didReceiveWebSocketFrameError): Deleted.

  • Modules/websockets/WebSocketChannelInspector.h:
  • Update to keep a WeakRef to the Document to reduce the amount of plumbing necessary to call these methods

from WebSocket.

  • Move static utility method createFrame here from WebKit::WebSocketChannel since it is only used for

inspector instrumentation.

  • Modules/websockets/WorkerThreadableWebSocketChannel.cpp:

(WebCore::WorkerThreadableWebSocketChannel::Peer::didReceiveMessageError):
(WebCore::WorkerThreadableWebSocketChannel::Bridge::connect):

  • Modules/websockets/WorkerThreadableWebSocketChannel.h:
  • Modules/websockets/ThreadableWebSocketChannelClientWrapper.cpp:

(WebCore::ThreadableWebSocketChannelClientWrapper::didReceiveMessageError):

  • Modules/websockets/ThreadableWebSocketChannelClientWrapper.h:
  • Modules/websockets/WebSocketChannel.cpp:

(WebCore::WebSocketChannel::fail):
(WebCore::WebSocketChannel::didFailSocketStream):

  • Modules/websockets/WebSocketChannel.h:
  • Update these classes to pass along a reason, if available, for errors.

Source/WebKit:

Move inspector instrumentation for things that should be delayed until the websocket has resumed (in general,
these are instrumentation points for receiving messages) into WebCore::WebSocket so that they are sent at the
expected time in the frontend, not "in the future" when script execution is suspended (e.g. while debugging).

  • WebProcess/Network/WebSocketChannel.cpp:

(WebKit::WebSocketChannel::notifySendFrame):
(WebKit::WebSocketChannel::connect):
(WebKit::WebSocketChannel::close):
(WebKit::WebSocketChannel::fail):
(WebKit::WebSocketChannel::disconnect):
(WebKit::WebSocketChannel::didReceiveText):
(WebKit::WebSocketChannel::didReceiveBinaryData):
(WebKit::WebSocketChannel::didClose):
(WebKit::WebSocketChannel::didReceiveMessageError):
(WebKit::WebSocketChannel::didSendHandshakeRequest):
(WebKit::WebSocketChannel::didReceiveHandshakeResponse):
(WebKit::createWebSocketFrameForWebInspector): Deleted.

  • WebProcess/Network/WebSocketChannel.h:
5:01 PM Changeset in webkit [290855] by Patrick Angle
  • 2 edits in trunk/Source/WebKit

Web Inspector: [Cocoa] Continually opening and closing Web Inspector sometimes crashes
​https://bugs.webkit.org/show_bug.cgi?id=237484

Reviewed by Darin Adler.

We need to handle operations on the main queue because webView:stopURLSchemeTask: will be called from the main
queue, and we must not be in middle the operation when we get the request to stop said operation, otherwise we
may attempt to call [urlSchemeTask did*], which is not permitted after we have been asked to stop that task.
If we add the operation for the WKURLSchemeTask to a different queue it is possible we will have already
started the operation on a background queue while at the same time are receiving a request to stop that same
WKURLSchemeTask.

  • UIProcess/Inspector/mac/WKInspectorResourceURLSchemeHandler.mm:

(-[WKInspectorResourceURLSchemeHandler webView:startURLSchemeTask:]):
(-[WKInspectorResourceURLSchemeHandler webView:stopURLSchemeTask:]):

4:48 PM Changeset in webkit [290854] by Chris Dumez
  • 5 edits in trunk/Source/WebCore

Modernize OriginLock
​https://bugs.webkit.org/show_bug.cgi?id=237485

Reviewed by Darin Adler.

OriginLock subclasses ThreadSafeRefCounted. As a result, it should have a create()
factory function instead of an error-prone public constructor. Its functions should
also take String parameters by const reference instead of by value.

  • Modules/webdatabase/DatabaseTracker.cpp:

(WebCore::DatabaseTracker::originLockFor):

  • Modules/webdatabase/DatabaseTracker.h:
  • Modules/webdatabase/OriginLock.cpp:

(WebCore::lockFileNameForPath):
(WebCore::OriginLock::OriginLock):
(WebCore::OriginLock::deleteLockFile):
(WebCore::OriginLock::lockFileNameForPath): Deleted.

  • Modules/webdatabase/OriginLock.h:

(WebCore::OriginLock::create):

3:45 PM Changeset in webkit [290853] by Kate Cheney
  • 6 edits
    2 adds in trunk

about:blank iframes do not always inherit parent CSP
​https://bugs.webkit.org/show_bug.cgi?id=236347
<rdar://problem/88669147>

Reviewed by Brent Fulgham.

Source/WebCore:

Test: http/tests/security/contentSecurityPolicy/block-eval-onload-in-nested-about-blank-iframe.html

Usually we initialize CSP for window when we create a jsWindowProxy
for that frame. In this case, we load an about:blank iframe that
attempts to run eval() in the onload function of its own nested
iframe. Since we never run script in frame, we don't initialize a
jsWindowProxy and thus never propogate its CSP.

This fix checks the document's CSP in FrameLoader::clear when we
initialize a new JSGlobalObject and sets the eval value in the window
accordingly to properly enforce CSP.

  • bindings/js/ScriptController.cpp:

(WebCore::ScriptController::enableEval):

  • bindings/js/ScriptController.h:
  • loader/FrameLoader.cpp:

(WebCore::FrameLoader::clear):

  • page/csp/ContentSecurityPolicy.h:

(WebCore::ContentSecurityPolicy::evalErrorMessage const):

LayoutTests:

  • http/tests/security/contentSecurityPolicy/block-eval-onload-in-nested-about-blank-iframe-expected.txt: Added.
  • http/tests/security/contentSecurityPolicy/block-eval-onload-in-nested-about-blank-iframe.html: Added

We can't use modern js-test.js and related functions because
js-test.js uses eval() and loading it makes the test time out when the
eval is blocked by the document's CSP. We can't specify unsafe-eval
because the whole point of this test is to block eval.

3:31 PM Changeset in webkit [290852] by Robert Jenner
  • 2 edits in trunk/LayoutTests

Update WPT css-scroll-snap tests
​https://bugs.webkit.org/show_bug.cgi?id=237358

Unreviewed test gardening.

  • platform/ios-wk2/TestExpectations:
3:30 PM Changeset in webkit [290851] by Russell Epstein
  • 9 edits in branches/safari-613-branch/Source

Versioning.

WebKit-7613.2.2

3:08 PM Changeset in webkit [290850] by mmaxfield@apple.com
  • 11 edits in trunk

[iOS] Books ASSERTs upon opening a book with a debug build of WebKit
​https://bugs.webkit.org/show_bug.cgi?id=237445
<rdar://problem/89776531>

Reviewed by Alex Christensen.

Source/WebCore:

  • platform/sql/SQLiteDatabase.cpp:

(WebCore::SQLiteDatabase::open):

Source/WebKit:

  • NetworkProcess/cache/NetworkCacheBlobStorage.cpp:

(WebKit::NetworkCache::BlobStorage::add):

  • UIProcess/API/APIContentRuleListStore.cpp:

(API::openAndMapContentRuleList):
(API::compiledToFile):

Source/WTF:

makeSafeToUseMemoryMapForPath() runs an ASSERT() that it was successful.
However, it's not always successful, so this ASSERT() was getting hit when
trying to open a book in Books. So, this patch makes the function return a
bool to indicate success, and updates callers to do something sensible if
it failed.

Test: FileSystemTest.makeSafeToUseMemoryMapForPath

  • wtf/FileSystem.cpp:

(WTF::FileSystemImpl::makeSafeToUseMemoryMapForPath):
(WTF::FileSystemImpl::mapToFile):

  • wtf/FileSystem.h:
  • wtf/cocoa/FileSystemCocoa.mm:

(WTF::FileSystemImpl::makeSafeToUseMemoryMapForPath):

Tools:

  • TestWebKitAPI/Tests/WTF/FileSystem.cpp:

(TestWebKitAPI::TEST_F):

2:57 PM Changeset in webkit [290849] by Chris Dumez
  • 21 edits
    2 adds in trunk

Home link on weather.gov is not working
​https://bugs.webkit.org/show_bug.cgi?id=237451
<rdar://60409277>

Reviewed by Geoff Garen.

LayoutTests/imported/w3c:

  • web-platform-tests/html/browsers/browsing-the-web/overlapping-navigations-and-traversals/tentative/anchor-fragment-history-back-on-click-expected.txt: Added.
  • web-platform-tests/html/browsers/browsing-the-web/overlapping-navigations-and-traversals/tentative/anchor-fragment-history-back-on-click.html: Added.

Add layout test coverage (already upstreamed to WPT).

  • web-platform-tests/html/browsers/browsing-the-web/overlapping-navigations-and-traversals/tentative/cross-document-traversal-same-document-nav-expected.txt:
  • web-platform-tests/html/browsers/browsing-the-web/overlapping-navigations-and-traversals/tentative/same-document-traversal-same-document-nav-expected.txt:

Rebaseline a couple of WPT tests that are now failing. I have verified that these tests are fully failing (and in the same way) in Blink.
In Gecko, only the second subtest in each of these tests is failing.

Source/WebCore:

According to the HTML specification [1], when history.back() is called, we are supposed to
resolve the history entry based on the delta (-1), then we're supposed to queue a task to
traverse the history to that particular entry.

However, WebKit was merely scheduling a task to navigate the history with a delta of -1.
We only resolve the target history entry once the scheduled task runs asynchronously.
As a result, we could end up navigating to a different history entry than we'd expect if
the history list changes between the call to history.back() and the actual execution of
the task to traverse the history list. In particular, fragment navigations can cause
synchronous navigations and thus add new history entries.

On weather.gov, the "HOME" anchor looks like so:
<a href="#" onclick="history.back();">HOME</a>

Per the DOM specification, when clicking the anchor, we'd first call history.back() and
then run the anchor activation behavior that would do a fragment navigation to "#".
The history.back() call would schedule to task to navigate back, then we'd navigate to
"#" synchronously, which would add a new history entry. Once the task to navigate back
would run asynchronously, we would navigate back to the same page (but without the fragment)
instead of going back to the home page.

[1] ​https://html.spec.whatwg.org/multipage/history.html#traverse-the-history-by-a-delta

Test: imported/w3c/web-platform-tests/html/browsers/browsing-the-web/overlapping-navigations-and-traversals/tentative/anchor-fragment-history-back-on-click.html

  • history/BackForwardClient.h:
  • history/BackForwardController.cpp:

(WebCore::BackForwardController::containsItem const):

  • history/BackForwardController.h:
  • loader/EmptyClients.cpp:
  • loader/NavigationScheduler.cpp:

(WebCore::ScheduledHistoryNavigation::ScheduledHistoryNavigation):
(WebCore::NavigationScheduler::scheduleHistoryNavigation):

Source/WebKit:

  • WebProcess/WebPage/WebBackForwardListProxy.cpp:

(WebKit::WebBackForwardListProxy::removeItem):
(WebKit::WebBackForwardListProxy::containsItem const):

  • WebProcess/WebPage/WebBackForwardListProxy.h:

Source/WebKitLegacy/mac:

  • History/BackForwardList.h:
  • History/BackForwardList.mm:

(BackForwardList::containsItem const):
(BackForwardList::containsItem): Deleted.

Source/WebKitLegacy/win:

  • BackForwardList.cpp:

(BackForwardList::containsItem):

  • BackForwardList.h:
  • WebBackForwardList.cpp:

(WebBackForwardList::containsItem):

LayoutTests:

Skip WPT tests that is timing out. I have verified that this WPT test is timing out in Blink as well.

2:43 PM Changeset in webkit [290848] by Simon Fraser
  • 3 edits in trunk/Source/WebCore

Use an OptionSet<> for GraphicsContextCGFlags
​https://bugs.webkit.org/show_bug.cgi?id=237482

Reviewed by Wenson Hsieh.

Mechanical change to use an OptionSet<> for GraphicsContextCG::m_contextFlags.

  • platform/graphics/cg/GraphicsContextCG.cpp:

(WebCore::GraphicsContextCG::setIsCALayerContext):
(WebCore::GraphicsContextCG::isCALayerContext const):
(WebCore::GraphicsContextCG::setIsAcceleratedContext):
(WebCore::GraphicsContextCG::renderingMode const):

  • platform/graphics/cg/GraphicsContextPlatformPrivateCG.h:

(WebCore::GraphicsContextPlatformPrivate::GraphicsContextPlatformPrivate):
(): Deleted.

2:12 PM Changeset in webkit [290847] by Simon Fraser
  • 2 edits in trunk/Source/WebKit

Crash under ScrollingCoordinatorMac::hasNodeWithAnimatedScrollChanged()
​https://bugs.webkit.org/show_bug.cgi?id=237478
<rdar://89072235>

Reviewed by Alan Bujtas.

Crash data show that r290109 failed to fix this crash; the actual cause of the crash is a
null m_page on TiledCoreAnimationScrollingCoordinator, diagnosed by noting that the crash
offset corresponds to the offset of m_renderingUpdateRemainingSteps in Page.

  • WebProcess/WebPage/mac/TiledCoreAnimationScrollingCoordinator.mm:

(WebKit::TiledCoreAnimationScrollingCoordinator::hasNodeWithAnimatedScrollChanged):

2:10 PM Changeset in webkit [290846] by Chris Dumez
  • 4 edits in trunk

URL's isolatedCopy() optimization when called on a r-value reference doesn't work
​https://bugs.webkit.org/show_bug.cgi?id=237481

Reviewed by Geoffrey Garen.

Source/WTF:

URL has an isolatedCopy() implementation that attempts to optimize the case where
it is called on a r-value reference. The idea is to rely on the String's
isolatedCopy() implementation which is optimized when called on a r-value reference.

Note that there are some specific conditions under which the String implementation
is able to avoid the copy (see String::isSafeToSendToAnotherThread()).
Namely, the StringImpl's refcount needs to be 1 and it cannot be backed by an
AtomStringImpl.

The issue was that URL::isolatedCopy() would first copy the URL, which would copy
its m_string and thus bump its refcount. As a result, m_string's refcount could
never be 1 and the optimization could never kick in.

  • wtf/URL.cpp:

(WTF::URL::isolatedCopy):

Tools:

Add API test coverage.

  • TestWebKitAPI/Tests/WTF/URL.cpp:

(TestWebKitAPI::TEST_F):

2:08 PM Changeset in webkit [290845] by commit-queue@webkit.org
  • 6 edits
    3 adds in trunk/Source/WebCore

Support constants in IDL namespaces.
​https://bugs.webkit.org/show_bug.cgi?id=232557
<radr://problem/85142162>

Patch by Dan Glastonbury <​djg@apple.com> on 2022-03-04
Reviewed by Sam Weinig.

Test: bindings/script/test/TestNamespaceConst.idl

  • bindings/scripts/CodeGeneratorJS.pm:

(GenerateConstructorHelperMethods):
If namespace contains only constants, globalObject is unused
produces a compile error. Add UNUSED_PARAM to quiet error.

  • bindings/scripts/IDLAttributes.json:
  • bindings/scripts/IDLParser.pm:

(convertNamespaceToInterface): Copy namespace constants to new interface.
(applyTypedefs): Apply typedefs to namespace constants.
(parseNamespace): Added parsed constants to namespace's list of constants.
(parseNamespaceMember): Accept constants as namespace members.

  • bindings/scripts/test/BindingTestGlobalConstructors.idl:
  • bindings/scripts/test/JS/*: Updated.
  • bindings/scripts/test/SupplementalDependencies.dep:
  • bindings/scripts/test/TestNamespaceConst.idl: Added.
1:58 PM Changeset in webkit [290844] by Russell Epstein
  • 1 copy in tags/Safari-614.1.5.7

Tag Safari-614.1.5.7.

1:44 PM Changeset in webkit [290843] by Russell Epstein
  • 9 edits in branches/safari-614.1.5-branch/Source

Versioning.

WebKit-7614.1.5.7

1:00 PM Changeset in webkit [290842] by Russell Epstein
  • 1 copy in tags/Safari-613.2.1

Tag Safari-613.2.1.

12:35 PM Changeset in webkit [290841] by Chris Dumez
  • 8 edits
    2 adds in trunk

Load event never firing after form is submitted
​https://bugs.webkit.org/show_bug.cgi?id=235407
<rdar://problem/87831049>

Reviewed by Geoffrey Garen.

LayoutTests/imported/w3c:

Rebaseline WPT tests that are no longer timing out.

  • web-platform-tests/html/semantics/forms/form-submission-target/rel-base-target-expected.txt:
  • web-platform-tests/html/semantics/forms/form-submission-target/rel-button-target-expected.txt:
  • web-platform-tests/html/semantics/forms/form-submission-target/rel-form-target-expected.txt:
  • web-platform-tests/html/semantics/forms/form-submission-target/rel-input-target-expected.txt:

Source/WebCore:

In Document::implicitClose(), we early return (and thus don't fire the load
event) if there is a location change pending. To determine if there is a
location change pending, we rely on NavigationScheduler::locationChangePending()
which checks if there is a schedule navigation or not. This usually works fine.

However, when a form gets submitted with a target that is "_blank",
FrameLoader::submitForm() is not able to find the target frame (since we'll need
to create one) and it ends up using the current frame's scheduler. The idea is
that once the navigation actually triggers, FrameLoader::loadFrameRequest() will
check the target and create the new Frame.

The issue is that as a result of this, NavigationScheduler::locationChangePending()
returns true for the submitter's frame while such form submission is scheduled,
even though the navigation will actually happen in another (new) frame. To address
the issue, I updated NavigationScheduler::locationChangePending() to check that
the pending navigation is actually for the current frame.

Test: http/tests/loading/form-submission-no-load-event.html

  • loader/NavigationScheduler.cpp:

(WebCore::ScheduledNavigation::targetIsCurrentFrame const):
(WebCore::NavigationScheduler::locationChangePending):
(WebCore::ScheduledFormSubmission::ScheduledFormSubmission): Deleted.

LayoutTests:

Add layout test coverage (Based on reduction from Sam Sneddon).

  • http/tests/loading/form-submission-no-load-event-expected.txt: Added.
  • http/tests/loading/form-submission-no-load-event.html: Added.
12:33 PM Changeset in webkit [290840] by J Pascoe
  • 2 edits in trunk/Source/WebKit

[WebAuthn] Don't use decidePolicyForLocalAuthenticator for Web Authentication Modern
​https://bugs.webkit.org/show_bug.cgi?id=225646
rdar://78147681

Reviewed by Brent Fulgham.

decidePolicyForLocalAuthenticator is not implemented for the _WKWebAuthenticationPanelDelegate
used for modern because the prompt to allow Touch/FaceID comes earlier in the process.

  • UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:

(WebKit::LocalAuthenticator::makeCredential):

11:40 AM Changeset in webkit [290839] by Said Abou-Hallawa
  • 5 edits in trunk

[GPU Process] Canvas compositing buffer should be created through its GraphicsContext
​https://bugs.webkit.org/show_bug.cgi?id=237260
rdar://89196918

Reviewed by Simon Fraser.

Source/WebCore:

If the backend of the underlying ImageBuffer of the canvas is remote the
compositing ImageBuffer will also be remote. This will transfer the whole
compositing operation to GPUProcess.

The layout test fast/canvas/canvas-composite-canvas.html crashes because
of this bug on the GPUP layout bots.

  • html/canvas/CanvasRenderingContext2DBase.cpp:

(WebCore::CanvasRenderingContext2DBase::fullCanvasCompositedDrawImage):
(WebCore::CanvasRenderingContext2DBase::createCompositingBuffer): Deleted.

  • html/canvas/CanvasRenderingContext2DBase.h:

LayoutTests:

  • gpu-process/TestExpectations:
11:15 AM Changeset in webkit [290838] by commit-queue@webkit.org
  • 6 edits in trunk/Source/WebCore

"OffscreenCanvas" in IDLs doesn't seem to be able to be compiled
​https://bugs.webkit.org/show_bug.cgi?id=232733
<rdar://problem/85318653>

Patch by Dan Glastonbury <​djg@apple.com> on 2022-03-04
Reviewed by Sam Weinig.

OffscreenCanvas is controlled by ENABLE flags. Add conditional
compilation to handle OffscreenCanvas to the WebGPU IDL bindings
when the OffscreenCanvas feature is enabled.

  • Modules/WebGPU/GPUCanvasContext.cpp:

(WebCore::GPUCanvasContext::canvas):

  • Modules/WebGPU/GPUCanvasContext.h:
  • Modules/WebGPU/GPUCanvasContext.idl:

Add OffscreenCanvas to canvas attribute when it is enabled.

  • Modules/WebGPU/GPUImageCopyExternalImage.h:
  • Modules/WebGPU/GPUImageCopyExternalImage.idl:

Add OffscreenCanvas to source attribute when it is enabled.

10:46 AM Changeset in webkit [290837] by eric.carlson@apple.com
  • 5 edits in trunk/Source/WebCore

[Cocoa] Crash in MediaPlayerPrivateAVFoundationObjC::createAVAssetForURL
​https://bugs.webkit.org/show_bug.cgi?id=237456
rdar://80407863

Reviewed by Jer Noble.

  • platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:

(WebCore::MediaPlayerPrivateAVFoundation::enableInheritURIQueryComponent const): Create
and use a static, never destroyed, AtomString instead of creating one every time
a AVURLAsset is created. New method used by both AVF media players.

  • platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.h:
  • platform/graphics/avfoundation/cf/MediaPlayerPrivateAVFoundationCF.cpp:

(WebCore::MediaPlayerPrivateAVFoundationCF::createAVAssetForURL): Call enableInheritURIQueryComponent.

  • platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:

(WebCore::MediaPlayerPrivateAVFoundationObjC::createAVAssetForURL): Ditto.

10:03 AM Changeset in webkit [290836] by sihui_liu@apple.com
  • 5 edits in trunk/Source/WebCore

IDB serialization thread should pass isolated copy of IndexIDToIndexKeyMap to storage thread
​https://bugs.webkit.org/show_bug.cgi?id=237455

Reviewed by Chris Dumez.

  • Modules/indexeddb/server/MemoryObjectStore.cpp:

(WebCore::IDBServer::MemoryObjectStore::addRecord):

  • Modules/indexeddb/server/UniqueIDBDatabase.cpp:

(WebCore::IDBServer::UniqueIDBDatabase::putOrAdd):

  • bindings/js/IDBBindingUtilities.cpp:

(WebCore::generateIndexKeyMapForValueIsolatedCopy):
(WebCore::generateIndexKeyMapForValue): Deleted.

  • bindings/js/IDBBindingUtilities.h:
9:44 AM Changeset in webkit [290835] by pvollan@apple.com
  • 3 edits in trunk/Source/WebKit

[iOS] Hard link AVPictureInPictureController
​https://bugs.webkit.org/show_bug.cgi?id=237227

Reviewed by Brent Fulgham.

Hard linking instead of soft linking should be a small performance improvement.

  • Configurations/WebKit.xcconfig:
  • UIProcess/Cocoa/WebProcessPoolCocoa.mm:

(WebKit::WebProcessPool::platformInitializeWebProcess):

9:16 AM Changeset in webkit [290834] by Aditya Keerthi
  • 5 edits in trunk

[iOS] Unable to scroll to a found text range when there is an existing selection
​https://bugs.webkit.org/show_bug.cgi?id=237407
rdar://89653213

Reviewed by Wenson Hsieh.

Source/WebCore:

Scrolling to a found text range is performed by creating a
TemporarySelectionChange and using the RevealSelectionBounds
TemporarySelectionOption. When a TemporarySelectionChange is
destroyed, the original selection is restored.

Currently, the selection is restored using the same set of selection
options used to make the temporary selection. Consequently, whenever a
"reveal" option is specified, WebKit scrolls to reveal the temporary
selection, and then scrolls again to reveal the original selection.
This behavior means that an attempt to scroll to a found text range
will fail if the document has an existing selection.

To fix, do not add any of the "reveal" options to the set of selection
options when restoring the original selection during a
TemporarySelectionChange. The only other features that use
TemporarySelectionChange with "reveal" options are App Highlights
and Scroll To Text Fragment. Neither of these features require WebKit
to scroll to the original selection.

  • editing/Editor.cpp:

(WebCore::TemporarySelectionChange::TemporarySelectionChange):
(WebCore::TemporarySelectionChange::~TemporarySelectionChange):
(WebCore::TemporarySelectionChange::setSelection):

  • editing/Editor.h:

Tools:

Add an API test that sets a selection in the document, finds some
text outside the viewport, and scrolls to make the found text
visible.

  • TestWebKitAPI/Tests/WebKitCocoa/FindInPage.mm:

(-[TestScrollViewDelegate init]):
(-[TestScrollViewDelegate scrollViewDidEndScrollingAnimation:]):
(TEST):

8:51 AM Changeset in webkit [290833] by Tyler Wilcock
  • 3 edits in trunk/Source/WebCore

AX ITM: Updating m_pendingLoadingProgress can cause deadlock on AXIsolatedTree::m_changeLogLock
​https://bugs.webkit.org/show_bug.cgi?id=237402

Reviewed by Chris Fleizach.

AXIsolatedTree::m_pendingLoadingProgress is currently guarded by
AXIsolatedTree::m_changeLogLock. Because loading can happen at any time,
deadlocks can happen in this sequence:

  1. AXIsolatedTree::updateLoadingProgress is called on the main thread while the secondary thread holds the lock
  2. The secondary thread is holding the lock to service an AX request, and said AX request does something to call into the main thread (e.g. AXLOGs an isolated object, which causes a dispatch to the main thread as part of AXIsolatedObject::outerHTML).
  3. Deadlock

This patch fixes this by making m_loadingProgress threadsafe
via std::atomic<double> and removing m_pendingLoadingProgress.

This patch also removes an unnecessary acquisition of m_changeLogLock
in AXIsolatedTree::focusedNode(). This function is only called on the
secondary-thread, and only accesses secondary-thread safe functions
and member variables (nodeForID, m_focusedNodeID), so we don't need the lock.

  • accessibility/isolatedtree/AXIsolatedTree.cpp:

(WebCore::AXIsolatedTree::focusedNode):
Removed unnecessary m_changeLogLock acquisition.
(WebCore::AXIsolatedTree::updateLoadingProgress):
Update m_loadingProgress directly instead of the now deleted intermediary
m_pendingLoadingProgress.
(WebCore::AXIsolatedTree::applyPendingChanges):

  • accessibility/isolatedtree/AXIsolatedTree.h:

Remove m_pendingLoadingProgress.

7:49 AM Changeset in webkit [290832] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebCore

Top layers should not be moved
​https://bugs.webkit.org/show_bug.cgi?id=237305

Patch by Rob Buis <​rbuis@igalia.com> on 2022-03-04
Reviewed by Tim Nguyen.

Top layers are always children of RenderView and should not be moved.

  • rendering/RenderElement.cpp:

(WebCore::RenderElement::moveLayers):

7:42 AM Changeset in webkit [290831] by graouts@webkit.org
  • 4 edits in trunk

[web-animations] "inherit" values should trigger keyframe recomputation if any previous effect has changed that property
​https://bugs.webkit.org/show_bug.cgi?id=237471

Reviewed by Antti Koivisto.

LayoutTests/imported/w3c:

  • web-platform-tests/web-animations/responsive/textIndent-expected.txt:

Source/WebCore:

When we fixed 237371 we only looked at the unanimated style, but we should account for any previous keyframe effect
modifying a property set to "inherit" for the current effect.

  • animation/KeyframeEffectStack.cpp:

(WebCore::KeyframeEffectStack::applyKeyframeEffects):

7:11 AM Changeset in webkit [290830] by Kate Cheney
  • 4 edits
    2 adds in trunk

CSP report does not get sent to the document in the case of a detached element
​https://bugs.webkit.org/show_bug.cgi?id=237440
<rdar://problem/89081463>

Reviewed by Chris Dumez.

Source/WebCore:

Test: http/tests/security/contentSecurityPolicy/report-violation-to-document-after-element-has-been-detached.html

Only send a violation report to the element if it is connected. Check
right before dispatching in case the element gets detached after the
security policy violation has been created. If the element is not
connected in this case, we send the report to the document.

  • dom/Element.cpp:

(WebCore::Element::enqueueSecurityPolicyViolationEvent):

  • page/csp/ContentSecurityPolicy.cpp:

(WebCore::ContentSecurityPolicy::reportViolation const):
Also sets the composed value on the violation event as per the spec.

LayoutTests:

  • http/tests/security/contentSecurityPolicy/report-violation-to-document-after-element-has-been-detached-expected.txt: Added.
  • http/tests/security/contentSecurityPolicy/report-violation-to-document-after-element-has-been-detached.html: Added.
5:22 AM Changeset in webkit [290829] by youenn@apple.com
  • 3 edits in trunk/Source/WebKit

LibWebRTCCodecs::setEncodeRates should send LibWebRTCCodecsProxy::SetEncodeRates only when the encoder is live
​https://bugs.webkit.org/show_bug.cgi?id=237421

Reviewed by Darin Adler.

We were previously not asserting in LibWebRTCCodecsProxy::setEncodeRates and we were missing some encode rate orders.
This is due to the fact that when creating an encoder, we are hopping to main thread, then to work queue to send the message to create an encoder.
In LibWebRTCCodecs::setEncodeRates, we were hopping to main thread if needed.
If the encoder connection is null, we are now hopping to main thread, then to work queue as done when creating an encoder.
Since there is a time where LibWebRTCCodecsProxy::setEncodeRates might have sent encode rates, we bail out early to not set based on old bitrates.

Covered by existing tests not crashing in LibWebRTCCodecsProxy::setEncodeRates.

  • WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp:

(WebKit::LibWebRTCCodecs::setEncodeRates):

  • WebProcess/GPU/webrtc/LibWebRTCCodecs.h:
5:16 AM Changeset in webkit [290828] by Angelos Oikonomopoulos
  • 2 edits in trunk/Source/JavaScriptCore

[JSC] Improve reuse of known register values on ARMv7
​https://bugs.webkit.org/show_bug.cgi?id=237424

Reviewed by Žan Doberšek.

Reduce the generated code size by introducing and pervasively using
setupArmAddress(AbsoluteAddress address, ...). This effectively
replaces sequences of e.g.

movw r6, cst1
movt r6, cst2
strd r0, r1, [r6]

with

strd r0, r1, [r6, offset]

when a close enough address is already available in r6.

While here, change short_move to only emit an add/sub if this results in an
actual reduction in code size. When the add/sub would be neutral,
prefer loading an immediate as that doesn't introduce a data dependency
between the instructions.

This results in a measurable but small (< 1%) reduction in the
generated code size on JS2.

Hat tip to Geza Lore for the suggestions.

  • assembler/MacroAssemblerARMv7.h:

(JSC::MacroAssemblerARMv7::add32):
(JSC::MacroAssemblerARMv7::add64):
(JSC::MacroAssemblerARMv7::or8):
(JSC::MacroAssemblerARMv7::or16):
(JSC::MacroAssemblerARMv7::or32):
(JSC::MacroAssemblerARMv7::sub32):
(JSC::MacroAssemblerARMv7::load32):
(JSC::MacroAssemblerARMv7::load8):
(JSC::MacroAssemblerARMv7::load16):
(JSC::MacroAssemblerARMv7::store32):
(JSC::MacroAssemblerARMv7::store8):
(JSC::MacroAssemblerARMv7::store16):
(JSC::MacroAssemblerARMv7::storePair32):
(JSC::MacroAssemblerARMv7::short_move):
(JSC::MacroAssemblerARMv7::add32Impl):
(JSC::MacroAssemblerARMv7::branch8):
(JSC::MacroAssemblerARMv7::branchTest32):
(JSC::MacroAssemblerARMv7::branchTest8):
(JSC::MacroAssemblerARMv7::branchTest16):
(JSC::MacroAssemblerARMv7::farJump):
(JSC::MacroAssemblerARMv7::absoluteAddressWithinShortOffset):
(JSC::MacroAssemblerARMv7::setupArmAddress):

4:01 AM Changeset in webkit [290827] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebCore

Iteration to search for least active WebGLRenderingContextBase could use min_element
​https://bugs.webkit.org/show_bug.cgi?id=237464

Patch by Kimmo Kinnunen <​kkinnunen@apple.com> on 2022-03-04
Reviewed by Antti Koivisto.

Apply review comments after landing bug 222411 r290816.

  • html/canvas/WebGLRenderingContextBase.cpp:

(WebCore::addActiveContext):

3:55 AM Changeset in webkit [290826] by commit-queue@webkit.org
  • 2 edits in trunk/Tools

[Flatpak SDK] Upgrade from llvm12 to llvm13
​https://bugs.webkit.org/show_bug.cgi?id=237430

Patch by Philippe Normand <​pnormand@igalia.com> on 2022-03-04
Reviewed by Adrian Perez de Castro.

  • flatpak/flatpakutils.py:

(WebkitFlatpak.run_in_sandbox):
(WebkitFlatpak._get_dependency_packages):

3:37 AM Changeset in webkit [290825] by Adrian Perez de Castro
  • 2 edits in trunk/Source/WebKit

[GTK][WPE] Documentation for webkit_web_context_set_spell_checking_languages() is incomplete
​https://bugs.webkit.org/show_bug.cgi?id=237465

Reviewed by Carlos Garcia Campos.

  • UIProcess/API/glib/WebKitWebContext.cpp: Improve documentation.
1:15 AM Changeset in webkit [290824] by youenn@apple.com
  • 16 edits in trunk/Source/WebKit

Introduce routines to exchange SharedVideoFrame::Buffer directly
​https://bugs.webkit.org/show_bug.cgi?id=237267

Reviewed by Eric Carlson.

Define explictly SharedVideoFrame::Buffer as Variant of the various buffer representations.
This allows to move more code in SharedVideoFrame for instance by adding direct support of sending webrtc::VideoFrame buffers in SharedVideoFrame.
Reuse that code in LibWebRTCCodecs as a refactoring/simplification.
Reuse that code in RemoteVideoFrameObjectHeap which allows to exchange IOSurfaces in case WebProcess can use them.
This is used when encoding such frames using software encoders.

Covered by existing tests.

  • GPUProcess/media/RemoteVideoFrameObjectHeap.cpp:
  • GPUProcess/media/RemoteVideoFrameObjectHeap.h:
  • GPUProcess/media/RemoteVideoFrameObjectHeap.messages.in:
  • GPUProcess/webrtc/LibWebRTCCodecsProxy.h:
  • GPUProcess/webrtc/LibWebRTCCodecsProxy.messages.in:
  • GPUProcess/webrtc/LibWebRTCCodecsProxy.mm:
  • WebKit.xcodeproj/project.pbxproj:
  • WebProcess/GPU/media/RemoteVideoFrameProxy.cpp:
  • WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp:
  • WebProcess/GPU/webrtc/RemoteVideoFrameObjectHeapProxy.h:
  • WebProcess/GPU/webrtc/RemoteVideoFrameObjectHeapProxyProcessor.cpp:
  • WebProcess/GPU/webrtc/RemoteVideoFrameObjectHeapProxyProcessor.h:
  • WebProcess/GPU/webrtc/RemoteVideoFrameObjectHeapProxyProcessor.messages.in:
  • WebProcess/GPU/webrtc/SharedVideoFrame.cpp:
  • WebProcess/GPU/webrtc/SharedVideoFrame.h:
12:53 AM Changeset in webkit [290823] by graouts@webkit.org
  • 8 edits in trunk

[web-animations] keyframe values set to "inherit" should recompute their values when the inherited value changes
​https://bugs.webkit.org/show_bug.cgi?id=237371

Reviewed by Antti Koivisto.

LayoutTests/imported/w3c:

  • web-platform-tests/web-animations/responsive/lineHeight-expected.txt:
  • web-platform-tests/web-animations/responsive/opacity-expected.txt:
  • web-platform-tests/web-animations/responsive/textIndent-expected.txt:

Source/WebCore:

We now keep track of properties set to "inherit" in keyframes such that we may determine when the
computed value may have changed when resolving animations.

  • animation/KeyframeEffect.cpp:

(WebCore::KeyframeEffect::processKeyframes):

  • animation/KeyframeEffect.h:

(WebCore::KeyframeEffect::inheritedProperties const):

  • animation/KeyframeEffectStack.cpp:

(WebCore::KeyframeEffectStack::applyKeyframeEffects):

12:42 AM Changeset in webkit [290822] by sihui_liu@apple.com
  • 3 edits in trunk/Source/WebCore

SQLiteDatabase::open should return early if journal mode cannot be set
​https://bugs.webkit.org/show_bug.cgi?id=237130
<rdar://83130954>

Reviewed by Darin Adler.

Add early return in SQLiteDatabase::open if key operation fails; also make sure error is properly set and
database is closed in the case.

  • platform/sql/SQLiteDatabase.cpp:

(WebCore::SQLiteDatabase::open):
(WebCore::SQLiteDatabase::useWALJournalMode):
(WebCore::SQLiteDatabase::close):

  • platform/sql/SQLiteDatabase.h:
12:10 AM Changeset in webkit [290821] by youenn@apple.com
  • 5 edits in trunk

webrtc/canvas-to-peer-connection.html is flakily failing a test assertion
​https://bugs.webkit.org/show_bug.cgi?id=237423

Reviewed by Eric Carlson.

Source/WebCore:

Make sure the rotation session size is matching the buffer size.
Covered by updated test.

  • platform/graphics/cocoa/GraphicsContextGLCocoa.h:
  • platform/graphics/cocoa/GraphicsContextGLCocoa.mm:

(WebCore::GraphicsContextGLCocoa::paintCompositedResultsToMediaSample):

LayoutTests:

WebRTC pipeline is lossy so frames might disappear.
For that reason, we need to send multiple times the same frame to ensure we can read the expected frame.
To ensure we are not reading a previous test frame, what we do is changing the size of the canvas before doing the test.
This patch reduces the number of iterations to ensure the test is not too long to run.

  • webrtc/canvas-to-peer-connection.html:
12:07 AM Changeset in webkit [290820] by youenn@apple.com
  • 4 edits in trunk/Source/WebCore

AVVideoCaptureSource should reuse CaptureDevice label
​https://bugs.webkit.org/show_bug.cgi?id=237363
<rdar://88301613>

Reviewed by Eric Carlson.

We are getting AV device name through AVCaptureDevice.localizedName, first in UIProcess, then in GPUProcess.
To make sure we always use the ones from UIProcess (which are the ones exposed through mediaDevices.enumerateDevices),
We make sure to use CaptureDevice.label when creating an AVVideoCaptureSource.

Manually tested.

  • platform/mediastream/mac/AVVideoCaptureSource.h:
  • platform/mediastream/mac/AVVideoCaptureSource.mm:

(WebCore::AVVideoCaptureSource::create):
(WebCore::AVVideoCaptureSource::AVVideoCaptureSource):

  • platform/mediastream/mac/RealtimeMediaSourceCenterMac.cpp:
Note: See TracTimeline for information about the timeline view.