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

Timeline



Jul 6, 2021:

11:05 PM Changeset in webkit [279639] by commit-queue@webkit.org
  • 5 edits
    2 deletes in trunk

Unreviewed, reverting r279628.
​https://bugs.webkit.org/show_bug.cgi?id=227737

Test does not work since it relies on r279546, which is
reverted due to Speedometer regression

Reverted changeset:

"SubtleCrypto should only be exposed to secure contexts"
​https://bugs.webkit.org/show_bug.cgi?id=227725
​https://commits.webkit.org/r279628

8:49 PM Changeset in webkit [279638] by ysuzuki@apple.com
  • 3 edits in trunk/Source/JavaScriptCore

Unreviewed, build fix after r279630
​https://bugs.webkit.org/show_bug.cgi?id=223166

  • DerivedSources-input.xcfilelist:
  • DerivedSources-output.xcfilelist:
8:44 PM Changeset in webkit [279637] by ysuzuki@apple.com
  • 2 edits in trunk/Source/WebCore

Unreviewed, need CryptoKey and SubtleCrypto names

  • bindings/js/WebCoreBuiltinNames.h:
8:36 PM Changeset in webkit [279636] by Simon Fraser
  • 3 edits
    2 adds in trunk

REGRESSION (r262237) Safari 14.x shows graphics artifacts when scrolling, using drop-down menus or just moving the mouse
​https://bugs.webkit.org/show_bug.cgi?id=220892
<rdar://73538454>

Reviewed by Alan Bujtas.

Source/WebCore:

Fix an issue with backing sharing where a composited layer needs to interrupted a backing
sharing sequence. In some cases, a layer that became composited via an indirect reason
(like overflow positioning) would not interrupt a backing sharing sequence, leaving a dangling
layer that ended up painting into the wrong ancestor.

The fix is to ensure that BackingSharingState::updateBeforeDescendantTraversal() and
BackingSharingState::updateAfterDescendantTraversal() have the same behavior when a layer
becomes composited (thus interrupting the sequence). However, we also have ensure that
updateAfterDescendantTraversal() doesn't erroeously interrupt the sequence when the sequence
was initiated by some descendant, hence the check against the preDescendantProviderCandidate.

Test: compositing/shared-backing/backing-sharing-compositing-change.html

  • rendering/RenderLayerCompositor.cpp:

(WebCore::RenderLayerCompositor::BackingSharingState::endBackingSharingSequence):
(WebCore::RenderLayerCompositor::BackingSharingState::updateBeforeDescendantTraversal):
(WebCore::RenderLayerCompositor::BackingSharingState::updateAfterDescendantTraversal):
(WebCore::RenderLayerCompositor::computeCompositingRequirements):
(WebCore::RenderLayerCompositor::traverseUnchangedSubtree):

LayoutTests:

  • compositing/shared-backing/backing-sharing-compositing-change-expected.html: Added.
  • compositing/shared-backing/backing-sharing-compositing-change.html: Added.
8:12 PM Changeset in webkit [279635] by commit-queue@webkit.org
  • 122 edits
    5 deletes in trunk

Unreviewed, reverting r279546, r279554, r279558 and r279567.
​https://bugs.webkit.org/show_bug.cgi?id=227732

Speedometer/jQuery-TodoMVC 2-3% regression

Reverted changesets:

"[WebIDL] Rework runtime enabled properties leveraging
PropertyCallback"
​https://bugs.webkit.org/show_bug.cgi?id=227275
​https://commits.webkit.org/r279546

"[WebIDL] Generate constructor's hash table in
GenerateConstructorHelperMethods"
​https://bugs.webkit.org/show_bug.cgi?id=227668
​https://commits.webkit.org/r279554

"[WebIDL] Simplify generation of runtime conditionally read-
write attributes"
​https://bugs.webkit.org/show_bug.cgi?id=227672
​https://commits.webkit.org/r279558

"Use AbortSignal's [PrivateIdentifier] whenSignalAborted()
static method"
​https://bugs.webkit.org/show_bug.cgi?id=227673
​https://commits.webkit.org/r279567

6:09 PM Changeset in webkit [279634] by Alan Coon
  • 1 copy in tags/Safari-612.1.22.3.1

Tag Safari-612.1.22.3.1.

6:06 PM Changeset in webkit [279633] by Alan Coon
  • 1 copy in tags/Safari-612.1.22.1.1

Tag Safari-612.1.22.1.1.

6:04 PM Changeset in webkit [279632] by Alan Coon
  • 1 copy in tags/Safari-612.1.22.2.1

Tag Safari-612.1.22.2.1.

6:01 PM Changeset in webkit [279631] by Alan Coon
  • 1 copy in tags/Safari-612.1.22.0.1

Tag Safari-612.1.22.0.1.

5:48 PM Changeset in webkit [279630] by commit-queue@webkit.org
  • 8 edits
    4 adds in trunk/Source/JavaScriptCore

[JSC] Implement Temporal
​https://bugs.webkit.org/show_bug.cgi?id=223166

Patch by Philip Chimento <​pchimento@igalia.com> on 2021-07-06
Reviewed by Yusuke Suzuki.

Intended to be the first patch in a stack. Adds boilerplate for
Temporal in order to unblock further parallelizable work on this bug.

This patch adds a feature flag for Temporal, and a toplevel Temporal
global containing only Temporal.now, which is itself an empty object.
These objects will be further populated in later patches.

  • CMakeLists.txt: Add TemporalObject and TemporalNow. Property lookup table in TemporalObject.
  • DerivedSources.make: Add TemporalObject property lookup table header.
  • JavaScriptCore.xcodeproj/project.pbxproj: Add new files.
  • Sources.txt: Add TemporalObject and TemporalNow.
  • runtime/CommonIdentifiers.h: Add 'Temporal' property key.
  • runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::init): Create the Temporal global if the feature

flag is enabled.

  • runtime/OptionsList.h: Add useTemporal feature flag.
  • runtime/TemporalNow.cpp: Added.

(JSC::TemporalNow::TemporalNow):
(JSC::TemporalNow::create):
(JSC::TemporalNow::createStructure):
(JSC::TemporalNow::finishCreation):

  • runtime/TemporalNow.h: Added.
  • runtime/TemporalObject.cpp: Added.

(JSC::createNowObject):
(JSC::TemporalObject::TemporalObject):
(JSC::TemporalObject::create):
(JSC::TemporalObject::createStructure):
(JSC::TemporalObject::finishCreation):

  • runtime/TemporalObject.h: Added.
5:27 PM Changeset in webkit [279629] by commit-queue@webkit.org
  • 4 edits in trunk

imported/w3c/web-platform-tests/fetch/api/credentials/authentication-basic.any*.html are crashing in debug
​https://bugs.webkit.org/show_bug.cgi?id=227310

Patch by Alex Christensen <​achristensen@webkit.org> on 2021-07-06
Reviewed by Chris Dumez.

Source/WebCore:

In r228486 we blocked cross-origin requests from asking for credentials, and we wanted to add a console log for web developers
to see why they could no longer ask for credentials. r228703 loosened that to allow main resources to request credentials,
and it added an incorrect assertion before logging. ResourceLoader::isAllowedToAskUserForCredentials has two other reasons
why credentials could be blocked, and there is no reason to log in those cases because that is standard web behavior, as seen by
running the tests in Chrome and Firefox and seeing no console log. This removes the logs in cases where other browsers also
have the same behavior and do not log, and removes the incorrect assertion.

  • loader/ResourceLoader.cpp:

(WebCore::ResourceLoader::didBlockAuthenticationChallenge):

LayoutTests:

4:54 PM Changeset in webkit [279628] by Chris Dumez
  • 5 edits
    2 adds in trunk

SubtleCrypto should only be exposed to secure contexts
​https://bugs.webkit.org/show_bug.cgi?id=227725

Reviewed by Darin Adler.

Source/WebCore:

SubtleCrypto should only be exposed to secure contexts:

Gecko and Blink match the specification.

This was causing WebKit to fail the WebCryptoAPI/historical.any.html WPT test.

Test: http/wpt/crypto/historical.html

  • crypto/CryptoKey.idl:
  • crypto/SubtleCrypto.idl:
  • page/Crypto.idl:

LayoutTests:

Add layout test coverage.

  • http/wpt/crypto/historical-expected.txt: Added.
  • http/wpt/crypto/historical.html: Added.
3:49 PM Changeset in webkit [279627] by commit-queue@webkit.org
  • 2 edits in trunk/Source/JavaScriptCore

Fix type error in testb3
​https://bugs.webkit.org/show_bug.cgi?id=227722

Patch by Yijia Huang <Yijia Huang> on 2021-07-06
Reviewed by Mark Lam.

Fix type error in testb3. Shift amount should be 32-bit constant.

  • b3/testb3_3.cpp:

(testInsertSignedBitfieldInZero64):
(testExtractSignedBitfield64):

3:37 PM Changeset in webkit [279626] by rniwa@webkit.org
  • 5 edits in trunk/Source

Deploy smart pointers in EventHandler and UserInputBridge
​https://bugs.webkit.org/show_bug.cgi?id=227481
<rdar://problem/79906757>

Reviewed by Wenson Hsieh and Chris Dumez.

Source/WebCore:

Deployed Ref/RefPtr in various places in EventHandler and UserInputBridge.

  • page/EventHandler.cpp:

(WebCore::EventHandler::selectClosestWordFromHitTestResult):
(WebCore::EventHandler::selectClosestContextualWordFromMouseEvent):
(WebCore::EventHandler::selectClosestContextualWordOrLinkFromMouseEvent):
(WebCore::EventHandler::handleMousePressEventTripleClick):
(WebCore::EventHandler::handleMousePressEventSingleClick):
(WebCore::EventHandler::selectionExtentRespectingEditingBoundary):
(WebCore::EventHandler::handleMouseDraggedEvent):
(WebCore::EventHandler::eventMayStartDrag const):
(WebCore::EventHandler::updateSelectionForMouseDrag):
(WebCore::EventHandler::handleMouseReleaseEvent):
(WebCore::EventHandler::hitTestResultAtPoint const):
(WebCore::EventHandler::scrollOverflow):
(WebCore::EventHandler::logicalScrollOverflow):
(WebCore::EventHandler::scrollRecursively):
(WebCore::EventHandler::logicalScrollRecursively):
(WebCore::EventHandler::updateCursor):
(WebCore::EventHandler::selectCursor):
(WebCore::EventHandler::handleMousePressEvent):
(WebCore::EventHandler::handleMouseMoveEvent):
(WebCore::contentFrameForNode): Renamed from targetIsFrame and made it return the node.
(WebCore::EventHandler::updateDragAndDrop):
(WebCore::EventHandler::cancelDragAndDrop):
(WebCore::EventHandler::performDragAndDrop):
(WebCore::hierarchyHasCapturingEventListeners):
(WebCore::EventHandler::updateMouseEventTargetNode):
(WebCore::EventHandler::notifyScrollableAreasOfMouseEvents):
(WebCore::EventHandler::dispatchMouseEvent):
(WebCore::EventHandler::isInsideScrollbar const):
(WebCore::EventHandler::handleWheelEvent):
(WebCore::EventHandler::handleWheelEventInternal):
(WebCore::EventHandler::sendContextMenuEvent):
(WebCore::EventHandler::sendContextMenuEventForKey):
(WebCore::EventHandler::fakeMouseMoveEventTimerFired):
(WebCore::EventHandler::hoverTimerFired):
(WebCore::EventHandler::handleAccessKey):
(WebCore::EventHandler::isKeyEventAllowedInFullScreen const):
(WebCore::EventHandler::keyEvent):
(WebCore::EventHandler::internalKeyEvent):
(WebCore::setInitialKeyboardSelection):
(WebCore::removeDraggedContentDocumentMarkersFromAllFramesInPage):
(WebCore::EventHandler::handleKeyboardScrolling):
(WebCore::EventHandler::handleTouchEvent):
(WebCore::EventHandler::passWheelEventToWidget):

  • replay/UserInputBridge.cpp:

(WebCore::UserInputBridge::handleMousePressEvent):
(WebCore::UserInputBridge::handleMouseReleaseEvent):
(WebCore::UserInputBridge::handleMouseMoveEvent):
(WebCore::UserInputBridge::handleMouseMoveOnScrollbarEvent):
(WebCore::UserInputBridge::handleMouseForceEvent):
(WebCore::UserInputBridge::handleKeyEvent):
(WebCore::UserInputBridge::handleAccessKeyEvent):
(WebCore::UserInputBridge::handleWheelEvent):
(WebCore::UserInputBridge::scrollRecursively):
(WebCore::UserInputBridge::logicalScrollRecursively):
(WebCore::UserInputBridge::loadRequest):
(WebCore::UserInputBridge::tryClosePage):

Source/WebKit:

  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::contextMenuAtPointInWindow):
(WebKit::handleContextMenuEvent):

3:34 PM Changeset in webkit [279625] by Devin Rousso
  • 3 edits in trunk/Source/WebKit

Provide SPI for clients to override just the contextmenu preview instead of the entire UIContextMenuConfiguration
​https://bugs.webkit.org/show_bug.cgi?id=227603
<rdar://problem/78832586>

Reviewed by Wenson Hsieh.

  • UIProcess/API/Cocoa/WKUIDelegatePrivate.h:
  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView continueContextMenuInteraction:]):
This allows Safari to remove some custom contextmenu code and use WebKit's default actions.

3:33 PM Changeset in webkit [279624] by dino@apple.com
  • 5 edits in trunk/Source/WebCore

WebGL video to texture upload spends time clearing the uploaded-to texture
​https://bugs.webkit.org/show_bug.cgi?id=227582
<rdar://problem/80020335>

Patch by Kimmo Kinnunen <​kkinnunen@apple.com> on 2021-07-06
Reviewed by Kenneth Russell.

Disable robust resource initiaization for the shared ANGLE context that is used
to copy video frames to WebGL textures. Otherwise ANGLE would spend time
initializing the texture in gl::DrawArrays.

No new tests, we currently do not have WebGL perf tests.

  • platform/graphics/angle/GraphicsContextGLANGLE.cpp:

(WebCore::GraphicsContextGLOpenGL::texImage2DDirect):
Add the direct texImage2D call so that the texture seed can be
somehow updated. This will be removed once the texture image version
management is fixed to be a bit more robust.

  • platform/graphics/cocoa/GraphicsContextGLOpenGLCocoa.mm:

(WebCore::GraphicsContextGLOpenGL::GraphicsContextGLOpenGL):

  • platform/graphics/cv/GraphicsContextGLCVANGLE.cpp:

(WebCore::GraphicsContextGLCVANGLE::copyPixelBufferToTexture):

  • platform/graphics/opengl/GraphicsContextGLOpenGL.h:
3:27 PM Changeset in webkit [279623] by Simon Fraser
  • 2 edits in trunk/Source/WebCore

RenderLayer does not need a virtual destructor
​https://bugs.webkit.org/show_bug.cgi?id=227706

Reviewed by Tim Horton.

The virtual destructor was a holdover from when RenderLayer inherited from
ScrollableArea.

  • rendering/RenderLayer.h:
2:35 PM Changeset in webkit [279622] by Truitt Savell
  • 16 edits
    6 deletes in trunk

Unreviewed, reverting r279542.

Casued 4 test crashes

Reverted changeset:

"SourceBuffer.abort() doesn't go back to state
WAITING_FOR_SEGMENT properly"
​https://bugs.webkit.org/show_bug.cgi?id=227559
​https://commits.webkit.org/r279542

2:20 PM Changeset in webkit [279621] by msaboff@apple.com
  • 14 edits in trunk/Source/bmalloc

[bmalloc] Make adaptive scavenging more precise
​https://bugs.webkit.org/show_bug.cgi?id=226237

Reviewed by Geoffrey Garen.

Reland the adaptive scavenger change for macOS with fix.

The bug happens when decommitting large ranges that don't have physical pages.
We'd call Heap::decommitLargeRange(), but would only add the range to the
decommitter list if there were physical pages associated with the range.
We would still perform all the other processing of a decommitted range,
including setting the range as not elgible for allocation or merging.
Had the range been added to the decommitter list, we would have set the
range as elgible after the physical pages were released to the OS.
The result is that the range could never be allocated, either by itself or as a
larger range merged with adjacent ranges.

The fix is to only perform decommit processing of large ranges if they have
physical pages. We now check for physical pages before calling Heap::decommitLargeRange().
For ranges that don't have physical pages, they can stay on the free list as
elgible without having to round trip through decommit processing.

Made a minor change to the calculation of the physical end of the LargeRange created
and added to the free list in Heap::deallocateSmallChunk. If the last page in the chunk
has a physical page, we set the physical end of the range to the end of the chunk.
This is for the case where there is an unusable partial small page at the end of the chunk.

  • bmalloc/BPlatform.h:
  • bmalloc/Heap.cpp:

(bmalloc::Heap::decommitLargeRange):
(bmalloc::Heap::scavenge):
(bmalloc::Heap::allocateSmallChunk):
(bmalloc::Heap::deallocateSmallChunk):
(bmalloc::Heap::allocateSmallPage):
(bmalloc::Heap::splitAndAllocate):
(bmalloc::Heap::allocateLarge):
(bmalloc::Heap::tryAllocateLargeChunk):
(bmalloc::Heap::shrinkLarge):
(bmalloc::Heap::deallocateLarge):
(bmalloc::Heap::scavengeToHighWatermark): Deleted.

  • bmalloc/Heap.h:
  • bmalloc/IsoDirectory.h:
  • bmalloc/IsoDirectoryInlines.h:

(bmalloc::passedNumPages>::takeFirstEligible):
(bmalloc::passedNumPages>::scavenge):
(bmalloc::passedNumPages>::scavengeToHighWatermark): Deleted.

  • bmalloc/IsoHeapImpl.h:
  • bmalloc/IsoHeapImplInlines.h:

(bmalloc::IsoHeapImpl<Config>::scavengeToHighWatermark): Deleted.

  • bmalloc/IsoSharedHeapInlines.h:

(bmalloc::IsoSharedHeap::allocateSlow):

  • bmalloc/LargeMap.cpp:

(bmalloc::LargeMap::add):

  • bmalloc/LargeRange.h:

(bmalloc::LargeRange::LargeRange):
(bmalloc::LargeRange::physicalEnd const):
(bmalloc::LargeRange::setPhysicalEnd):
(bmalloc::LargeRange::clearPhysicalEnd):
(bmalloc::LargeRange::setUsedSinceLastScavenge):
(bmalloc::merge):
(bmalloc::LargeRange::split const):
(): Deleted.

  • bmalloc/Scavenger.cpp:

(bmalloc::Scavenger::Scavenger):
(bmalloc::Scavenger::scheduleIfUnderMemoryPressure):
(bmalloc::Scavenger::schedule):
(bmalloc::Scavenger::scavenge):
(bmalloc::Scavenger::threadRunLoop):
(bmalloc::Scavenger::didStartGrowing): Deleted.
(bmalloc::Scavenger::timeSinceLastPartialScavenge): Deleted.
(bmalloc::Scavenger::partialScavenge): Deleted.

  • bmalloc/Scavenger.h:
  • bmalloc/SmallPage.h:

(bmalloc::SmallPage::setUsedSinceLastScavenge):

2:12 PM Changeset in webkit [279620] by sbarati@apple.com
  • 2 edits in trunk/JSTests

Run microbenchmarks/memcpy-typed-loop-small.js for fewer iterations to avoid timeouts
​https://bugs.webkit.org/show_bug.cgi?id=227717

Reviewed by Robin Morisset.

  • microbenchmarks/memcpy-typed-loop-small.js:
2:05 PM Changeset in webkit [279619] by sihui_liu@apple.com
  • 7 edits in trunk/Source/WebKit

WebIDBServer created after NetworkProcess::prepareToSuspend is not suspended correctly
​https://bugs.webkit.org/show_bug.cgi?id=227650

Reviewed by Chris Dumez.

We created WebIDBServer on receiving AddIDBConnection message from web process, to make sure WebIDBServer's
thread is launched only when it is needed. Now WebIDBServer uses WorkQueue, which uses thread from thread pool,
we can go back to ensure WebIDBServer at when connection to web process is needed. By doing this, it's less
likely WebIDBServer is created after NetworkProcess::prepareToSuspend. To make it more safe, this patch also
sets m_shouldSuspendIDBServer on NetworkProcess::prepareToSuspend. If the value is true, WebIDBServer is
suspended after creation.

  • NetworkProcess/NetworkConnectionToWebProcess.cpp:

(WebKit::NetworkConnectionToWebProcess::addIDBConnection): Deleted.

  • NetworkProcess/NetworkConnectionToWebProcess.h:
  • NetworkProcess/NetworkConnectionToWebProcess.messages.in:
  • NetworkProcess/NetworkProcess.cpp:

(WebKit::NetworkProcess::createNetworkConnectionToWebProcess):
(WebKit::NetworkProcess::prepareToSuspend):
(WebKit::NetworkProcess::resume):
(WebKit::NetworkProcess::createWebIDBServer):

  • NetworkProcess/NetworkProcess.h:
  • WebProcess/Databases/IndexedDB/WebIDBConnectionToServer.cpp:

(WebKit::WebIDBConnectionToServer::WebIDBConnectionToServer):

1:54 PM Changeset in webkit [279618] by Adrian Perez de Castro
  • 2 edits in releases/WebKitGTK/webkit-2.32/Source/WebCore

Merge r278892 - [GStreamer] Another crash under gst_element_add_pad
​https://bugs.webkit.org/show_bug.cgi?id=225765

Patch by Philippe Normand <​pnormand@igalia.com> on 2021-06-15
Reviewed by Adrian Perez de Castro.

Decodebin3 in GStreamer <= 1.16 does not respect user-supplied select-stream events. So we
need to relax the release assert for these versions. This bug was fixed in:
​https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/commit/b41b87522f59355bb21c001e9e2df96dc6956928

  • platform/graphics/gstreamer/ImageDecoderGStreamer.cpp:

(WebCore::ImageDecoderGStreamer::InnerDecoder::connectDecoderPad):

1:54 PM Changeset in webkit [279617] by Adrian Perez de Castro
  • 2 edits in releases/WebKitGTK/webkit-2.32/Source/WebKit

Merge r278761 - [GTK] Crash when dragging an account node above WebView
​https://bugs.webkit.org/show_bug.cgi?id=226811

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-06-11
Reviewed by Adrian Perez de Castro.

When we receive empty drag data, this is indicated by length -1, not by 0.

  • UIProcess/API/gtk/DropTargetGtk3.cpp:

(WebKit::DropTarget::dataReceived):

1:53 PM WebKitGTK/2.32.x edited by Adrian Perez de Castro
(diff)
1:51 PM Changeset in webkit [279616] by Adrian Perez de Castro
  • 4 edits in releases/WebKitGTK/webkit-2.32/Source

Merge r278302 - [WPE][GTK] Support building against uClibc
​https://bugs.webkit.org/show_bug.cgi?id=226244

Reviewed by Michael Catanzaro.

Source/JavaScriptCore:

  • assembler/MacroAssemblerARM64.cpp:

(getauxval): Provide a fallback implementation of getauxval() for
systems which do not provide <sys/auxv.h>, like those using uClibc
as their C library.

Source/WTF:

  • wtf/PlatformRegisters.h: Use the <sys/ucontext.h> header instead of

<ucontext.h>, which is enough to gain access to the type definitions
for CPU registers and is available on every libc. On the other hand,
uClibc does not have <ucontext.h>, so this fixes the build in that
case.

1:46 PM Changeset in webkit [279615] by Chris Dumez
  • 2 edits in trunk/Source/WebCore

Make sure PlatformCALayer gets destroyed on the main thread
​https://bugs.webkit.org/show_bug.cgi?id=227714

Reviewed by Geoffrey Garen.

Make sure PlatformCALayer gets destroyed on the main thread as we have evidence this is
not always the case and its destructor is definitely not safe to call on a non-main
thread.

  • platform/graphics/ca/PlatformCALayer.h:
1:31 PM Changeset in webkit [279614] by jer.noble@apple.com
  • 2 edits in trunk/Source/WebCore

MediaPlayer may be left in a non-visible state
​https://bugs.webkit.org/show_bug.cgi?id=227711

Reviewed by Eric Carlson.

Prospective fix for possible edge-case behavior. MediaPlayer defaults to non-visible state
at creation time, but that visibility state is set to true in two places:

  • When the Page's visibility state changes
  • During layout

If the MediaPlayer is created (or re-created) after the Page's visibility state, or (somehow)
layout does not occur, the MediaPlayer can be left thinking it is not visible, which could
cause downstream effects like a failure to render video content.

Rather than wait for layout to occur, or for the Page's visibility state to change, always
set the visibility state immediately after creating the MediaPlayer object.

No test, as it's unclear what edge case may cause this problem to occur; could be a result of
re-creating the remote MediaPlayer after a GPU process crash; could be a specific page behavior
when switching media sources; could only occur in fullscreen mode.

  • html/HTMLMediaElement.cpp:

(WebCore::HTMLMediaElement::createMediaPlayer:

1:25 PM Changeset in webkit [279613] by Patrick Angle
  • 3 edits in trunk/Source/WebInspectorUI

Web Inspector: Elements Tab Details Sidebar navigation items sometime wrap to a second line
​https://bugs.webkit.org/show_bug.cgi?id=227707

Reviewed by Devin Rousso.

When resizing a sidebar, it was possible that the cumulative widths of each navigation item could add up to just
less than the actual amount of space necessary to lay out each item in a single row, leading to wrapping items
to the next line. This resolves that issue by taking the ceiling of each item's width when calculating the
total amount of space needed to display all the items. Additionally, every time a panel is added or removed from
the sidebar, we need to recalculate the width of the sidebar to make sure the new navigation item, or the
removal thereof, is accommodated.

  • UserInterface/Views/NavigationBar.js:

(WI.NavigationBar.prototype.layout.calculateVisibleItemWidth):
(WI.NavigationBar.prototype._calculateMinimumWidth):

  • UserInterface/Views/SingleSidebar.js:

(WI.SingleSidebar.prototype.didInsertSidebarPanel):
(WI.SingleSidebar.prototype.didRemoveSidebarPanel):

1:19 PM Changeset in webkit [279612] by Ruben Turcios
  • 8 edits in trunk/Source

Versioning.

WebKit-7612.1.24

1:01 PM Changeset in webkit [279611] by Chris Dumez
  • 2 edits in trunk/LayoutTests

Unreviewed, address flakiness of imported/w3c/web-platform-tests/html/webappapis/timers/negative-settimeout.any.worker.html

This test has been flaky since its import. Silence its console logging to address the flakiness.

12:43 PM Changeset in webkit [279610] by Ruben Turcios
  • 8 edits in branches/safari-612.1.22.3-branch

Cherry-pick r279449. rdar://problem/80212082

Turn off data ICs by default
​https://bugs.webkit.org/show_bug.cgi?id=227334
<rdar://problem/79802812>

Reviewed by Yusuke Suzuki.

JSTests:

  • microbenchmarks/deltablue-varargs.js:
  • microbenchmarks/richards-try-catch.js:

Source/JavaScriptCore:

There are GC crashes that are caused by access data IC sharing. This
patch is both turning off data IC sharing by default, and turning off data
ICs by default.

We should re-enable this once we figure out the issue:
​https://bugs.webkit.org/show_bug.cgi?id=227551

Some of our testing modes are still running with data ICs on, so the code doesn't
bit rot. And a select few tests are running with data IC sharing on, for
similar reasons, even though we know it has issues. If those tests start
crashing, we'll just disable sharing completely until the issue is resolved.

  • bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate):
  • runtime/OptionsList.h:

Tools:

  • Scripts/run-jsc-stress-tests:

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@279449 268f45cc-cd09-0410-ab3c-d52691b4dbfc

12:37 PM Changeset in webkit [279609] by Wenson Hsieh
  • 9 edits
    2 adds in trunk

[Live Text] Extraneous spaces when copying or translating Chinese and Japanese text in WebKit
​https://bugs.webkit.org/show_bug.cgi?id=227674
rdar://79669807

Reviewed by Tim Horton.

Source/WebCore:

See WebKit/ChangeLog for more details.

Test: fast/images/text-recognition/image-overlay-text-without-leading-whitespace.html

  • html/HTMLElement.cpp:

(WebCore::HTMLElement::updateWithTextRecognitionResult):

For each recognized word in text, only append a trailing newline in the text content of the text container
element if hasLeadingWhitespace is set. Drive-by fix: additionally remove logic to append a line break when
computing and applying CSS transforms to text container elements.

  • platform/TextRecognitionResult.h:

(WebCore::TextRecognitionWordData::TextRecognitionWordData):
(WebCore::TextRecognitionWordData::encode const):
(WebCore::TextRecognitionWordData::decode):

Add a per-word hasLeadingWhitespace flag.

  • testing/Internals.cpp:

(WebCore::makeDataForLine):

  • testing/Internals.h:
  • testing/Internals.idl:

Source/WebKit:

When injecting Live Text into images, we currently assume that all pieces of recognized text from VisionKit are
separated by spaces. Upon selecting Japanese or Chinese text, this causes text selections to include extraneous
spaces between words.

To fix this, we add a bit for each TextRecognitionWordData, to indicate whether that word should be followed by
whitespace in the image overlay. When converting VKWKTextInfo into TextRecognitionWordData, we then set this bit
to true only if the word is the first on a line of text that is preceded by another line, or there exists
whitespace between the word and the previous word on the same line.

  • Platform/cocoa/TextRecognitionUtilities.mm:

(WebKit::makeTextRecognitionResult):

LayoutTests:

Add a layout test to verify that no extraneous spaces are inserted when injecting recognized text into images
without leading whitespace.

  • fast/images/text-recognition/image-overlay-text-without-leading-whitespace-expected.txt: Added.
  • fast/images/text-recognition/image-overlay-text-without-leading-whitespace.html: Added.
12:34 PM Changeset in webkit [279608] by Ruben Turcios
  • 8 edits in branches/safari-612.1.22.1-branch

Cherry-pick r279449. rdar://problem/80212104

Turn off data ICs by default
​https://bugs.webkit.org/show_bug.cgi?id=227334
<rdar://problem/79802812>

Reviewed by Yusuke Suzuki.

JSTests:

  • microbenchmarks/deltablue-varargs.js:
  • microbenchmarks/richards-try-catch.js:

Source/JavaScriptCore:

There are GC crashes that are caused by access data IC sharing. This
patch is both turning off data IC sharing by default, and turning off data
ICs by default.

We should re-enable this once we figure out the issue:
​https://bugs.webkit.org/show_bug.cgi?id=227551

Some of our testing modes are still running with data ICs on, so the code doesn't
bit rot. And a select few tests are running with data IC sharing on, for
similar reasons, even though we know it has issues. If those tests start
crashing, we'll just disable sharing completely until the issue is resolved.

  • bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate):
  • runtime/OptionsList.h:

Tools:

  • Scripts/run-jsc-stress-tests:

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@279449 268f45cc-cd09-0410-ab3c-d52691b4dbfc

12:34 PM Changeset in webkit [279607] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebKit

Make Caches::writeRecord and Caches::readRecord more robust
​https://bugs.webkit.org/show_bug.cgi?id=221620

Patch by Alex Christensen <​achristensen@webkit.org> on 2021-07-06
Reviewed by Youenn Fablet.

I saw null dereferenced in EWS, and everywhere else we check m_storage for null.
Some events happen during teardown. No reason to crash.

  • NetworkProcess/cache/CacheStorageEngineCaches.cpp:

(WebKit::CacheStorage::Caches::writeRecord):
(WebKit::CacheStorage::Caches::readRecord):

12:33 PM Changeset in webkit [279606] by Kyle Piddington
  • 13 edits in trunk/Source/ThirdParty/ANGLE

REGRESSION (r279466): [Big Sur] webgl/1.0.3/conformance & webgl/2.0.0/conformance are failing
​https://bugs.webkit.org/show_bug.cgi?id=227596
Provide Intel workaround for Big Sur systems. Atan and invariant have
issues on older systems, and require us to disable fastmath to produce correct results.

Reviewed by Kenneth Russell.

  • include/platform/FeaturesMtl.h:
  • src/compiler/translator/TranslatorMetalDirect.h:

(sh::TranslatorMetalReflection::reset):

  • src/compiler/translator/TranslatorMetalDirect/EmitMetal.cpp:

(GenMetalTraverser::emitPostQualifier):
(GenMetalTraverser::visitUnary):
(GenMetalTraverser::visitAggregate):

  • src/libANGLE/renderer/metal/DisplayMtl.mm:

(rx::DisplayMtl::initializeFeatures):

  • src/libANGLE/renderer/metal/ProgramMtl.h:

(rx::ProgramMtl::getTranslatedShaderInfo const):

  • src/libANGLE/renderer/metal/ProgramMtl.mm:
  • src/libANGLE/renderer/metal/mtl_glslang_mtl_utils.h:
  • src/libANGLE/renderer/metal/mtl_glslang_mtl_utils.mm:

(rx::mtl::GlslangGetMSL):

  • src/libANGLE/renderer/metal/mtl_render_utils.h:
  • src/libANGLE/renderer/metal/mtl_render_utils.mm:

(rx::mtl::TransformFeedbackUtils::createMslXfbLibrary):
(rx::mtl::TransformFeedbackUtils::getTransformFeedbackRenderPipeline):

  • src/libANGLE/renderer/metal/mtl_utils.h:
  • src/libANGLE/renderer/metal/mtl_utils.mm:

(rx::mtl::CreateShaderLibrary):

12:30 PM Changeset in webkit [279605] by Ruben Turcios
  • 8 edits in branches/safari-612.1.22.0-branch

Cherry-pick r279449. rdar://problem/80212096

Turn off data ICs by default
​https://bugs.webkit.org/show_bug.cgi?id=227334
<rdar://problem/79802812>

Reviewed by Yusuke Suzuki.

JSTests:

  • microbenchmarks/deltablue-varargs.js:
  • microbenchmarks/richards-try-catch.js:

Source/JavaScriptCore:

There are GC crashes that are caused by access data IC sharing. This
patch is both turning off data IC sharing by default, and turning off data
ICs by default.

We should re-enable this once we figure out the issue:
​https://bugs.webkit.org/show_bug.cgi?id=227551

Some of our testing modes are still running with data ICs on, so the code doesn't
bit rot. And a select few tests are running with data IC sharing on, for
similar reasons, even though we know it has issues. If those tests start
crashing, we'll just disable sharing completely until the issue is resolved.

  • bytecode/PolymorphicAccess.cpp: (JSC::PolymorphicAccess::regenerate):
  • runtime/OptionsList.h:

Tools:

  • Scripts/run-jsc-stress-tests:

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@279449 268f45cc-cd09-0410-ab3c-d52691b4dbfc

12:25 PM Changeset in webkit [279604] by ysuzuki@apple.com
  • 35 edits
    3 adds in trunk

[JSC] Optimize Object.assign and putDirectInternal
​https://bugs.webkit.org/show_bug.cgi?id=227677

Reviewed by Filip Pizlo.

JSTests:

  • microbenchmarks/object-assign-replace.js: Added.

(test):

  • microbenchmarks/object-assign-transition.js: Added.

(test):

Source/JavaScriptCore:

This patch improves Object.assign performance (and this requires putDirectInternal improvement).

  1. Object.assign is handled by DFG / FTL as ObjectAssign node
  2. We found that putDirectInternal is suboptimal. This patch removes several bottlenecks. They are super critical from the measurement of microbenchmarks.

2.1. Creating and destroying DeferredStructureTransitionWatchpointFire is not free. We should do that only when we need it.
2.2. Before r277620, we are checking m_replacementWatchpointSets's nullptr and that was fast. But after that, we are always

calling HashMap::get, and it is not inlined. This means that if we have StructureRareData, we are always calling HashMap::get
even though there is no m_replacementWatchpointSets set. This patch adds HashMap::isNullStorage to avoid this call by inlinely
check this via LIKELY(m_replacementWatchpointSets.isNullStorage()).

2.3. Structure::addPropertyTransitionToExistingStructure has very cheap fast path and we must inline them to get performance benefit

for major single-transition case.

Added microbenchmarks show significant performance improvements. And Speedometer2 shows 0.6 - 1.0% improvement.

ToT Patched

object-assign-transition 105.2539+-0.2970 88.8046+-0.2029 definitely 1.1852x faster
object-assign-replace 116.1568+-0.0905 75.0673+-0.0658 definitely 1.5474x faster

(JSC::DeferredWatchpointFire::fireAllSlow):
(JSC::DeferredWatchpointFire::DeferredWatchpointFire): Deleted.
(JSC::DeferredWatchpointFire::~DeferredWatchpointFire): Deleted.
(JSC::DeferredWatchpointFire::fireAll): Deleted.

  • bytecode/Watchpoint.h:

(JSC::DeferredWatchpointFire::DeferredWatchpointFire):
(JSC::DeferredWatchpointFire::fireAll):
(JSC::FireDetail::FireDetail): Deleted.
(JSC::FireDetail::~FireDetail): Deleted.

  • dfg/DFGAbstractInterpreterInlines.h:

(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):

  • dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::handleIntrinsicCall):

  • dfg/DFGClobberize.h:

(JSC::DFG::clobberize):

  • dfg/DFGDoesGC.cpp:

(JSC::DFG::doesGC):

  • dfg/DFGFixupPhase.cpp:

(JSC::DFG::FixupPhase::fixupNode):

  • dfg/DFGMayExit.cpp:
  • dfg/DFGNodeType.h:
  • dfg/DFGOperations.cpp:

(JSC::DFG::JSC_DEFINE_JIT_OPERATION):

  • dfg/DFGOperations.h:
  • dfg/DFGPredictionPropagationPhase.cpp:
  • dfg/DFGSafeToExecute.h:

(JSC::DFG::safeToExecute):

  • dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::compileObjectAssign):

  • dfg/DFGSpeculativeJIT.h:
  • dfg/DFGSpeculativeJIT32_64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

  • dfg/DFGSpeculativeJIT64.cpp:

(JSC::DFG::SpeculativeJIT::compile):

  • ftl/FTLCapabilities.cpp:

(JSC::FTL::canCompile):

  • ftl/FTLLowerDFGToB3.cpp:

(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectAssign):

  • runtime/Intrinsic.cpp:

(JSC::intrinsicName):

  • runtime/Intrinsic.h:
  • runtime/JSObject.cpp:

(JSC::JSObject::deleteProperty):

  • runtime/JSObjectInlines.h:

(JSC::JSObject::putDirectInternal):

  • runtime/ObjectConstructor.cpp:

(JSC::objectAssignGeneric):
(JSC::JSC_DEFINE_HOST_FUNCTION):

  • runtime/ObjectConstructor.h:
  • runtime/ObjectConstructorInlines.h: Added.

(JSC::canPerformFastPropertyEnumerationForObjectAssign):

  • runtime/Structure.cpp:

(JSC::StructureTransitionTable::singleTransition const): Deleted.
(JSC::StructureTransitionTable::get const): Deleted.
(JSC::Structure::addPropertyTransitionToExistingStructureImpl): Deleted.
(JSC::Structure::addPropertyTransitionToExistingStructure): Deleted.
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently): Deleted.

  • runtime/Structure.h:
  • runtime/StructureInlines.h:

(JSC::Structure::didReplaceProperty):
(JSC::Structure::propertyReplacementWatchpointSet):
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransitionToExistingStructure):
(JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
(JSC::StructureTransitionTable::singleTransition const):
(JSC::StructureTransitionTable::get const):

Source/WTF:

  • wtf/HashMap.h:
  • wtf/HashSet.h:
  • wtf/HashTable.h:

(WTF::HashTable::isNullStorage const):

12:10 PM Changeset in webkit [279603] by commit-queue@webkit.org
  • 2 edits in trunk/Tools

Add myself (Harshil Ratnu) to contributors.json
​https://bugs.webkit.org/show_bug.cgi?id=227653

Patch by Harshil Ratnu <​hratnu@apple.com> on 2021-07-06
Reviewed by Devin Rousso.

  • Scripts/webkitpy/common/config/contributors.json: Added myself.
12:02 PM Changeset in webkit [279602] by youenn@apple.com
  • 16 edits in trunk

Unable to use 'data:application/javascript' url for Worker
​https://bugs.webkit.org/show_bug.cgi?id=225716
<rdar://problem/78222538>

Reviewed by Alex Christensen.

LayoutTests/imported/w3c:

  • web-platform-tests/fetch/api/cors/data-url-worker-expected.txt:
  • web-platform-tests/html/cross-origin-embedder-policy/cross-origin-isolated-permission.https-expected.txt:
  • web-platform-tests/html/webappapis/the-windoworworkerglobalscope-mixin/Worker_Self_Origin-expected.txt:
  • web-platform-tests/service-workers/service-worker/local-url-inherit-controller.https-expected.txt:
  • web-platform-tests/workers/Worker_script_mimetype-expected.txt:
  • web-platform-tests/workers/constructors/Worker/same-origin-expected.txt:
  • web-platform-tests/workers/data-url-expected.txt:
  • web-platform-tests/workers/dedicated-worker-in-data-url-context.window-expected.txt:
  • web-platform-tests/workers/modules/dedicated-worker-import-data-url-cross-origin-expected.txt:
  • web-platform-tests/workers/modules/dedicated-worker-import-data-url.any-expected.txt:

Source/WebCore:

As per ​https://fetch.spec.whatwg.org/#main-fetch step 11, same origin fetch for data URL should succeed.
Update AbstractWorker to let such URLs trigger loads and update WorkerScriptLoader to enable those loads.

Covered by rebased tests.

  • workers/AbstractWorker.cpp:

(WebCore::AbstractWorker::resolveURL):

  • workers/WorkerScriptLoader.cpp:

(WebCore::WorkerScriptLoader::loadAsynchronously):

LayoutTests:

Some tests are showing progress but are timing out. Skipping them for now.

12:01 PM Changeset in webkit [279601] by Chris Dumez
  • 20 edits in trunk/Source/WebKit

[iOS] Have ProcessAssertion take the RunningBoard assertion asynchronously by default
​https://bugs.webkit.org/show_bug.cgi?id=225324
<rdar://76972252>

Reviewed by Geoffrey Garen.

Have ProcessAssertion take the RunningBoard assertion asynchronously (on a background thread) by
default as we have evidence that doing so on the main thread is bad for performance and may
negatively impact launch time.

When constructing a ProcessAssertion, the caller can now indicate if it wants the assertion to be
taken asynchronously (default) or not. Bug 227552 is an example of a case where we still want to
take the assertion synchronously (because we're not on the main thread and we need to make sure
we have the assertion before proceeding).

The caller can also provide a completion handler that will get called once the RunningBoard is
taken. Note that the RunningBoard async API ([RBSAssertion acquireWithInvalidationHandler]) does
not provide a way for us to know when the assertion is taken. For this reason, ProcessAssertion
keeps using the RunningBoard sync API ([RBSAssertion acquireWithError:]) but calls in on a
background queue.

For the UIProcess's background task though, we don't need to know when the assertion is taken
so we can use the RunningBoard async API.

Note that the previous iteration of this patch had a bug where the ProcessThrottler would release
its previous assertion before the new one is taken (asynchronously) when changing the assertion
type (e.g. foreground to background). This is addressed in this patch. ProcessThrottler now passes
an acquisition handler when constructing the ProcessAssertion and only releases its previous
assertion once the acquisition handler for the new one is taken.

  • NetworkProcess/Downloads/DownloadMap.cpp:

(WebKit::DownloadMap::add):

  • NetworkProcess/Downloads/DownloadMap.h:
  • Platform/IPC/cocoa/ConnectionCocoa.mm:

(IPC::ConnectionTerminationWatchdog::ConnectionTerminationWatchdog):

  • UIProcess/Downloads/DownloadProxyMap.cpp:

(WebKit::DownloadProxyMap::createDownloadProxy):

  • UIProcess/Downloads/DownloadProxyMap.h:
  • UIProcess/Network/NetworkProcessProxy.cpp:

(WebKit::NetworkProcessProxy::setWebProcessHasUploads):

  • UIProcess/Network/NetworkProcessProxy.h:
  • UIProcess/ProcessAssertion.cpp:

(WebKit::ProcessAssertion::ProcessAssertion):

  • UIProcess/ProcessAssertion.h:

(WebKit::ProcessAssertion::create):

  • UIProcess/ProcessThrottler.cpp:

(WebKit::ProcessThrottler::setAssertionType):

  • UIProcess/ProcessThrottler.h:
  • UIProcess/WebProcessPool.cpp:

(WebKit::WebProcessPool::updateAudibleMediaAssertions):

  • UIProcess/WebProcessPool.h:
  • UIProcess/WebProcessProxy.cpp:

(WebKit::WebProcessProxy::updateAudibleMediaAssertions):

  • UIProcess/WebProcessProxy.h:
  • UIProcess/ios/ProcessAssertionIOS.mm:

(assertionsWorkQueue):
(-[WKProcessAssertionBackgroundTaskManager _updateBackgroundTask]):
(-[WKProcessAssertionBackgroundTaskManager assertion:didInvalidateWithError:]):
(WebKit::ProcessAssertion::ProcessAssertion):
(WebKit::ProcessAssertion::acquireAsync):
(WebKit::ProcessAssertion::acquireSync):
(WebKit::ProcessAssertion::~ProcessAssertion):
(WebKit::ProcessAssertion::processAssertionWasInvalidated):
(WebKit::ProcessAssertion::isValid const):

12:00 PM Changeset in webkit [279600] by sihui_liu@apple.com
  • 2 edits in trunk/Source/WebKit

Don't interrupt database for WebResourceLoadStatisticsStore if it will not be suspended
​https://bugs.webkit.org/show_bug.cgi?id=227708

Reviewed by Geoffrey Garen.

  • NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:

(WebKit::WebResourceLoadStatisticsStore::suspend):

11:29 AM Changeset in webkit [279599] by achristensen@apple.com
  • 2 edits in trunk/Source/WebKit

Unreviewed, reverting r279597.

Broke build

Reverted changeset:

"Make Caches::writeRecord and Caches::readRecord more robust"
​https://bugs.webkit.org/show_bug.cgi?id=221620
​https://commits.webkit.org/r279597

10:59 AM Changeset in webkit [279598] by Ruben Turcios
  • 8 edits in branches/safari-612.1.22.3-branch/Source/JavaScriptCore

Cherry-pick r279560. rdar://problem/80212160

ActiveScratchBufferScope should take the buffer as argument
​https://bugs.webkit.org/show_bug.cgi?id=227670
rdar://80011612

Reviewed by Mark Lam.

​https://bugs.webkit.org/show_bug.cgi?id=227013 created ActiveScratchBufferScope.
It is used by operations that can cause the GC to run, to mark as roots the contents of the scratch buffer that is live during that time (if any).
The bug is that it simply asks the VM for a scratch buffer of the right size, but this will always return the last scratch buffer, and not necessarily the one that the operation is actually using.

A fairly simple fix is to pass it directly the scratch buffer, since the operation normally can get it easily enough.
In most cases the operation has access to the m_buffer field of the ScratchBuffer, but getting a pointer to the entire structure from that is fairly simple (I added ScratchBuffer::fromData() to do so).

  • dfg/DFGOSRExit.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION):
  • dfg/DFGOSRExit.h:
  • dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION):
  • dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewArray):
  • dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator):
  • runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime):
  • runtime/VM.h: (JSC::ScratchBuffer::fromData):
  • runtime/VMInlines.h: (JSC::ActiveScratchBufferScope::ActiveScratchBufferScope): (JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope):

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@279560 268f45cc-cd09-0410-ab3c-d52691b4dbfc

10:40 AM Changeset in webkit [279597] by achristensen@apple.com
  • 2 edits in trunk/Source/WebKit

Make Caches::writeRecord and Caches::readRecord more robust
​https://bugs.webkit.org/show_bug.cgi?id=221620

Reviewed by Youenn Fablet.

I saw null dereferenced in EWS, and everywhere else we check m_storage for null.
Some events happen during teardown. No reason to crash.

  • NetworkProcess/cache/CacheStorageEngineCaches.cpp:

(WebKit::CacheStorage::Caches::writeRecord):
(WebKit::CacheStorage::Caches::readRecord):

10:38 AM Changeset in webkit [279596] by Ruben Turcios
  • 8 edits in branches/safari-612.1.22.1-branch/Source/JavaScriptCore

Cherry-pick r279560. rdar://problem/80212179

ActiveScratchBufferScope should take the buffer as argument
​https://bugs.webkit.org/show_bug.cgi?id=227670
rdar://80011612

Reviewed by Mark Lam.

​https://bugs.webkit.org/show_bug.cgi?id=227013 created ActiveScratchBufferScope.
It is used by operations that can cause the GC to run, to mark as roots the contents of the scratch buffer that is live during that time (if any).
The bug is that it simply asks the VM for a scratch buffer of the right size, but this will always return the last scratch buffer, and not necessarily the one that the operation is actually using.

A fairly simple fix is to pass it directly the scratch buffer, since the operation normally can get it easily enough.
In most cases the operation has access to the m_buffer field of the ScratchBuffer, but getting a pointer to the entire structure from that is fairly simple (I added ScratchBuffer::fromData() to do so).

  • dfg/DFGOSRExit.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION):
  • dfg/DFGOSRExit.h:
  • dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION):
  • dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewArray):
  • dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator):
  • runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime):
  • runtime/VM.h: (JSC::ScratchBuffer::fromData):
  • runtime/VMInlines.h: (JSC::ActiveScratchBufferScope::ActiveScratchBufferScope): (JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope):

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@279560 268f45cc-cd09-0410-ab3c-d52691b4dbfc

10:34 AM Changeset in webkit [279595] by achristensen@apple.com
  • 15 edits in trunk

loadSimulatedRequest: should do same delegate callbacks as loadHTMLString and loadData
​https://bugs.webkit.org/show_bug.cgi?id=227599

Reviewed by Chris Dumez.

Source/WebCore:

  • loader/SubstituteData.h:

Source/WebKit:

Share more code with loadData and loadHTMLString to prevent such errors.

Before this change we set SubstituteData.failingURL, which in FrameLoader::PolicyChecker::checkNavigationPolicy
makes it behave more like _loadAlternateHTMLString which doesn't call decidePolicyForNavigationAction and does
add a back/forward entry. We want it to behave more like loadHTMLString, which does call decidePolicyForNavigationAction
and doesn't add a back/forward entry. Except we do want it to add a back/forward entry. This patch is to accomplish that.

In order to continue making a back/forward list item with loadSimulatedRequest, we need to use
WebCore::SubstituteData::SessionHistoryVisibility::Visible for its calls and also API::SubstituteData
needs to remember that we initially used that for when we go back to a back/forward list item from
that data. In order to keep binary compatibility with existing apps, loadData and loadHTMLString
need to continue using WebCore::SubstituteData::SessionHistoryVisibility::Hidden.

Covered by existing and new API tests.

  • Shared/LoadParameters.cpp:

(WebKit::LoadParameters::encode const):
(WebKit::LoadParameters::decode):

  • Shared/LoadParameters.h:
  • UIProcess/API/APINavigation.cpp:

(API::SubstituteData::SubstituteData):

  • UIProcess/API/APINavigation.h:

(API::SubstituteData::SubstituteData):

  • UIProcess/ProvisionalPageProxy.cpp:

(WebKit::ProvisionalPageProxy::loadData):

  • UIProcess/ProvisionalPageProxy.h:
  • UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::loadData):
(WebKit::WebPageProxy::loadDataWithNavigationShared):
(WebKit::WebPageProxy::loadSimulatedRequest):
(WebKit::WebPageProxy::continueNavigationInNewProcess):

  • UIProcess/WebPageProxy.h:
  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::loadDataImpl):
(WebKit::WebPage::loadData):
(WebKit::WebPage::loadAlternateHTML):
(WebKit::WebPage::loadSimulatedRequestAndResponse):

  • WebProcess/WebPage/WebPage.h:

Tools:

  • TestWebKitAPI/Tests/WebKitCocoa/WKWebViewLoadAPIs.mm:

(TEST):

10:32 AM Changeset in webkit [279594] by Chris Dumez
  • 3 edits in trunk/Source/WebCore

Add assertions in LayerPool to help debug <rdar://80184576>
​https://bugs.webkit.org/show_bug.cgi?id=227710

Reviewed by Simon Fraser.

  • platform/graphics/ca/LayerPool.cpp:

(WebCore::LayerPool::LayerPool):
(WebCore::LayerPool::~LayerPool):
(WebCore::LayerPool::addLayer):
(WebCore::LayerPool::takeLayerWithSize):
(WebCore::LayerPool::pruneTimerFired):
(WebCore::LayerPool::drain):

  • platform/graphics/ca/LayerPool.h:
10:29 AM Changeset in webkit [279593] by commit-queue@webkit.org
  • 5 edits in trunk/Source/JavaScriptCore

Fix instruction check failure of UBFX and SBFIZ in testb3 due to the speculative fix in bug 227554
​https://bugs.webkit.org/show_bug.cgi?id=227563

Patch by Yijia Huang <Yijia Huang> on 2021-07-06
Reviewed by Filip Pizlo.

This patch includes two modifications to resolve rdar://79978150:

  1. Fix the bug caused by the patch introducing BFI.
  2. Discard the corresponding speculative fix in ​https://bugs.webkit.org/show_bug.cgi?id=227554.

The previous patch, added bit field insert (BFI) to AIR opcode, causes the Gmail page
hanging issue on Safari. The root cause is the incorrect definition of register role in
BFI's AIR opcode. Since BFI inserts a bit field at the low end of the destination register
while keeping the high bit unchanged, the destination register should have both roles of
use and define simultaneously, which is not (missing use) in the previous patch.

This will result in the loss of preserving the value of the destination register,
which does happen when browsing the Gmail page on Safari.

B3 IR snippets from Gmail
Int32 b@23 = Add(b@104, b@111, D@100)
...
Int32 b@55 = Const32(65535, D@50)
Int32 b@137 = BitAnd(b@118, $65535(b@55), D@160)
Int32 b@168 = Const32(16, D@40)
Int32 b@141 = Shl(b@137, $16(b@168), D@163)
Int32 b@143 = BitAnd(b@23, $65535(b@55), D@166)
Int32 b@144 = BitOr(b@141, b@143, D@169)

The pattern of BFI is d = ((n & mask1) << lsb) | (d & mask2). So, it is obvious that
BFI can be utilized in b@144 where the d is b@23.

Incorrect AIR opcode of BFI
arm64: InsertBitField32 U:G:32, U:G:32, U:G:32, ZD:G:32

Tmp, Imm, Imm, Tmp

Air w/o use role
Add32 %x3, %x7, %x7, b@23
...
InsertBitField32 %x3, $16, $16, %x4, b@144

Generated code w/o use role
add w7, w3, w7
...
bfi w4, w3, #16, #16

In Air, the added value is stored in the w7. But the value is not preserved after
lowering with BFI. To fix this, the use role should be enabled for the destination
register.

Correnct AIR opcode of BFI
arm64: InsertBitField32 U:G:32, U:G:32, U:G:32, UZD:G:32

Tmp, Imm, Imm, Tmp

Air w/ use role
Add32 %x3, %x7, %x7, b@23
...
Move32 %x7, %x4, b@144
InsertBitField32 %x3, $16, $16, %x4, b@144

Generated code w/ use role
add w7, w3, w7
...
ubfx x4, x7, #0, #32
bfi w4, w3, #16, #16

In addition, BFXIL, which has pattern d = ((n >> lsb) & mask1) | (d & mask2), also needs
the similar update.

  • b3/B3LowerToAir.cpp:
  • b3/air/AirOpcode.opcodes:
  • b3/testb3_2.cpp:

(testInsertBitField32):
(testInsertBitField64):
(testExtractInsertBitfieldAtLowEnd32):
(testExtractInsertBitfieldAtLowEnd64):

  • runtime/OptionsList.h:
10:26 AM Changeset in webkit [279592] by Russell Epstein
  • 1 copy in tags/Safari-611.3.10.1.4

Tag Safari-611.3.10.1.4.

10:25 AM Changeset in webkit [279591] by pvollan@apple.com
  • 9 edits in trunk/Source/WebKit

Collect Accessibility preferences on a background queue
​https://bugs.webkit.org/show_bug.cgi?id=227617
<rdar://80055168>

Reviewed by Brent Fulgham.

To avoid blocking the main thread of the UI process, collect Media Accessibility preferences on a background thread,
and send them to the WebContent process(es).

  • Shared/AccessibilityPreferences.cpp:

(IPC::ArgumentCoder<WebKit::AccessibilityPreferences>::encode):
(IPC::ArgumentCoder<WebKit::AccessibilityPreferences>::decode):

  • Shared/AccessibilityPreferences.h:
  • UIProcess/Cocoa/WebProcessPoolCocoa.mm:

(WebKit::accessibilityPreferences):
(WebKit::WebProcessPool::setMediaAccessibilityPreferences):
(WebKit::WebProcessPool::mediaAccessibilityPreferencesChangedCallback):
(WebKit::WebProcessPool::registerNotificationObservers):

  • UIProcess/WebProcessPool.cpp:

(WebKit::WebProcessPool::initializeNewWebProcess):

  • UIProcess/WebProcessPool.h:
  • WebProcess/WebProcess.h:
  • WebProcess/WebProcess.messages.in:
  • WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::accessibilityPreferencesDidChange):
(WebKit::WebProcess::setMediaAccessibilityPreferences):

10:24 AM Changeset in webkit [279590] by Russell Epstein
  • 8 edits in branches/safari-611.3.10.1-branch/Source

Versioning.

WebKit-7611.3.10.1.4

10:20 AM Changeset in webkit [279589] by Russell Epstein
  • 8 edits in branches/safari-611.3.10.0-branch/Source

Revert "Versioning."

This reverts commit r279588.

10:15 AM Changeset in webkit [279588] by Russell Epstein
  • 8 edits in branches/safari-611.3.10.0-branch/Source

Versioning.

WebKit-7611.3.10.1.4

10:05 AM Changeset in webkit [279587] by Ruben Turcios
  • 8 edits in branches/safari-612.1.22.0-branch/Source/JavaScriptCore

Cherry-pick r279560. rdar://problem/80212171

ActiveScratchBufferScope should take the buffer as argument
​https://bugs.webkit.org/show_bug.cgi?id=227670
rdar://80011612

Reviewed by Mark Lam.

​https://bugs.webkit.org/show_bug.cgi?id=227013 created ActiveScratchBufferScope.
It is used by operations that can cause the GC to run, to mark as roots the contents of the scratch buffer that is live during that time (if any).
The bug is that it simply asks the VM for a scratch buffer of the right size, but this will always return the last scratch buffer, and not necessarily the one that the operation is actually using.

A fairly simple fix is to pass it directly the scratch buffer, since the operation normally can get it easily enough.
In most cases the operation has access to the m_buffer field of the ScratchBuffer, but getting a pointer to the entire structure from that is fairly simple (I added ScratchBuffer::fromData() to do so).

  • dfg/DFGOSRExit.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION):
  • dfg/DFGOSRExit.h:
  • dfg/DFGOperations.cpp: (JSC::DFG::JSC_DEFINE_JIT_OPERATION):
  • dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileNewArray):
  • dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator):
  • runtime/JSGlobalObject.cpp: (JSC::JSGlobalObject::haveABadTime):
  • runtime/VM.h: (JSC::ScratchBuffer::fromData):
  • runtime/VMInlines.h: (JSC::ActiveScratchBufferScope::ActiveScratchBufferScope): (JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope):

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@279560 268f45cc-cd09-0410-ab3c-d52691b4dbfc

10:04 AM Changeset in webkit [279586] by Truitt Savell
  • 2 edits in trunk/LayoutTests

[BigSur E Wk2 Release] imported/w3c/web-platform-tests/webrtc/RTCRtpSender-encode-same-track-twice.https.html in flaky failure
​https://bugs.webkit.org/show_bug.cgi?id=226054

Unreviewed test gardening.

Patch by Eric Hutchison <Eric Hutchison> on 2021-07-06

  • platform/mac-wk2/TestExpectations:
9:27 AM Changeset in webkit [279585] by Chris Dumez
  • 18 edits
    181 adds in trunk/LayoutTests

Resync cookies web-platform-tests from upstream
​https://bugs.webkit.org/show_bug.cgi?id=227641

Reviewed by Darin Adler.

LayoutTests/imported/w3c:

Resync cookies web-platform-tests from upstream 2c19d6ee62676ac90146.

  • resources/import-expectations.json:
  • web-platform-tests/cookies/*: Updated.

LayoutTests:

9:02 AM Changeset in webkit [279584] by youenn@apple.com
  • 6 edits in trunk/Source/WebKit

REGRESSION: [iOS] ASSERTION FAILED: !m_messageReceiverMapCount under WebKit::RemoteRemoteCommandListener::~RemoteRemoteCommandListener()
​https://bugs.webkit.org/show_bug.cgi?id=226248
<rdar://problem/78481758>

Reviewed by Eric Carlson.

Make sure to remove message receiver on the same gpu process connection it was added.
Also make sure to recreate remote command listener every time we use a new connection.
Do the same thing for RemoteAudioHardwareListener.
Also make sure to remove message receiver in RemoteRenderingBackendProxy::gpuProcessConnectionDidClose

Covered by existing tests.

  • WebProcess/GPU/graphics/RemoteRenderingBackendProxy.cpp:

(WebKit::RemoteRenderingBackendProxy::gpuProcessConnectionDidClose):

  • WebProcess/GPU/media/RemoteAudioHardwareListener.cpp:

(WebKit::RemoteAudioHardwareListener::RemoteAudioHardwareListener):
(WebKit::RemoteAudioHardwareListener::~RemoteAudioHardwareListener):

  • WebProcess/GPU/media/RemoteAudioHardwareListener.h:
  • WebProcess/GPU/media/RemoteRemoteCommandListener.cpp:

(WebKit::RemoteRemoteCommandListener::RemoteRemoteCommandListener):
(WebKit::RemoteRemoteCommandListener::~RemoteRemoteCommandListener):
(WebKit::RemoteRemoteCommandListener::ensureGPUProcessConnection):
(WebKit::RemoteRemoteCommandListener::gpuProcessConnectionDidClose):
(WebKit::RemoteRemoteCommandListener::updateSupportedCommands):

  • WebProcess/GPU/media/RemoteRemoteCommandListener.h:
9:00 AM Changeset in webkit [279583] by Chris Dumez
  • 10 edits in trunk/Source

Unreviewed, reverting r279495.

Seems to have caused a ~2% PLT5 regression

Reverted changeset:

"[macOS] Suspend WebProcesses that are in the process cache"
​https://bugs.webkit.org/show_bug.cgi?id=227269
​https://commits.webkit.org/r279495

8:17 AM Changeset in webkit [279582] by youenn@apple.com
  • 7 edits in trunk

Remove MediaStreamTrack.onconstrainederror
​https://bugs.webkit.org/show_bug.cgi?id=227696

Reviewed by Eric Carlson.

Source/WebCore:

Covered by updated tests.

  • Modules/mediastream/MediaStreamTrack.idl:
  • dom/EventNames.h:

Remove never used/deprecated event handler.

LayoutTests:

  • fast/mediastream/MediaStreamTrack-clone-expected.txt:
  • fast/mediastream/MediaStreamTrack-clone.html:
  • fast/mediastream/MediaStreamTrack.html:
7:54 AM Changeset in webkit [279581] by Antti Koivisto
  • 7 edits
    10 adds in trunk/LayoutTests

Import basic :has() tests
​https://bugs.webkit.org/show_bug.cgi?id=227703

Reviewed by Alan Bujtas.

Along with some other updates to css/selectors.

  • web-platform-tests/css/selectors/focus-visible-022.tentative-expected.txt: Added.
  • web-platform-tests/css/selectors/focus-visible-022.tentative.html: Added.
  • web-platform-tests/css/selectors/has-basic-expected.txt: Added.
  • web-platform-tests/css/selectors/has-basic.html: Added.
  • web-platform-tests/css/selectors/has-relative-argument-expected.txt: Added.
  • web-platform-tests/css/selectors/has-relative-argument.html: Added.
  • web-platform-tests/css/selectors/is-where-parsing-expected.txt:
  • web-platform-tests/css/selectors/is-where-parsing.html:
  • web-platform-tests/css/selectors/parsing/parse-has-expected.txt: Added.
  • web-platform-tests/css/selectors/parsing/parse-has.html: Added.
  • web-platform-tests/css/selectors/parsing/w3c-import.log:
  • web-platform-tests/css/selectors/user-invalid.html:
  • web-platform-tests/css/selectors/user-valid-expected.txt: Added.
  • web-platform-tests/css/selectors/user-valid.html: Added.
  • web-platform-tests/css/selectors/w3c-import.log:
4:10 AM Changeset in webkit [279580] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebKit

[GTK4] Navigation swipe doesn't work when the page scrolls horizontally
​https://bugs.webkit.org/show_bug.cgi?id=226173

Patch by Alexander Mikhaylenko <Alexander Mikhaylenko> on 2021-07-06
Reviewed by Michael Catanzaro.

There was a chunk of code that was never ported to GTK4. Port it.

  • UIProcess/API/gtk/PageClientImpl.cpp:

(WebKit::PageClientImpl::wheelEventWasNotHandledByWebCore):

1:02 AM Changeset in webkit [279579] by youenn@apple.com
  • 5 edits in trunk/Source/WebCore

Set kVTCompressionPropertyKey_MaxKeyFrameInterval in VideoSampleBufferCompressor
​https://bugs.webkit.org/show_bug.cgi?id=227680
<rdar://78027782>

Reviewed by Eric Carlson.

Source/WebCore:

Set kVTCompressionPropertyKey_MaxKeyFrameInterval in addition to kVTCompressionPropertyKey_MaxKeyFrameIntervalDuration.
Manually tested.

  • platform/mediarecorder/cocoa/VideoSampleBufferCompressor.mm:

(WebCore::VideoSampleBufferCompressor::initCompressionSession):

Source/WebCore/PAL:

  • pal/cf/VideoToolboxSoftLink.cpp:
  • pal/cf/VideoToolboxSoftLink.h:
12:55 AM Changeset in webkit [279578] by youenn@apple.com
  • 5 edits in trunk/Source/WebKit

NetworkRTCUDPSocketCocoa should update the port of its m_address field
​https://bugs.webkit.org/show_bug.cgi?id=227622

Reviewed by Eric Carlson.

Make sure we set the port to m_address field as this is used for setting up nw_connections.
Then notify WebProcess to proceed. This will ensure that we create a nw_connection with the right listening port.
Also fix the value given to nw_parameters_set_is_third_party_web_content.

Set local address reuse to true with nw_parameters_set_reuse_local_address so that listeners and connections can share the same address and port.
This does not always work so, we temporarily resort to use a 0 port instead of m_address.port() when setting up nw_connections.

Manually tested.

  • NetworkProcess/webrtc/NetworkRTCProvider.cpp:

(WebKit::NetworkRTCProvider::doSocketTaskOnRTCNetworkThread):

  • NetworkProcess/webrtc/NetworkRTCProvider.h:
  • NetworkProcess/webrtc/NetworkRTCUDPSocketCocoa.h:
  • NetworkProcess/webrtc/NetworkRTCUDPSocketCocoa.mm:

(WebKit::NetworkRTCUDPSocketCocoa::setListeningPort):
(WebKit::NetworkRTCUDPSocketCocoaConnections::NetworkRTCUDPSocketCocoaConnections):
(WebKit::NetworkRTCUDPSocketCocoaConnections::setListeningPort):

12:54 AM Changeset in webkit [279577] by youenn@apple.com
  • 2 edits in trunk/Source/WebKit

UserMediaCaptureManagerProxy::SourceProxy destructor should remove itself as observer before invalidating its ring buffer storage
​https://bugs.webkit.org/show_bug.cgi?id=227683

Reviewed by Eric Carlson.

Covered by existing tests.

  • UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp:

(WebKit::UserMediaCaptureManagerProxy::SourceProxy::~SourceProxy):
Previously, we were invalidating the ring buffer storage before removing the source proxy as audio observer.
This created the risk for the ring buffer to be recreated before the end of SourceProxy destructor.
To fix this, we invalidate the storage just after stopping observing.

12:48 AM Changeset in webkit [279576] by Fujii Hironori
  • 2 edits in trunk/Source/WebCore

[curl][Win] very high CPU load on page with WebSocket
​https://bugs.webkit.org/show_bug.cgi?id=227428
<rdar://problem/80150503>

Reviewed by Don Olmstead.

curl_socket_t is UINT_PTR on Windows while it is int on other
platforms. CurlStream::appendMonitoringFd was failing to update
maxfd because the following condition can't be true on Windows.

if (maxfd < *socket)

maxfd = *socket;

As the result, ::select was not called, and CurlStreamScheduler's
thread ran busy.

  • platform/network/curl/CurlStream.cpp:

(WebCore::CurlStream::appendMonitoringFd): Added static_cast.

12:44 AM Changeset in webkit [279575] by Fujii Hironori
  • 2 edits in trunk/Source/WebCore

[curl][Win] wss: WebSocket doesn't work since r271170
​https://bugs.webkit.org/show_bug.cgi?id=227694

Reviewed by Don Olmstead.

r271170 started to use CURLSSLOPT_NATIVE_CA for https for Windows.
However, I forgot to set the flag to WebSocket curl handles.

  • platform/network/curl/CurlContext.cpp:

(WebCore::CurlHandle::enableSSLForHost):
(WebCore::CurlHandle::enableHttp):

Jul 5, 2021:

10:45 PM Changeset in webkit [279574] by commit-queue@webkit.org
  • 5 edits in trunk/Source/WebKit

[GTK] Navigation swipe gesture can be triggered with mouse
​https://bugs.webkit.org/show_bug.cgi?id=227678

Patch by Alexander Mikhaylenko <Alexander Mikhaylenko> on 2021-07-05
Reviewed by Carlos Garcia Campos.

Originally, the navigation swipe gesture had a few checks to only make it possible to
trigger it with a touchpad or touchscreen, with an exception for simulated swipes
where we couldn't set the source easily.

During the rewrite in ​https://bugs.webkit.org/show_bug.cgi?id=212324, the check got
dropped, but it has a good reason to be there: not all devices are capable of
performing a gesture. Touchpads and touchscreens should be fine, trackpoints are
finicky, though can still technically work, but mouse are a no-go. While they can
start a swipe, they will never end it and the gesture will get stuck.

So, add the check back. Don't bother with the scroll direction this time though, while
that check made sense when it got added, at some point since then all scroll events
had GDK_SCROLL_SMOOTH direction and just set their deltas to (1, 0), (-1, 0), (0, 1)
or (0, -1), so that check stopped working, and the source type check should filter
mouse events anyway.

  • UIProcess/API/gtk/PageClientImpl.cpp:

(WebKit::PageClientImpl::wheelEventWasNotHandledByWebCore):

  • UIProcess/API/gtk/WebKitWebViewBase.cpp:

(webkitWebViewBaseHandleWheelEvent):
(webkitWebViewBaseScroll):
(webkitWebViewBaseTouchDragUpdate):
(webkitWebViewBaseTouchDragEnd):

  • UIProcess/ViewGestureController.h:
  • UIProcess/gtk/ViewGestureControllerGtk.cpp:

(WebKit::ViewGestureController::PendingSwipeTracker::scrollEventCanInfluenceSwipe):
(WebKit::isTouchEvent):
(WebKit::ViewGestureController::beginSimulatedSwipeInDirectionForTesting):
(WebKit::ViewGestureController::completeSimulatedSwipeInDirectionForTesting):

5:56 PM Changeset in webkit [279573] by Wenson Hsieh
  • 3 edits
    2 adds in trunk

Live Text should not be visible in video thumbnail images behind "Skip Ad" button on YouTube
​https://bugs.webkit.org/show_bug.cgi?id=227692

Reviewed by Darin Adler.

Source/WebCore:

Force text-shadow: none; for image overlay text, such that Live Text injected into image elements isn't
visible to the user when the containing image element has a text shadow.

Test: fast/images/text-recognition/image-overlay-with-text-shadow.html

  • html/shadow/imageOverlay.css:

(div#image-overlay):

LayoutTests:

Add a new layout test to verify that specifying text-shadow on image elements does not cause Live Text to
become visible.

  • fast/images/text-recognition/image-overlay-with-text-shadow-expected.html: Added.
  • fast/images/text-recognition/image-overlay-with-text-shadow.html: Added.
3:54 PM Changeset in webkit [279572] by Alan Bujtas
  • 2 edits in trunk/LayoutTests

[LFC][IFC] Test garderning for overflow-wrap:anywhere
​https://bugs.webkit.org/show_bug.cgi?id=227689

Unreviewed.

with IFC. Also use ImageOnlyFailure instead so that we can see progressions.

2:15 PM Changeset in webkit [279571] by commit-queue@webkit.org
  • 3 edits in trunk/Source/WebKit

[GTK] Kinetic scrolling interferes with gestures
​https://bugs.webkit.org/show_bug.cgi?id=226680

Patch by Alexander Mikhaylenko <Alexander Mikhaylenko> on 2021-07-05
Reviewed by Michael Catanzaro.

Simulate scroll events that would stop scrolling when we're starting any touch
gesture. Since we don't have a way to do that on touchpad yet, just stop it when
starting a zoom or a navigation swipe gesture instead.

  • UIProcess/API/gtk/PageClientImpl.cpp:

(WebKit::PageClientImpl::navigationGestureDidBegin):

  • UIProcess/API/gtk/WebKitWebViewBase.cpp:

(webkitWebViewBaseZoomBegin):
(webkitWebViewBaseTouchDragBegin):
(webkitWebViewBaseConstructed):

1:59 PM Changeset in webkit [279570] by Cameron McCormack
  • 7 edits
    21 deletes in trunk/LayoutTests

Move some Mac MathML test expectation files around
​https://bugs.webkit.org/show_bug.cgi?id=227520
<rdar://79749198>

Reviewed by Frédéric Wang.

LayoutTests/imported/w3c:

  • web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-combining-expected.txt:
  • web-platform-tests/mathml/relations/css-styling/padding-border-margin/border-002-expected.txt:

Make the macOS expectation file the default for these tests.

LayoutTests:

This should make it so that the same test expectation files are used
for Monterey as for Big Sur, without needing to add Monterey-specific
files.

  • platform/ios-simulator-wk2/TestExpectations:
  • platform/ios-wk2/TestExpectations:

Re-enable border-002.html.

  • platform/mac-wk1/TestExpectations:

Re-enable displaystyle-013.html and displaystyle-014.html.

  • platform/ios-wk2/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-combining-expected.txt: Removed.
  • platform/ios-wk2/imported/w3c/web-platform-tests/mathml/relations/css-styling/padding-border-margin/border-002-expected.txt: Removed.
  • platform/ios/imported/w3c/web-platform-tests/mathml/relations/css-styling/padding-border-margin/border-002-expected.txt: Removed.
  • platform/mac-bigsur-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/mo-minsize-maxsize-001-expected.txt: Removed.
  • platform/mac-bigsur-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-combining-expected.txt: Removed.
  • platform/mac-bigsur-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-stretchy-001-expected.txt: Removed.
  • platform/mac-bigsur-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-stretchy-002-expected.txt: Removed.
  • platform/mac-bigsur-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-symmetric-001-expected.txt: Removed.
  • platform/mac-bigsur-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-symmetric-005-expected.txt: Removed.
  • platform/mac-bigsur-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-symmetric-006-expected.txt: Removed.
  • platform/mac-bigsur-wk1/imported/w3c/web-platform-tests/mathml/relations/css-styling/padding-border-margin/border-002-expected.txt: Removed.
  • platform/mac-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/mo-minsize-maxsize-001-expected.txt: Removed.
  • platform/mac-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-stretchy-001-expected.txt: Removed.
  • platform/mac-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-stretchy-002-expected.txt: Removed.
  • platform/mac-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-symmetric-001-expected.txt: Removed.
  • platform/mac-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-symmetric-005-expected.txt: Removed.
  • platform/mac-wk1/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-symmetric-006-expected.txt: Removed.
  • platform/mac-wk1/imported/w3c/web-platform-tests/mathml/relations/css-styling/padding-border-margin/border-002-expected.txt: Removed.
  • platform/mac-wk2/imported/w3c/web-platform-tests/mathml/presentation-markup/operators/operator-dictionary-combining-expected.txt: Removed.
  • platform/mac-wk2/imported/w3c/web-platform-tests/mathml/relations/css-styling/padding-border-margin/border-002-expected.txt: Removed.
  • platform/mac/imported/w3c/web-platform-tests/mathml/relations/css-styling/padding-border-margin/border-002-expected.txt: Removed.
11:04 AM Changeset in webkit [279569] by commit-queue@webkit.org
  • 3 edits in trunk/Tools

[GTK] Installs in wrong directory on the bots
​https://bugs.webkit.org/show_bug.cgi?id=227684

Patch by Philippe Normand <​pnormand@igalia.com> on 2021-07-05
Reviewed by Aakash Jain.

The patch landed in r279563 induced a typo in the installation prefix path option passed to
build-webkit. Then the built-product-archive was failing to find the header andn pkgconfig
files to pack. This patch fixes the issue.

  • CISupport/build-webkit-org/steps.py:

(CompileWebKit.start):

  • CISupport/build-webkit-org/steps_unittest.py:

(TestCompileWebKit.test_success_gtk):

7:52 AM Changeset in webkit [279568] by Alan Bujtas
  • 4 edits in trunk

[LFC][IFC] Add support for conditionally hanging glyph
​https://bugs.webkit.org/show_bug.cgi?id=227676

Reviewed by Antti Koivisto.

Source/WebCore:

When a glyph at the end edge of a line hangs, it is not considered when measuring the line’s contents alignment.
If white-space is set to pre-wrap, the UA must (unconditionally) hang the trailing sequence,
unless the sequence is followed by a forced line break, in which case it must conditionally hang the sequence instead
(hang only if it does not otherwise fit in the line prior to justification).
e.g.
<div style="white-space: pre-wrap; width: 5ch; text-align: center"> 0 </p>
We center the _0_ content as the trailing whitespace does not hang here.

  • layout/formattingContexts/inline/InlineFormattingGeometry.cpp:

(WebCore::Layout::hangingGlyphWidth): No need for the struct. We can handle it by returning the hanging content width.
(WebCore::Layout::horizontalAlignmentOffset):
(WebCore::Layout::HangingTrailingWhitespaceContent::width const): Deleted.
(WebCore::Layout::HangingTrailingWhitespaceContent::isConditional const): Deleted.
(WebCore::Layout::HangingTrailingWhitespaceContent::setIsConditional): Deleted.
(WebCore::Layout::HangingTrailingWhitespaceContent::expand): Deleted.
(WebCore::Layout::HangingTrailingWhitespaceContent::reset): Deleted.
(WebCore::Layout::collectHangingTrailingWhitespaceContent): Deleted.

LayoutTests:

7:34 AM Changeset in webkit [279567] by Alexey Shvayka
  • 8 edits in trunk

Use AbortSignal's [PrivateIdentifier] whenSignalAborted() static method
​https://bugs.webkit.org/show_bug.cgi?id=227673

Reviewed by Youenn Fablet.

LayoutTests/imported/w3c:

  • web-platform-tests/streams/piping/abort.any-expected.txt:
  • web-platform-tests/streams/piping/abort.any.worker-expected.txt:
  • web-platform-tests/streams/piping/pipe-through.any-expected.txt:
  • web-platform-tests/streams/piping/pipe-through.any.worker-expected.txt:

Source/WebCore:

Enabled by refactoring in r279546, this change removes handcrafted @whenSignalAborted()
global function in favor of using equivalent generated [PrivateIdentifier] static method.

The generated method checks its arguments more strictly (as per WebIDL spec):
a TypeError is thrown for invalid AbortSignal argument, which progresses the WPT.

Test: imported/w3c/web-platform-tests/streams/piping/pipe-through.any.js

  • Modules/streams/ReadableStreamInternals.js:

(readableStreamPipeToWritableStream):

  • bindings/js/JSDOMGlobalObject.cpp:

(WebCore::JSDOMGlobalObject::addBuiltinGlobals):

4:48 AM Changeset in webkit [279566] by commit-queue@webkit.org
  • 2 edits in trunk/LayoutTests

[Media] test-webvtt.m3u8 is invalid
​https://bugs.webkit.org/show_bug.cgi?id=227681

Patch by Philippe Normand <​pnormand@igalia.com> on 2021-07-05
Reviewed by Xabier Rodriguez-Calvar.

This issue was detected by the GStreamer m3u8 parser.

  • http/tests/media/resources/hls/test-webvtt.m3u8:
2:58 AM Changeset in webkit [279565] by Philippe Normand
  • 2 edits in trunk/LayoutTests

Unreviewed, GLIB gardening triaging.

  • platform/glib/TestExpectations:
2:21 AM Changeset in webkit [279564] by Martin Robinson
  • 7 edits
    2 adds in trunk

[css-scroll-snap] Triggering a layout during scroll causes jittery scrolling on Mac when dragging the scrollbar
​https://bugs.webkit.org/show_bug.cgi?id=227478

Reviewed by Simon Fraser.

Source/WebCore:

When dragging the scrollbar thumb, wait to resnap after layout for a
given axis until the mouse button is up on the scrollbar. This prevents
the layout and the scrollbar from fighting to set the scroll position
which causes some pretty terrible jitter in this case.

Test: css3/scroll-snap/scroll-snap-drag-scrollbar-thumb-with-relayouts.html

  • platform/ScrollAnimationSmooth.cpp:

(WebCore::ScrollAnimationSmooth::updatePerAxisData): Fix an issue where the new position
was calculated incorrectly. This did not cause the animation to land on the wrong place,
but did cause a very janky animation progression when retriggering animations to the
same location.

  • platform/ScrollAnimator.cpp:

(WebCore::ScrollAnimator::retargetRunningAnimation): Added this helper, which retargets a
a running animation to allow for a smooth transition during relayouts.

  • platform/ScrollAnimator.h: Added new method definition.
  • platform/ScrollableArea.cpp:

(WebCore::ScrollableArea::resnapAfterLayout): Only snap after layout when the user is not
currently interacting with the scrollbar. Once the scrollbar isn't being interacted with,
snapping will occur already. When there is already some sort of animation in progress,
smoothly transition that animation to land on the new position instead of snapping there
immediately.

LayoutTests:

  • css3/scroll-snap/scroll-snap-drag-scrollbar-thumb-with-relayouts-expected.txt: Added.
  • css3/scroll-snap/scroll-snap-drag-scrollbar-thumb-with-relayouts.html: Added.
  • platform/ios/TestExpectations: Skip this test on iOS since it uses a scrollbar thumb drag.
1:25 AM Changeset in webkit [279563] by commit-queue@webkit.org
  • 9 edits
    1 add in trunk/Tools

[GTK] Pack header and .pc files in the built-product archive
​https://bugs.webkit.org/show_bug.cgi?id=227526

Patch by Philippe Normand <​pnormand@igalia.com> on 2021-07-05
Reviewed by Michael Catanzaro.

The header files and pkg-config files needed to build WebKitGTK apps are now included in the
built product zip file. As they're text files the impact on the zip size should not be
significant. In order to support this, two changes are introduced for the GTK build bot:

  • build-webkit is now called with a --prefix option
  • a new build step has been added, which installs the built files in the given prefix directory

Then built-product-archive can simply pack files from the install prefix directory.

Additionally the .a (potentially big) files are now excluded from the zip archive.

  • CISupport/build-webkit-org/factories.py:

(BuildFactory.init):

  • CISupport/build-webkit-org/steps.py:

(CompileWebKit.start):
(InstallBuiltProduct):

  • CISupport/built-product-archive:
  • Scripts/install-built-product: Added.
Note: See TracTimeline for information about the timeline view.