Timeline



Aug 9, 2021:

11:56 PM Changeset in webkit [280825] by ysuzuki@apple.com
  • 4 edits in trunk

[JSC] super-Latin1 white space and line terminator after regular expression literal misinterpreted as flags
https://bugs.webkit.org/show_bug.cgi?id=227944

Reviewed by Alexey Shvayka.

JSTests:

  • test262/expectations.yaml:

Source/JavaScriptCore:

There are non-Latin1 white-spaces and line-terminators, but Lexer::scanRegExp's code did not assume that.
As a result, if there is a non-Latin1 white-spaces or line-terminators after RegExp, we raise SyntaxError
while this is valid. This patch fixes that.

  • parser/Lexer.cpp:

(JSC::Lexer<T>::scanRegExp):

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

Blob URL changes after loading it
https://bugs.webkit.org/show_bug.cgi?id=228923

Reviewed by Geoff Garen.

Source/WebCore:

Blob URL changes after loading it. This is because we use URLWithBlobURLLifetimeExtension to
extend the lifetime of the Blob URL during the load and URLWithBlobURLLifetimeExtension ends
up creating a new public Blob URL. This is Web-observable so we need a way to extend the
lifetime of a Blob URL without actually generating a new Blob URL.

This patch replaces URLWithBlobURLLifetimeExtension with a new BlobURLHandle class which
extends the lifetime of a Blob URL as long as there are BlobURLHandle objects referring
to it. BlobURLHandle works with both private and public Blob URLs so it replaces
Blob::Handle as well (which I recently introduced via r280547). The Blob URL no longer
changes when we extend its lifetime. Instead, the Blob registry now keeps track of
references to a given Blob and only removes a Blob URL once there are no longer any
references to it.

Test: fast/files/blob-as-frame-url.html

  • Headers.cmake:
  • WebCore.xcodeproj/project.pbxproj:
  • bindings/js/SerializedScriptValue.cpp:

(WebCore::CloneSerializer::serialize):
(WebCore::CloneSerializer::CloneSerializer):
(WebCore::CloneSerializer::dumpIfTerminal):
(WebCore::SerializedScriptValue::SerializedScriptValue):
(WebCore::SerializedScriptValue::create):

  • bindings/js/SerializedScriptValue.h:

(WebCore::SerializedScriptValue::blobHandles const):
(WebCore::SerializedScriptValue::SerializedScriptValue):

  • fileapi/Blob.cpp:

(WebCore::Blob::Blob):
(WebCore::Blob::slice const):
(WebCore::Blob::size const):
(WebCore::Blob::handle const):

  • fileapi/Blob.h:

(WebCore::Blob::url const):

  • fileapi/BlobURL.cpp:

(WebCore::BlobURLHandle::BlobURLHandle):
(WebCore::BlobURLHandle::~BlobURLHandle):
(WebCore::BlobURLHandle::registerBlobURLHandleIfNecessary):
(WebCore::BlobURLHandle::unregisterBlobURLHandleIfNecessary):
(WebCore::BlobURLHandle::operator=):
(WebCore::BlobURLHandle::clear):

  • fileapi/BlobURL.h:

(WebCore::BlobURLHandle::BlobURLHandle):
(WebCore::BlobURLHandle::url const):

  • fileapi/ThreadableBlobRegistry.cpp:

(WebCore::ThreadableBlobRegistry::registerBlobURLHandle):
(WebCore::ThreadableBlobRegistry::unregisterBlobURLHandle):

  • fileapi/ThreadableBlobRegistry.h:
  • loader/PolicyChecker.cpp:

(WebCore::FrameLoader::PolicyChecker::extendBlobURLLifetimeIfNecessary const):
(WebCore::FrameLoader::PolicyChecker::checkNavigationPolicy):
(WebCore::FrameLoader::PolicyChecker::checkNewWindowPolicy):

  • loader/PolicyChecker.h:
  • platform/network/BlobRegistry.h:
  • platform/network/BlobRegistryImpl.cpp:

(WebCore::BlobRegistryImpl::registerFileBlobURL):
(WebCore::BlobRegistryImpl::registerBlobURL):
(WebCore::BlobRegistryImpl::registerBlobURLOptionallyFileBacked):
(WebCore::BlobRegistryImpl::registerBlobURLForSlice):
(WebCore::BlobRegistryImpl::unregisterBlobURL):
(WebCore::BlobRegistryImpl::addBlobData):
(WebCore::BlobRegistryImpl::registerBlobURLHandle):
(WebCore::BlobRegistryImpl::unregisterBlobURLHandle):

  • platform/network/BlobRegistryImpl.h:
  • xml/XMLHttpRequest.cpp:

(WebCore::XMLHttpRequest::setResponseType):
(WebCore::XMLHttpRequest::open):
(WebCore::XMLHttpRequest::prepareToSend):
(WebCore::XMLHttpRequest::send):
(WebCore::XMLHttpRequest::createRequest):
(WebCore::XMLHttpRequest::clearRequest):
(WebCore::XMLHttpRequest::didFinishLoading):

  • xml/XMLHttpRequest.h:

Source/WebKit:

  • NetworkProcess/NetworkConnectionToWebProcess.cpp:

(WebKit::NetworkConnectionToWebProcess::registerBlobURLHandle):
(WebKit::NetworkConnectionToWebProcess::unregisterBlobURLHandle):

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

(WebKit::NetworkProcessPlatformStrategies::createBlobRegistry):

  • WebProcess/FileAPI/BlobRegistryProxy.cpp:

(WebKit::BlobRegistryProxy::registerBlobURLHandle):
(WebKit::BlobRegistryProxy::unregisterBlobURLHandle):

  • WebProcess/FileAPI/BlobRegistryProxy.h:

Source/WebKitLegacy/mac:

  • WebCoreSupport/WebPlatformStrategies.mm:

Source/WebKitLegacy/win:

  • WebCoreSupport/WebPlatformStrategies.cpp:

LayoutTests:

Add layout test coverage.

  • fast/files/blob-as-frame-url-expected.txt: Added.
  • fast/files/blob-as-frame-url.html: Added.
8:11 PM Changeset in webkit [280823] by mmaxfield@apple.com
  • 2 edits in trunk

Update logging docs after r280758
https://bugs.webkit.org/show_bug.cgi?id=228899

Reviewed by Fujii Hironori.

Add more information about logging.

  • Introduction.md:
7:54 PM Changeset in webkit [280822] by Lauro Moura
  • 2 edits in trunk/LayoutTests

[GLIB] Garden two getUserMedia timeouts

Unreviewed test gardening.

  • platform/glib/TestExpectations:
7:29 PM Changeset in webkit [280821] by Fujii Hironori
  • 2 edits in trunk/Source/WTF

[GTK][WPE] REGRESSION(r280795): MemoryPressureHandlerUnix.cpp:45:28: error: ‘LogMemoryPressure’ was not declared in this scope
https://bugs.webkit.org/show_bug.cgi?id=228938

Unreviewed build fix.

  • wtf/unix/MemoryPressureHandlerUnix.cpp:
7:15 PM Changeset in webkit [280820] by Fujii Hironori
  • 2 edits in trunk/Source/WTF

[WTF][Win] REGRESSION(r280795) error LNK2019: unresolved external symbol "class WTF::String cdecl WTF::logLevelString(void)"
https://bugs.webkit.org/show_bug.cgi?id=228937
<rdar://problem/81722757>

Unresolved build fix.
The previous attempt (r280819) didn't actually fix the build
error. LoggingWin.cpp has to include LogInitialization.h.

  • wtf/win/LoggingWin.cpp:
6:36 PM Changeset in webkit [280819] by Fujii Hironori
  • 2 edits in trunk/Source/WTF

[WTF][Win] REGRESSION(r280795) error LNK2019: unresolved external symbol "class WTF::String cdecl WTF::logLevelString(void)"
https://bugs.webkit.org/show_bug.cgi?id=228937

Unreviewed build fix.

error LNK2019: unresolved external symbol "class WTF::String cdecl WTF::logLevelString(void)" (?logLevelString@WTF@@YA?AVString@1@XZ)

referenced in function "private: void cdecl WebKit::GPUProcessProxy::platformInitializeGPUProcessParameters(struct WebKit::GPUProcessCreationParameters &)"
(?platformInitializeGPUProcessParameters@GPUProcessProxy@WebKit@@AEAAXAEAUGPUProcessCreationParameters@2@@Z)
bin64\WebKit2.dll : fatal error LNK1120: 1 unresolved externals

  • wtf/LogInitialization.h: Added WTF_EXPORT_PRIVATE for logLevelString.
6:02 PM Changeset in webkit [280818] by Russell Epstein
  • 1 copy in tags/Safari-612.1.27.2.1

Tag Safari-612.1.27.2.1.

6:02 PM Changeset in webkit [280817] by Russell Epstein
  • 1 copy in tags/Safari-612.1.27.3.2

Tag Safari-612.1.27.3.2.

6:00 PM Changeset in webkit [280816] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.3-branch/Source/WebKit

Cherry-pick r280753. rdar://problem/81700429

Page on mhlw.go.jp triggers WebContent termination by GPU process
https://bugs.webkit.org/show_bug.cgi?id=228885
<rdar://81603231>

Reviewed by Wenson Hsieh.

https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000164708_00001.html triggered an issue
where RemoteRenderingBackend::finalizeRenderingUpdate() would be called when the
GPU process had just processed a "switching to next item buffer" meta command,
but had not yet received the new item buffer. This triggered the
MESSAGE_CHECK(initialHandle, "Missing initial shared display list handle");
in RemoteRenderingBackend::wakeUpAndApplyDisplayList().

Protect against this by having finalizeRenderingUpdate() check that
arguments.itemBufferIdentifier had been received, which is similar to what happens
inside the loop in wakeUpAndApplyDisplayList() already.

Not easily testable.

  • GPUProcess/graphics/RemoteRenderingBackend.cpp: (WebKit::RemoteRenderingBackend::finalizeRenderingUpdate):

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

5:59 PM Changeset in webkit [280815] by Russell Epstein
  • 8 edits in branches/safari-612.1.27.3-branch/Source

Versioning.

WebKit-7612.1.27.3.2

5:45 PM Changeset in webkit [280814] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.2-branch/Source/WebKit

Cherry-pick r280753. rdar://problem/81700429

Page on mhlw.go.jp triggers WebContent termination by GPU process
https://bugs.webkit.org/show_bug.cgi?id=228885
<rdar://81603231>

Reviewed by Wenson Hsieh.

https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000164708_00001.html triggered an issue
where RemoteRenderingBackend::finalizeRenderingUpdate() would be called when the
GPU process had just processed a "switching to next item buffer" meta command,
but had not yet received the new item buffer. This triggered the
MESSAGE_CHECK(initialHandle, "Missing initial shared display list handle");
in RemoteRenderingBackend::wakeUpAndApplyDisplayList().

Protect against this by having finalizeRenderingUpdate() check that
arguments.itemBufferIdentifier had been received, which is similar to what happens
inside the loop in wakeUpAndApplyDisplayList() already.

Not easily testable.

  • GPUProcess/graphics/RemoteRenderingBackend.cpp: (WebKit::RemoteRenderingBackend::finalizeRenderingUpdate):

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

5:43 PM Changeset in webkit [280813] by Russell Epstein
  • 8 edits in branches/safari-612.1.27.2-branch/Source

Versioning.

WebKit-7612.1.27.2.1

5:27 PM Changeset in webkit [280812] by Russell Epstein
  • 1 copy in tags/Safari-612.1.27.0.4

Tag Safari-612.1.27.0.4.

5:07 PM Changeset in webkit [280811] by mmaxfield@apple.com
  • 13 edits in trunk/Source

Create a Language log channel
https://bugs.webkit.org/show_bug.cgi?id=228764

Reviewed by Simon Fraser.

Source/WebKit:

  • Platform/Logging.h:
  • Shared/EntryPointUtilities/Cocoa/XPCService/XPCServiceMain.mm:

(WebKit::setAppleLanguagesPreference):

  • UIProcess/Launcher/mac/ProcessLauncherMac.mm:

(WebKit::ProcessLauncher::launchProcess):

  • UIProcess/WebProcessPool.cpp:

(WebKit::WebProcessPool::setOverrideLanguages):
(WebKit::WebProcessPool::initializeNewWebProcess):

  • UIProcess/WebProcessProxy.cpp:

(WebKit::WebProcessProxy::getLaunchOptions):

  • WebProcess/WebProcess.cpp:

(WebKit::WebProcess::initializeWebProcess):
(WebKit::WebProcess::userPreferredLanguagesChanged const):

Source/WTF:

There have been a variety of bug reports over the past months/years about the procedure
by which we determine navigator.language. It's actually somewhat convoluted, so this
patch adds a (debug) log channel for it so we can follow what it's doing easily.

To enable all the logging, run these commands:

% defaults write com.apple.WebKit.WebContent.Development WTFLogging Language
% defaults write com.apple.WebKit.WebContent.Development WebKit2Logging Language
% defaults write com.apple.WebKit.WebContent WTFLogging Language
% defaults write com.apple.WebKit.WebContent WebKit2Logging Language
% defaults write -g WTFLogging Language
% defaults write -g WebKit2Logging Language
% defaults write /Users/$USER/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari.plist WTFLogging Language
% defaults write /Users/$USER/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari.plist WebKit2Logging Language

  • wtf/Language.cpp:

(WTF::defaultLanguage):
(WTF::overrideUserPreferredLanguages):
(WTF::userPreferredLanguages):

  • wtf/Logging.cpp:
  • wtf/Logging.h:
  • wtf/cf/LanguageCF.cpp:

(WTF::platformUserPreferredLanguages):

  • wtf/cocoa/LanguageCocoa.mm:

(WTF::minimizedLanguagesFromLanguages):

4:59 PM Changeset in webkit [280810] by Robert Jenner
  • 2 edits in trunk/LayoutTests

[ Monterey Release wk2 ] platform/mac/fast/overflow/overflow-scrollbar-hit-test.html is a flaky crash
https://bugs.webkit.org/show_bug.cgi?id=228200

Unreviewed test gardening.

  • platform/mac-wk2/TestExpectations:
4:48 PM Changeset in webkit [280809] by commit-queue@webkit.org
  • 2 edits in trunk/Source/JavaScriptCore

Fix yet another -Wreturn-type warning
https://bugs.webkit.org/show_bug.cgi?id=228928

Unreviewed.

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-09

  • ftl/FTLLowerDFGToB3.cpp:

(JSC::FTL::DFG::LowerDFGToB3::compileGetByValImpl):

4:46 PM Changeset in webkit [280808] by Yijia Huang
  • 6 edits in trunk/Source/JavaScriptCore

[ARM64] Clean up and fix Pre/Post-Indexed Address Mode to Air for ARM64 (Load Instruction)
https://bugs.webkit.org/show_bug.cgi?id=228890

Reviewed by Keith Miller.

This patch cleans up and does minor fix to the previous patch (https://bugs.webkit.org/show_bug.cgi?id=228047).

For the modifications in b3/B3Generate.cpp and b3/B3CanonicalizePrePostIncrements.cpp, we
need to convert post-index candidates to the canonical form. So, the address value needs to
be moved immediately before the load. This is subject to the dominance constraints that add
must be controlled equivalent to the load. So, similarly, if we need to move the offset to
just before the load, the dominance constraints must be satisfied. Since it is a constant
value, a better approach is to add a new constant value before the memory value. Then,
eliminate the dead code.

There is a bug in b3/B3CanonicalizePrePostIncrements.cpp. The insertionSet.execute(BasicBlock)
will reorder value indexes in the basic block. So, we should re-search for the value index in
the block every time after the execution.

In b3/B3LowerToAir.cpp, we need m_locked checks on address and base values. If they are already
locked, there is no need to convert the Load instruction to the pre/post-increment form.

  • b3/B3CanonicalizePrePostIncrements.cpp:

(JSC::B3::canonicalizePrePostIncrements):

  • b3/B3Generate.cpp:

(JSC::B3::generateToAir):

  • b3/B3LowerToAir.cpp:
  • b3/air/AirArg.h:

(JSC::B3::Air::Arg::isValidIncrementIndexForm):
(JSC::B3::Air::Arg::isValidForm const):
(JSC::B3::Air::Arg::isValidPreIndexForm): Deleted.
(JSC::B3::Air::Arg::isValidPostIndexForm): Deleted.

  • b3/air/opcode_generator.rb:
4:41 PM Changeset in webkit [280807] by Simon Fraser
  • 7 edits
    2 adds in trunk

Vertical scroll with mouse wheel in horizontal scroller fails to propagate to the document
https://bugs.webkit.org/show_bug.cgi?id=228891
<rdar://81640239>

Reviewed by Antti Koivisto.

Source/WebCore:

If a page has a horizontal scrolling carousel with a non-passive wheel event handler, and a
user with a clicky scroll wheel mouse tries to vertically scroll over that carousel, then
we'd fail to propagate the scroll to the page. This affects apple.com/store.

This happened because we don't do latching for legacy mouse wheel events, so we hit the code
in EventHandler::handleWheelEventInAppropriateEnclosingBox(); this finds the carousel and
calls handleWheelEventInScrollableArea(), but that dispatches to the scrolling thread in way
that does not propagate the event to the nearest ancestor that can handle it.

The fix is to check that the ScrollableArea can handle the event, sharing some code that
already exists and was used by findEnclosingScrollableContainer(). This is a conservative
fix; it's possible that scrollableAreaCanHandleEvent() could be called down in
handleWheelEventInScrollableArea() but that will affect other call sites.

Test: fast/scrolling/mac/vertical-scroll-in-horizontal-scroller.html

  • page/EventHandler.cpp:

(WebCore::EventHandler::handleWheelEventInAppropriateEnclosingBox):
(WebCore::EventHandler::scrollableAreaCanHandleEvent):

  • page/EventHandler.h:
  • page/mac/EventHandlerMac.mm:

(WebCore::findEnclosingScrollableContainer):

LayoutTests:

  • fast/scrolling/mac/vertical-scroll-in-horizontal-scroller-expected.txt: Added.
  • fast/scrolling/mac/vertical-scroll-in-horizontal-scroller.html: Added.
  • tiled-drawing/scrolling/overflow-scroll-reduced-content.html: Convert this test to use

async scrolling. webkit.org/b/228898 tracks an existing problem that caused the test
to fail with non-async scrolling.

4:32 PM Changeset in webkit [280806] by Ayumi Kojima
  • 2 edits in trunk/LayoutTests

[ MacOS wk2 ] tiled-drawing/scrolling/scroll-snap/scroll-snap-momentum-in-non-snapping-axis.html is a flaky timeout.
https://bugs.webkit.org/show_bug.cgi?id=228930

Unreviewed test gardening.

  • platform/mac-wk2/TestExpectations:
3:55 PM Changeset in webkit [280805] by Adrian Perez de Castro
  • 3 edits in releases/WebKitGTK/webkit-2.32/Source/JavaScriptCore

Merge r280770 - Adding missing REFERENCED_FROM_ASM annotations to facilitate LTO
https://bugs.webkit.org/show_bug.cgi?id=228865

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-09
Reviewed by Yusuke Suzuki.

When investigating why WebKitGTK fails to build with LTO (link-time optimization) enabled,
one of the GCC developers noticed that we are missing attribute (("used")) on several
C++ functions declared in LLIntSlowPaths.h and WasmSlowPaths.h that are called only from
asm. Without this attribute, GCC assumes the functions are unused and drops them, then
linking fails because they really are used.

  • llint/LLIntSlowPaths.h:
  • wasm/WasmSlowPaths.h:
3:55 PM Changeset in webkit [280804] by Adrian Perez de Castro
  • 2 edits in releases/WebKitGTK/webkit-2.32/Source/WebCore

Merge r273868 - Crash in removeSymbolElementsFromSubtree()
https://bugs.webkit.org/show_bug.cgi?id=222397

Patch by Julian Gonzalez <julian_a_gonzalez@apple.com> on 2021-03-03
Reviewed by Ryosuke Niwa.

Skip children in removeSymbolElementsFromSubtree(), so that
we don't see nodes that have been removed in disassociateAndRemoveClones.

Thanks to Darin Adler for the initial version of this patch
and Ryosuke Niwa for refinements.

  • svg/SVGUseElement.cpp:

(WebCore::removeSymbolElementsFromSubtree):

3:55 PM Changeset in webkit [280803] by Adrian Perez de Castro
  • 7 edits in releases/WebKitGTK/webkit-2.32/Source/JavaScriptCore

Merge r278856 - Add ldp and stp support for FP registers, plus some bug fixes.
https://bugs.webkit.org/show_bug.cgi?id=226998
rdar://79313717

Reviewed by Robin Morisset.

This patch does the following:

  1. Add ldp and stp support for FP registers. This simply entails providing wrappers that take FPRegisterID and passing true for the V bit to the underlying loadStoreRegisterPairXXX encoding function. V is for vector (aka floating point). This will cause bit 26 in the instruction to be set indicating that it's loading / storing floating point registers.
  1. Add ARM64 disassembler support ldp and stp for FP registers. This includes fixing A64DOpcodeLoadStoreRegisterPair::mask to not exclude the FP versions of the instructions.
  1. Add ARM64Assembler query methods for determining if an immediate is encodable as the signed 12 bit immediate of ldp and stp instructions.
  1. Fix ldp and stp offset form to take an int instead of an unsigned. The immediate it takes is a 12-bit signed int, not unsigned.
  1. In loadStoreRegisterPairXXX encoding functions used by the forms of ldp and stp, RELEASE_ASSERT that the passed in immediate is encodable. Unlike ldur / stur, there is no form of ldp / stp that takes the offset in a register that can be used as a fail over. Hence, if the immediate is not encodable, this is a non-recoverable event. The client is responsible for ensuring that the offset is encodable.
  1. Added some testmasm tests for testing the offset form (as opposed to PreIndex and PostIndex forms) of ldp and stp. We currently only use the offset form in our JITs.
  • assembler/ARM64Assembler.h:

(JSC::ARM64Assembler::isValidLDPImm):
(JSC::ARM64Assembler::isValidLDPFPImm):
(JSC::ARM64Assembler::ldp):
(JSC::ARM64Assembler::ldnp):
(JSC::ARM64Assembler::isValidSTPImm):
(JSC::ARM64Assembler::isValidSTPFPImm):
(JSC::ARM64Assembler::stp):
(JSC::ARM64Assembler::stnp):
(JSC::ARM64Assembler::loadStoreRegisterPairPostIndex):
(JSC::ARM64Assembler::loadStoreRegisterPairPreIndex):
(JSC::ARM64Assembler::loadStoreRegisterPairOffset):
(JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):

  • assembler/AssemblerCommon.h:

(JSC::isValidSignedImm7):

  • assembler/MacroAssemblerARM64.h:

(JSC::MacroAssemblerARM64::loadPair64):
(JSC::MacroAssemblerARM64::storePair64):

  • assembler/testmasm.cpp:

(JSC::testLoadStorePair64Int64):
(JSC::testLoadStorePair64Double):

  • disassembler/ARM64/A64DOpcode.cpp:

(JSC::ARM64Disassembler::A64DOpcodeLoadStoreRegisterPair::format):

  • disassembler/ARM64/A64DOpcode.h:
3:54 PM Changeset in webkit [280802] by Adrian Perez de Castro
  • 4 edits
    1 add in releases/WebKitGTK/webkit-2.32

Merge r280422 - [WPE][GTK] .asc file extension is appended to filename of text/plain downloads
https://bugs.webkit.org/show_bug.cgi?id=228566

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-07-29
Reviewed by Adrian Perez de Castro.

Source/WebCore:

Our MIMETypeRegistry::preferredExtensionForMIMEType returns "asc" for text/plain, possibly
because "asc" sorts alphabetically ahead of all other possible file extensions for
text/plain, and we just pick the first one. So if the text file does not contain any file
extension, we give it a file extension for a GPG signature. Ouch.

I don't know how to fix it, but we don't need to, because we don't really want to append any
file extension for text/plain anyway. That's just annoying. If I download a file named
"backtrace" then I don't want it renamed to "backtrace.txt". That would be expected on
Windows, but certainly not from WebKitGTK. So I think it's reasonable to have a special case
for text/plain.

  • platform/xdg/MIMETypeRegistryXdg.cpp:

(WebCore::MIMETypeRegistry::preferredExtensionForMIMEType):

Tools:

  • TestWebKitAPI/Tests/WebKitGLib/TestDownloads.cpp:

(serverCallback):
(testDownloadTextPlainMIMEType):
(beforeAll):

  • TestWebKitAPI/Tests/WebKitGLib/resources/text: Added.
3:49 PM Changeset in webkit [280801] by Robert Jenner
  • 1 edit
    1 add in trunk/LayoutTests

(rebaseline) [ iOS ] 2 imported/w3c/web-platform-tests/css/cssom/* tests failing
https://bugs.webkit.org/show_bug.cgi?id=228200

Unreviewed iOS 15 rebase being added to OpenSource.

  • platform/ios/imported/w3c/web-platform-tests/css/cssom/cssstyledeclaration-csstext-expected.txt: Added.
3:49 PM Changeset in webkit [280800] by Russell Epstein
  • 1 edit in branches/safari-612.1.15.4-branch/Source/Makefile

Speculative Build Fix. rdar://79147214

2:38 PM Changeset in webkit [280799] by keith_miller@apple.com
  • 2 edits in trunk/Source/JavaScriptCore

Revert bad assert about the number of upsilons going into a phi
https://bugs.webkit.org/show_bug.cgi?id=228922

Reviewed by Yusuke Suzuki.

This assert was invalid because we sometimes emit unreachable phis
that don't have any incoming upsilons. Specifically for MultiGetByOffset.

  • ftl/FTLOutput.h:

(JSC::FTL::Output::phi):

2:24 PM Changeset in webkit [280798] by Russell Epstein
  • 12 edits
    2 adds in branches/safari-612.1.27.0-branch

Cherry-pick r280720. rdar://problem/81706814

MediaPlayerPrivateMediaStreamAVFObjC should skip enqueuing frames when not visible
https://bugs.webkit.org/show_bug.cgi?id=228816
<rdar://81077972>

Reviewed by Eric Carlson.

Source/WebCore:

Do not create layers when not needed.
This prevents enqueuing frames in a AVSampleBufferDisplayLayer that will only buffer them, thus breaking camera capture/video decoding.
We do this by not calling ensureLayers when getting a new track. Instead we react upon player renderingCanBeAccelerated value.

It is also unnecessary and takes CPU cycles to enqueue frames when the video element is not visible.
HTMLMediaElement and RenderVideo thus pass to MediaPlayer a new flag telling whether the video element is visible in the view port.
MediaPlayerPrivateMediaStreamAVFObjC will then skip enqueueing frames if not needed.

Add getter and internals API to cover these changes.

Test: fast/mediastream/mediaPlayer-visibility.html

  • html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::isVisibleInViewportChanged):
  • platform/graphics/MediaPlayer.cpp: (WebCore::MediaPlayer::loadWithNextMediaEngine): (WebCore::MediaPlayer::setVisibleInViewport):
  • platform/graphics/MediaPlayer.h:
  • platform/graphics/MediaPlayerPrivate.h: (WebCore::MediaPlayerPrivateInterface::setVisibleInViewport):
  • platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h:
  • platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm: (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::enqueueVideoSample): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::setVisible): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::setVisibleInViewport): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::checkSelectedVideoTrack): (WebCore::MediaPlayerPrivateMediaStreamAVFObjC::paintCurrentFrameInContext):
  • rendering/RenderVideo.cpp: (WebCore::RenderVideo::updatePlayer):
  • testing/Internals.cpp: (WebCore::Internals::isPlayerVisibleInViewport const):
  • testing/Internals.h:
  • testing/Internals.idl:

LayoutTests:

  • fast/mediastream/mediaPlayer-visibility-expected.txt: Added.
  • fast/mediastream/mediaPlayer-visibility.html: Added.

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

2:24 PM Changeset in webkit [280797] by Russell Epstein
  • 3 edits
    2 adds in branches/safari-612.1.27.0-branch

Cherry-pick r280586. rdar://problem/81706593

Check that shadow root is connected in invalidateStyleAfterStyleSheetChange
https://bugs.webkit.org/show_bug.cgi?id=227383

Patch by Rob Buis <rbuis@igalia.com> on 2021-08-03
Reviewed by Antti Koivisto.

Source/WebCore:

Check that shadow root is connected in invalidateStyleAfterStyleSheetChange.

Test: fast/shadow-dom/shadow-tree-removal-crash.html

  • style/StyleScope.cpp: (WebCore::Style::Scope::updateActiveStyleSheets):

LayoutTests:

Add test for this.

  • fast/shadow-dom/shadow-tree-removal-crash-expected.txt: Added.
  • fast/shadow-dom/shadow-tree-removal-crash.html: Added.

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

2:24 PM Changeset in webkit [280796] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.0-branch/Source/WebCore

Cherry-pick r280782. rdar://problem/81706720

WebGL 2.0 doesn't work on A8 devices (iPad mini 4, iPad Air 2)
https://bugs.webkit.org/show_bug.cgi?id=228904
rdar://79198313

Reviewed by Anders Carlsson.

We can't use the ANGLE Metal backend for WebGL 2 on A8 devices (e.g. iPad Mini 4
and iPad Air 2). In this case revert back to the OpenGL backend.

It would be better if this check was exposed as API from ANGLE, but
its only a small number of devices, and this code can be removed once
they are no longer supported.

  • platform/graphics/cocoa/GraphicsContextGLOpenGLCocoa.mm: (WebCore::platformSupportsMetal): Add a parameter to indicate WebGL 2, and check the Metal device family support. (WebCore::GraphicsContextGLOpenGL::GraphicsContextGLOpenGL):

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

2:14 PM Changeset in webkit [280795] by mmaxfield@apple.com
  • 32 edits
    1 copy
    6 adds in trunk/Source

Support WTF logging channels
https://bugs.webkit.org/show_bug.cgi?id=228768

Source/WebKit:

Reviewed by Fujii Hironori.

No new tests because there is no behavior change.

  • GPUProcess/GPUProcess.cpp:

(WebKit::GPUProcess::initializeGPUProcess):

  • GPUProcess/GPUProcessCreationParameters.cpp:

(WebKit::GPUProcessCreationParameters::encode const):
(WebKit::GPUProcessCreationParameters::decode):

  • GPUProcess/GPUProcessCreationParameters.h:
  • Shared/AuxiliaryProcess.cpp:

(WebKit::AuxiliaryProcess::initialize):

  • Shared/WebKit2Initialize.cpp:

(WebKit::InitializeWebKit2):

  • Shared/WebProcessCreationParameters.cpp:

(WebKit::WebProcessCreationParameters::encode const):
(WebKit::WebProcessCreationParameters::decode):

  • Shared/WebProcessCreationParameters.h:
  • UIProcess/Cocoa/GPUProcessProxyCocoa.mm:

(WebKit::GPUProcessProxy::platformInitializeGPUProcessParameters):

  • UIProcess/Cocoa/WebProcessPoolCocoa.mm:

(WebKit::WebProcessPool::platformInitializeWebProcess):

  • UIProcess/GPU/GPUProcessProxy.cpp:

(WebKit::GPUProcessProxy::platformInitializeGPUProcessParameters):

  • UIProcess/WebProcessPool.cpp:
  • WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::platformInitializeWebProcess):

Source/WebKitLegacy/mac:

Reviewed by Fujii Hironori.

  • WebView/WebView.mm:

(-[WebView _commonInitializationWithFrameName:groupName:]):

Source/WTF:

This patch builds on top of https://bugs.webkit.org/show_bug.cgi?id=228809, which added shared infrastructure
for logging. This patch simply triggers that shared infrastructure for WTF. There is no change in behavior -
the existing WTF logging channels currently are all implemented independently in custom ways, so this patch
just migrates them over to use the shared infrastructure.

Reviewed by Fujii Hironori.

  • WTF.xcodeproj/project.pbxproj:
  • wtf/Assertions.h:
  • wtf/CMakeLists.txt:
  • wtf/LogInitialization.cpp: Added.

(WTF::logChannels):

  • wtf/LogInitialization.h: Added.
  • wtf/Logging.cpp: Added.
  • wtf/Logging.h: Added.
  • wtf/MemoryPressureHandler.cpp:

(WTF::MemoryPressureHandler::singleton):

  • wtf/MemoryPressureHandler.h:
  • wtf/PlatformFTW.cmake:
  • wtf/PlatformGTK.cmake:
  • wtf/PlatformJSCOnly.cmake:
  • wtf/PlatformMac.cmake:
  • wtf/PlatformPlayStation.cmake:
  • wtf/PlatformWPE.cmake:
  • wtf/PlatformWin.cmake:
  • wtf/RefCountedLeakCounter.cpp:
  • wtf/cocoa/LoggingCocoa.mm: Copied from Source/WebKit/UIProcess/Cocoa/GPUProcessProxyCocoa.mm.

(WTF::logLevelString):

  • wtf/cocoa/MachSendRight.cpp:
  • wtf/cocoa/MainThreadCocoa.mm:
  • wtf/cocoa/MemoryPressureHandlerCocoa.mm:
  • wtf/unix/LoggingUnix.cpp: Added.

(WTF::logLevelString):

  • wtf/win/LoggingWin.cpp: Added.

(WTF::logLevelString):

2:08 PM Changeset in webkit [280794] by Wenson Hsieh
  • 3 edits
    4 moves in trunk/LayoutTests

Enable layout tests in editing/selection/ios by default in EWS
https://bugs.webkit.org/show_bug.cgi?id=228916

Reviewed by Tim Horton.

Enable tests in editing/selection/ios in OpenSource EWS. This greatly improves pre-commit test coverage of
various WebKit2 editing behaviors that are currently only covered by Apple-internal post-commit testers.

  • fast/events/touch/ios/become-key-window-when-focusing-editable-area-expected.txt: Renamed from LayoutTests/editing/selection/ios/become-key-window-when-focusing-editable-area-expected.txt.
  • fast/events/touch/ios/become-key-window-when-focusing-editable-area.html: Renamed from LayoutTests/editing/selection/ios/become-key-window-when-focusing-editable-area.html.
  • fast/events/touch/ios/selection-handles-after-touch-end-expected.txt: Renamed from LayoutTests/editing/selection/ios/selection-handles-after-touch-end-expected.txt.
  • fast/events/touch/ios/selection-handles-after-touch-end.html: Renamed from LayoutTests/editing/selection/ios/selection-handles-after-touch-end.html.

Move a couple of tests that rely on touch events out of this directory, and into fast/events/touch/ios
instead.

  • platform/ios-wk2/TestExpectations:
  • platform/ios/TestExpectations:
1:45 PM Changeset in webkit [280793] by commit-queue@webkit.org
  • 2 edits in trunk/LayoutTests

[GLIB] Mark 2 imported/w3c/web-platform-tests/css/css-overflow/clip-* tests as failing.
https://bugs.webkit.org/show_bug.cgi?id=228920

Unreviewed test gardening.

Patch by Arcady Goldmints-Orlov <Arcady Goldmints-Orlov> on 2021-08-09

  • platform/glib/TestExpectations:
1:41 PM WebKitGTK/2.32.x edited by Adrian Perez de Castro
(diff)
1:19 PM Changeset in webkit [280792] by Russell Epstein
  • 1 edit in branches/safari-612.1.15.4-branch/Source/Makefile

Speculative Build Fix. rdar://79147214

1:07 PM Changeset in webkit [280791] by Russell Epstein
  • 8 edits in trunk/Source

Versioning.

WebKit-7612.2.1

1:06 PM Changeset in webkit [280790] by Kate Cheney
  • 16 edits in trunk

Add console logging to encourage the use of authenticated encryption in WebCrypto
https://bugs.webkit.org/show_bug.cgi?id=228879
<rdar://problem/80655397>

Reviewed by Brent Fulgham.

Source/WebCore:

Warn about risks of using AES-CBC and AES-CTR modes in WebCrypto,
based on recommendations in
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/encrypt.
We should encourage authenticated encryption instead.

  • crypto/SubtleCrypto.cpp:

(WebCore::SubtleCrypto::encrypt):
(WebCore::SubtleCrypto::decrypt):

LayoutTests:

Update layout tests.

  • crypto/subtle/aes-cbc-cfb-decrypt-malformed-parameters-expected.txt:
  • crypto/subtle/aes-cbc-cfb-encrypt-malformed-parameters-expected.txt:
  • crypto/subtle/aes-cbc-generate-key-encrypt-decrypt-expected.txt:
  • crypto/subtle/aes-cbc-import-key-decrypt-expected.txt:
  • crypto/subtle/aes-cbc-import-key-encrypt-expected.txt:
  • crypto/subtle/aes-ctr-encrypt-malformed-parameters-expected.txt:
  • crypto/subtle/aes-ctr-generate-key-encrypt-decrypt-expected.txt:
  • crypto/subtle/aes-ctr-import-key-decrypt-expected.txt:
  • crypto/subtle/aes-ctr-import-key-encrypt-expected.txt:
  • crypto/subtle/decrypt-malformed-parameters-expected.txt:
  • crypto/subtle/encrypt-malformed-parameters-expected.txt:
  • TestExpectations:

We should probably not change imported test expectations, this marks
those tests as having console logging go to stderr. Additionally, some
tests call encrypt/decrypt functions up to 1000 times to test for
crashing, we should probably not log console to stdout in that case.

12:06 PM Changeset in webkit [280789] by Said Abou-Hallawa
  • 18 edits
    4 deletes in trunk

Ease sandboxing restrictions for Mail to allow HEIF image decoding
https://bugs.webkit.org/show_bug.cgi?id=228812
<rdar://80967782>

Reviewed by Per Arne Vollan.

Source/WebCore:

No need to pass kCGImageSourceEnableRestrictedDecoding to ImageIO anymore.

  • platform/graphics/cg/ImageDecoderCG.cpp:

(WebCore::createImageSourceOptions):

Source/WebCore/PAL:

Delete unneeded SPIs and their soft-linking.

  • PAL.xcodeproj/project.pbxproj:
  • pal/cf/VideoToolboxSoftLink.cpp:
  • pal/cf/VideoToolboxSoftLink.h:
  • pal/cocoa/MediaToolboxSoftLink.cpp:
  • pal/cocoa/MediaToolboxSoftLink.h:
  • pal/spi/cg/ImageIOSPI.h:
  • pal/spi/cocoa/VideoToolboxSPI.h: Removed.

Source/WebKit:

If the running application is Mail, add a sandbox extension to allow HEIF
image decoding. There is no plan right now to enable HEIF in WebKit. So
do not try to support decoding it outside Mail.

  • Shared/WebProcessCreationParameters.cpp:

(WebKit::WebProcessCreationParameters::encode const):
(WebKit::WebProcessCreationParameters::decode):

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

(WebKit::WebProcessPool::platformInitializeWebProcess):

  • WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::platformInitializeWebProcess):
(WebKit::WebProcess::initializeSandbox):
(WebKit::restrictImageAndVideoDecoders): Deleted.

LayoutTests:

Delete the only HEIF ref test since the HEIF format has not been enabled
in WebKit and it requires a sandbox extension to be decoded correctly on
recent macOS versions.

  • TestExpectations:
  • fast/images/heic-as-background-image-expected.html: Removed.
  • fast/images/heic-as-background-image.html: Removed.
  • fast/images/resources/green-400x400.heic: Removed.
  • platform/ios/TestExpectations:
  • platform/mac/TestExpectations:
11:59 AM Changeset in webkit [280788] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.0-branch/Source/WebKit

Cherry-pick r280753. rdar://problem/81700429

Page on mhlw.go.jp triggers WebContent termination by GPU process
https://bugs.webkit.org/show_bug.cgi?id=228885
<rdar://81603231>

Reviewed by Wenson Hsieh.

https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000164708_00001.html triggered an issue
where RemoteRenderingBackend::finalizeRenderingUpdate() would be called when the
GPU process had just processed a "switching to next item buffer" meta command,
but had not yet received the new item buffer. This triggered the
MESSAGE_CHECK(initialHandle, "Missing initial shared display list handle");
in RemoteRenderingBackend::wakeUpAndApplyDisplayList().

Protect against this by having finalizeRenderingUpdate() check that
arguments.itemBufferIdentifier had been received, which is similar to what happens
inside the loop in wakeUpAndApplyDisplayList() already.

Not easily testable.

  • GPUProcess/graphics/RemoteRenderingBackend.cpp: (WebKit::RemoteRenderingBackend::finalizeRenderingUpdate):

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

11:59 AM Changeset in webkit [280787] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.0-branch/Source/WebCore

Cherry-pick r280727. rdar://problem/81700728

Crash at WebKit::WebPage::requestTextRecognition caused by accessibility invocation.
https://bugs.webkit.org/show_bug.cgi?id=228864
rdar://80679512

Reviewed by Chris Fleizach.

  • accessibility/AXImage.cpp: (WebCore::AXImage::imageOverlayElements): It was calling requestTextRecognition with *element(), but element() can return nullptr, which would lead to the crash.

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

11:59 AM Changeset in webkit [280786] by Russell Epstein
  • 7 edits in branches/safari-612.1.27.0-branch/Source

Cherry-pick r280723. rdar://problem/81700532

[Cocoa] Remove support for AVAssetImageGenerator
https://bugs.webkit.org/show_bug.cgi?id=228560
<rdar://problem/81336280>

Reviewed by Eric Carlson.

Source/WebCore:

A much more minimal approach to removing support for AVAssetImageGenerator.

The only time we use an AVAssetImageGenerator (as opposed to an AVPlayerItemVideoOutput)
is when the latter does not currently have an available image enqueued. Because painting
is a synchronous operation, we use a synchronous API (the generator) to create an image
for that operation. However, this can create deadlocks if (for example) the resource needs
to load data on the main thread in order to complete the painting operation.

Instead, allow the main runloop to spin while waiting (up to 1_s) for the video output
to receive a decoded frame.

Drive-by fixes:

  • Don't create an AVPlayerLayer at AVPlayer-creation; this causes the AVPlayerItemVideoOutput to never receive a decoded frambe (as the layer is not in a CALayer-heirarchy).
  • preferredRenderingMode() shouldn't be "none" when the page isn't visible. We already just mark the layer as "hidden" in that case.
  • Don't tear down the AVPlayerItemVideoOutput when creating an AVPlayerLayer; it'll just get re-created anyway.
  • platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp: (WebCore::MediaPlayerPrivateAVFoundation::preferredRenderingMode const): (WebCore::MediaPlayerPrivateAVFoundation::setUpVideoRendering):
  • platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:
  • platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm: (WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayer): (WebCore::MediaPlayerPrivateAVFoundationObjC::paintCurrentFrameInContext): (WebCore::MediaPlayerPrivateAVFoundationObjC::createVideoOutput): (WebCore::MediaPlayerPrivateAVFoundationObjC::paintWithVideoOutput): (WebCore::MediaPlayerPrivateAVFoundationObjC::waitForVideoOutputMediaDataWillChange): (WebCore::MediaPlayerPrivateAVFoundationObjC::outputMediaDataWillChange): (-[WebCoreAVFPullDelegate outputMediaDataWillChange:]): (-[WebCoreAVFPullDelegate setParent:]):

Source/WebKit:

Drive-by fix: we're passing the wrong value into acceleratedRenderingStateChanged(), and
we're not setting the correct initial value on MediaPlayerPrivateRemote creation.

  • GPUProcess/media/RemoteMediaPlayerProxy.h:
  • WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp: (WebKit::MediaPlayerPrivateRemote::MediaPlayerPrivateRemote): (WebKit::MediaPlayerPrivateRemote::acceleratedRenderingStateChanged):

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

11:59 AM Changeset in webkit [280785] by Russell Epstein
  • 12 edits
    1 delete in branches/safari-612.1.27.0-branch

Cherry-pick r280624. rdar://problem/81700532

Unreviewed, reverting r280531 and r280589.

caused

Reverted changesets:

"[Cocoa] Remove support for AVAssetImageGenerator"
https://bugs.webkit.org/show_bug.cgi?id=228560
https://commits.webkit.org/r280531

"REGRESSION (r280531): multiple modern-media-controls tests
have become flaky timeouts"
https://bugs.webkit.org/show_bug.cgi?id=228714
https://commits.webkit.org/r280589

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

11:24 AM Changeset in webkit [280784] by stephan.szabo@sony.com
  • 2 edits in trunk/Source/WebKitLegacy/win

[WinCairo][Debug] Build fix after r280756
https://bugs.webkit.org/show_bug.cgi?id=228918

Reviewed by Darin Adler.

  • WebView.cpp: Update call to initializeLogChannelsIfNecessary
11:22 AM Changeset in webkit [280783] by Robert Jenner
  • 1 edit
    2 adds in trunk/LayoutTests

(rebaseline) [ iOS ] 2 imported/w3c/web-platform-tests/css/cssom/* tests failing
https://bugs.webkit.org/show_bug.cgi?id=228200

Uneviewed test gardening.

  • platform/ios/imported/w3c/web-platform-tests/css/cssom/css-style-attr-decl-block-expected.txt: Added.
11:16 AM Changeset in webkit [280782] by dino@apple.com
  • 2 edits in trunk/Source/WebCore

WebGL 2.0 doesn't work on A8 devices (iPad mini 4, iPad Air 2)
https://bugs.webkit.org/show_bug.cgi?id=228904
rdar://79198313

Reviewed by Anders Carlsson.

We can't use the ANGLE Metal backend for WebGL 2 on A8 devices (e.g. iPad Mini 4
and iPad Air 2). In this case revert back to the OpenGL backend.

It would be better if this check was exposed as API from ANGLE, but
its only a small number of devices, and this code can be removed once
they are no longer supported.

  • platform/graphics/cocoa/GraphicsContextGLOpenGLCocoa.mm:

(WebCore::platformSupportsMetal): Add a parameter to indicate WebGL 2, and
check the Metal device family support.
(WebCore::GraphicsContextGLOpenGL::GraphicsContextGLOpenGL):

10:09 AM Changeset in webkit [280781] by Russell Epstein
  • 8 edits in branches/safari-612.1.27.0-branch/Source

Versioning.

WebKit-7612.1.27.0.4

9:39 AM Changeset in webkit [280780] by Kocsen Chung
  • 8 edits in trunk/Source

Versioning.

WebKit-7612.2.1

9:06 AM Changeset in webkit [280779] by commit-queue@webkit.org
  • 2 edits in trunk/LayoutTests

[GLIB] fast/events/check-defocus-event-order-when-triggered-by-mouse-click.html fails due to rounded corners
https://bugs.webkit.org/show_bug.cgi?id=228877

Patch by Arcady Goldmints-Orlov <Arcady Goldmints-Orlov> on 2021-08-09
Reviewed by Adrian Perez de Castro.

In the test, move the cursor to the center of the input element to be
clicked on to avoid issues with rounded corners.

  • fast/events/check-defocus-event-order-when-triggered-by-mouse-click.html:
8:59 AM Changeset in webkit [280778] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebCore

-Warray-bounds, -Wstringop-truncation warnings in Packed.h
https://bugs.webkit.org/show_bug.cgi?id=226557
<rdar://problem/79103658>

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-09
Reviewed by Adrian Perez de Castro.

Suppressing the -Warray-bounds warning introduces the -Wstringop-truncation warning, which
cannot be suppressed with pragmas. The only solution I found is -Wno-stringop-truncation. I
could apply it globally, but this warning does not have many false positives, so I think
it's better to suppress the warning only for WebSocket.cpp. Unfortunately we have to remove
it from the unified build in order to add custom flags, but it seems worth it to avoid
suppressing the warning globally.

  • CMakeLists.txt:
8:22 AM Changeset in webkit [280777] by Lauro Moura
  • 2 edits in trunk/LayoutTests

[GLIB] Garden accessibility/selected-state-changed-notifications.html timeouts

Unreviewed test gardening.

  • platform/glib/TestExpectations:
8:15 AM Changeset in webkit [280776] by jer.noble@apple.com
  • 8 edits in trunk/Source

[Cocoa|GPU] platformLayer() not always added to remotedly hosted context; black video while playing
https://bugs.webkit.org/show_bug.cgi?id=228873
<rdar://81271107>

Reviewed by Eric Carlson.

Source/WebCore:

Coalesce calls to renderingModeChanged() by setting a flag to call renderingModeChanged() in
the next run loop, and call into this coalescing method, setNeedsRenderingModeChanged(),
whenever the MediaPlayerPrivateAVFoundation subclasses create or destroy a video layer
or software painting context. This ensures that the MediaPlayerClient is always notified
when the rendering mode changes, regardless of why that change occurred.

Drive-by fix: replace the call in createVideoLayer() to "callOnMainThread()"
with "ensureOnMainThread()". The call to "callOnMainThread()" was added to avoid a
deadlock in WebKitLegacy, and "ensureOnMainThread()" has the correct behavior there, but
will be synchronous in WebKit.

  • platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:

(WebCore::MediaPlayerPrivateAVFoundation::setUpVideoRendering):
(WebCore::MediaPlayerPrivateAVFoundation::setNeedsRenderingModeChanged):
(WebCore::MediaPlayerPrivateAVFoundation::renderingModeChanged):
(WebCore::MediaPlayerPrivateAVFoundation::prepareForRendering):

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

(WebCore::MediaPlayerPrivateAVFoundationCF::destroyVideoLayer):
(WebCore::AVFWrapper::createAVCFVideoLayer):
(WebCore::AVFWrapper::createImageGenerator):
(WebCore::AVFWrapper::destroyImageGenerator):

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

(WebCore::MediaPlayerPrivateAVFoundationObjC::createVideoLayer):
(WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerLayer):
(WebCore::MediaPlayerPrivateAVFoundationObjC::destroyVideoLayer):
(WebCore::MediaPlayerPrivateAVFoundationObjC::createVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::destroyVideoOutput):

Source/WebKit:

Currently, the RemoteMediaPlayerProxy will insert its MediaPlayer's platformLayer() into the
remotely hosted context when it receives a "firstVideoFrameAvailable()" notification.
However this is problematic for two reasons: AVPlayerLayer may not become "ready for
playback" when it is not in an active CALayer heirarchy, and for
MediaPlayerPrivateAVFoundation, firstVideoFrameAvailable() is only fired during
updateStates(), which is not guaranteed to occur unless another state change occurs.

Instead, reparent the MediaPlayer's platformLayer() when we receive a
mediaPlayerRenderingModeChanged() notification, which notifies the client whenever a
platformLayer() is created or destroyed.

  • GPUProcess/media/RemoteMediaPlayerProxy.cpp:
  • GPUProcess/media/cocoa/RemoteMediaPlayerProxyCocoa.mm:

(WebKit::RemoteMediaPlayerProxy::mediaPlayerFirstVideoFrameAvailable):
(WebKit::RemoteMediaPlayerProxy::mediaPlayerRenderingModeChanged):

6:10 AM Changeset in webkit [280775] by aboya@igalia.com
  • 2 edits in trunk/Source/WebCore

[MSE][GStreamer] Update tracks synchronously
https://bugs.webkit.org/show_bug.cgi?id=228825

Reviewed by Xabier Rodriguez-Calvar.

A mistake introduced with the WebKitMediaSrc v2 patch made the call to
updateTracks() in MediaPlayerPrivateGStreamer asynchronous.

This introduced a subtle race condition in which the "resize" event
may be handled before updateTracks() is called, therefore m_hasVideo
has not yet been set to true, and querying the video size from the
"resize" event handler returns 0x0.

This fixes a timeout flake in media/media-source/media-source-resize.html.

  • platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:

(WebCore::MediaPlayerPrivateGStreamer::handleStreamCollectionMessage):

5:49 AM Changeset in webkit [280774] by imanol
  • 6 edits in trunk

Implement fullscreen in WPEView
https://bugs.webkit.org/show_bug.cgi?id=227951

Reviewed by Adrian Perez de Castro.

Notify DOM fullscreen enter request to libwpe and handle exit fullscreen from libwpe.

  • UIProcess/API/wpe/WPEView.cpp:

(WKWPE::m_backend):
(WKWPE::View::setFullScreen):

  • UIProcess/API/wpe/WPEView.h:
5:35 AM Changeset in webkit [280773] by ysuzuki@apple.com
  • 2 edits in trunk/Source/WebCore

Unreviewed, remove WTFLogAlways
https://bugs.webkit.org/show_bug.cgi?id=228858

  • html/parser/HTMLConstructionSite.cpp:

(WebCore::WhitespaceCache::lookup):

4:20 AM WebKitGTK/2.32.x edited by Adrian Perez de Castro
(diff)
4:05 AM Changeset in webkit [280772] by Cameron McCormack
  • 7 edits in trunk/Source/WebCore

Cache recently atomized all-whitespace strings for use by the HTML parser
https://bugs.webkit.org/show_bug.cgi?id=228858

Reviewed by Yusuke Suzuki.

We have a memory optimization where the HTML parser will atomize any
text node string that is all whitespace. This can be expensive,
as we need to loop over the string's characters three times: to detect
that it is indeed all whitespace, to hash the string, and to compare
to any existing entry in the atom hash table.

Many whitespace strings encountered during parsing have a limited
form -- they have a few runs of consecutive equal whitespace
characters, e.g. it's common to see a newline followed by a number
of space characters. We can take advantage of this by compressing
the whitespace string into a simple run-length encoded form while
we loop over the characters to check that the string is all
whitespace. Unlike a hash, this encoded form perfectly identifies the
string content.

We add a WhitespaceCache that is owned by the Document, which stores
the most recently atomized all-whitespace string encountered by the
parser for a given length, and keys it with the encoded form. The
parser can then look up the WhitespaceCache and find an AtomString
without the need to perform a lookup in the atom hash table.

The WhitespaceCache continues to hold on to the cached whitespace
atoms for the life of the document. The WhitespaceCache itself
takes a bit over 1 KiB when empty, and if completely populated would
take a bit over 2 KiB plus 8 KiB of atom string data (a 1 byte string,
plus a 2 byte string, plus a 3 byte string, etc.). This doesn't seem
high enough to be worth clearing this out just to avoid memory usage
from text nodes that have been removed from the document.

We have the Document own the WhitespaceCache so that it's not just the
initial document load, but any uses of innerHTML or other fragment
parsing APIs, that can re-use previously atomized whitespace strings.

The choice of WhitespaceCache::maximumCachedStringLength = 128 is
somewhat arbitrary. The value must be <= 255 to avoid overflowing
the specific 64 bit code format used to encode the whitespace string.
Testing on Speedometer shows whitespace strings only up to length 26,
but it may be worth testing other content to see if it's worth
reducing maximumCachedStringLength.

When running Speedometer 2, no entries in the cache ever get replaced
by a different whitespace string of the same length, and 16 unique
whitespace string lengths are encountered.

We don't compute codes for 16 bit strings, since 16 bit strings passed
in to WhitespaceCache::lookup() are almost always the entirety of an
HTMLToken's data, and HTMLToken tracks whether any 16 bit characters are
present. If there are any, then we know the string cannot be all
whitespace, and we use a WhitespaceMode value of NotAllWhitespace to
skip the atomization altogether.

This patch is an almost 1% improvement on Speedometer 2.

  • dom/Document.cpp:

(WebCore::m_whitespaceCache):

  • dom/Document.h:

(WebCore::Document::whitespaceCache):

  • html/parser/HTMLConstructionSite.cpp:

(WebCore::HTMLConstructionSite::HTMLConstructionSite):
(WebCore::HTMLConstructionSite::insertTextNode):
(WebCore::WhitespaceCache::codeForString):
(WebCore::WhitespaceCache::lookup):

  • html/parser/HTMLConstructionSite.h:
  • html/parser/HTMLTreeBuilder.cpp:

(WebCore::HTMLTreeBuilder::insertPhoneNumberLink):
(WebCore::HTMLTreeBuilder::linkifyPhoneNumbers):
(WebCore::HTMLTreeBuilder::processCharacterBufferForInBody):

  • html/parser/HTMLTreeBuilder.h:
3:53 AM Changeset in webkit [280771] by Cameron McCormack
  • 2 edits in trunk/Source/WebCore

Increase inline size of HTMLToken::Attribute::value
https://bugs.webkit.org/show_bug.cgi?id=228910
<rdar://problem/81686150>

Reviewed by Yusuke Suzuki.

Some attributes we encounter during HTML parsing are longer than 32
characters, and this shows up on profiles.

This patch improves Speedometer 2 by a modest amount (~0.3%).

  • html/parser/HTMLToken.h:
3:53 AM Changeset in webkit [280770] by commit-queue@webkit.org
  • 3 edits in trunk/Source/JavaScriptCore

Adding missing REFERENCED_FROM_ASM annotations to facilitate LTO
https://bugs.webkit.org/show_bug.cgi?id=228865

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-09
Reviewed by Yusuke Suzuki.

When investigating why WebKitGTK fails to build with LTO (link-time optimization) enabled,
one of the GCC developers noticed that we are missing attribute (("used")) on several
C++ functions declared in LLIntSlowPaths.h and WasmSlowPaths.h that are called only from
asm. Without this attribute, GCC assumes the functions are unused and drops them, then
linking fails because they really are used.

  • llint/LLIntSlowPaths.h:
  • wasm/WasmSlowPaths.h:
2:58 AM Changeset in webkit [280769] by imanol
  • 4 edits in trunk/Source/WebKit

Allow custom IPC::Attachment messaging in ConnectionUnix.cpp
https://bugs.webkit.org/show_bug.cgi?id=227740

Reviewed by Žan Doberšek.

In order to share AHardwareBuffer handles via IPC we need to use the AHardwareBuffer_sendHandleToUnixSocket()
and AHardwareBuffer_recvHandleFromUnixSocket() functions. This is not currently compatible with the Attachment
API used in UnixConnection, as those functions use custom messaging into the socked fd.

This patch adds a CustomWriterType Attachment that allows custom messaging going into the socket fd.

  • Platform/IPC/unix/ConnectionUnix.cpp:

Aug 8, 2021:

7:09 PM Changeset in webkit [280768] by Russell Epstein
  • 1 copy in tags/Safari-612.1.27.0.3

Tag Safari-612.1.27.0.3.

6:21 PM Changeset in webkit [280767] by Wenson Hsieh
  • 14 edits
    2 adds in trunk

caret-color does not work on first click in ios
https://bugs.webkit.org/show_bug.cgi?id=228859
rdar://81674787

Reviewed by Tim Horton.

Source/WebKit:

Addresses a couple of issues that cause the caret-color CSS property to not be applied when focusing editable
content on iOS. See below for more details.

Test: editing/caret/ios/caret-color-after-refocusing-input.html

  • Platform/spi/ios/UIKitSPI.h:
  • UIProcess/API/ios/WKWebViewPrivateForTestingIOS.h:
  • UIProcess/API/ios/WKWebViewTestingIOS.mm:

(-[WKWebView _serializedSelectionCaretBackgroundColorForTesting]):

Add support for a new test-only helper method. See Tools/ChangeLog for more information.

  • UIProcess/ios/WKContentViewInteraction.h:
  • UIProcess/ios/WKContentViewInteraction.mm:

(WebKit::WKSelectionDrawingInfo::WKSelectionDrawingInfo):
(WebKit::operator==):
(WebKit::operator<<):

Make a minor adjustment to ensure that changes to caretColor in EditorState are propagated to UIKit's
selection views. To achieve this, we add caretColor to WKSelectionDrawingInfo, and force the text selection
view to update the caret background color when the caret color changes (alongside other selection UI geometry
changes, which are applied underneath the call to -selectionChanged).

(-[WKContentView _updateChangedSelection:]):
(-[WKContentView textInteractionAssistant]):

  • WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::getPlatformEditorState const):

Address an existing FIXME which (mostly) fixes this bug. Currently, the caret color is only computed when
WebPage::m_focusedElement is set. However, when resigning first responder, we clear out WebPage's
m_focusedElement) right before updating the DOM selection, which creates a brief window during which we
compute an EditorState with a caretColor of transparent black.

To avoid this inconsistency, we instead compute the caret color from the selection container; this has the
additional benefit of allowing the caret color to change when changing selection within a single editable host
with multiple caret colors (instead of always just using the focused element's caret color).

Note that while this adjustment to WebPage::getPlatformEditorState is sufficient to ensure that the value of
-[WKContentView insertionPointColor] (which is based on EditorState) is always up-to-date, this doesn't
guarantee that the actual color of UIKit's caret view reflects the updated -insertionPointColor, which results
in situations where the caret color appears out-of-date after hiding the keyboard and refocusing an input field.
To fix this, we need the other adjustment in WKContentView (see above).

Tools:

Make it possible to test this bug by adding a UIScriptController hook to request the background color of the
current selection view's caret view, as serialized CSS text. See LayoutTests/ChangeLog for more details.

  • TestRunnerShared/UIScriptContext/Bindings/UIScriptController.idl:
  • TestRunnerShared/UIScriptContext/UIScriptController.h:

(WTR::UIScriptController::selectionCaretBackgroundColor const):

  • WebKitTestRunner/ios/UIScriptControllerIOS.h:
  • WebKitTestRunner/ios/UIScriptControllerIOS.mm:

(WTR::UIScriptControllerIOS::selectionCaretBackgroundColor const):

LayoutTests:

Add a new layout test that exercises the issue, as reported in Bugzilla (the call to -resignFirstResponder
simulates backgrounding Safari). To achieve this, we also introduce a script controller testing helper to grab
the native background color of the UITextSelectionView's caret view; see Tools/ChangeLog for more details.

  • editing/caret/ios/caret-color-after-refocusing-input-expected.txt: Added.
  • editing/caret/ios/caret-color-after-refocusing-input.html: Added.
  • resources/ui-helper.js:

(window.UIHelper.selectionCaretBackgroundColor):

2:53 PM Changeset in webkit [280766] by jer.noble@apple.com
  • 5 edits in trunk

REGRESSION: http/tests/preload/onload_event.html is a flaky timeout on Big Sur wk1 Release
https://bugs.webkit.org/show_bug.cgi?id=227366
<rdar://problem/79733280>

Reviewed by Eric Carlson.

Source/WebCore:

Querying for any state on an AVAsset before its fully loaded will cause AVFoundation to block
on networking to fulfill the request, and in the case where WebKit handles loading, will eventually
dispatch to the main thread (which is blocked) in WebCore loader code, causing a deadlock.

Always guard queries to AVAsset with checks for the loaded status of the property being queried.
To make this easier, add a new safeAVAssetTracksForVisualMedia() method, similar to the existing
safeAVAssetTracksForAudibleMedia(), which checks the "tracks" property status and returns an empty
array if the tracks are not yet loaded.

Guard a few more methods by bailing early if the AVAsset is not fully loaded.

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

(WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged):
(WebCore::MediaPlayerPrivateAVFoundationObjC::updateRotationSession):
(WebCore::MediaPlayerPrivateAVFoundationObjC::paintWithVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::safeAVAssetTracksForVisualMedia):

LayoutTests:

  • platform/mac-wk1/TestExpectations:
1:43 PM Changeset in webkit [280765] by ysuzuki@apple.com
  • 3 edits in trunk/JSTests

[JSC] Clean up test262 expectations
https://bugs.webkit.org/show_bug.cgi?id=228903

Reviewed by Ross Kirsling.

  • test262/config.yaml:
  • test262/expectations.yaml:

Aug 7, 2021:

9:18 PM Changeset in webkit [280764] by ddkilzer@apple.com
  • 2 edits in trunk/Source/WebCore

UBSan: KeyboardScrollingAnimator.cpp:303:10: runtime error: load of value nnn, which is not a valid value for type 'bool'
<https://webkit.org/b/228901>

Reviewed by Tim Horton.

Covered by running 78 layout tests with UBSan enabled.

  • platform/KeyboardScrollingAnimator.h:
  • Initialize m_scrollTriggeringKeyIsPressed to false.
6:20 PM Changeset in webkit [280763] by aakash_jain@apple.com
  • 2 edits in trunk/Tools

[ews] Limit the size of error context buffer
https://bugs.webkit.org/show_bug.cgi?id=228900

Reviewed by Alexey Proskuryakov.

  • CISupport/ews-build/steps.py:

(BuildLogLineObserver.outLineReceived): Limit the lines for additional context to 50 lines.

3:47 PM Changeset in webkit [280762] by Wenson Hsieh
  • 7 edits
    2 adds in trunk

[macOS] Web process crashes when detaching Document with uncommitted marked text
https://bugs.webkit.org/show_bug.cgi?id=228841
rdar://79960890

Reviewed by Ryosuke Niwa.

Source/WebCore:

In the case where the document is in the process of being detached (underneath willBeRemovedFromFrame()), if
there is currently uncommitted marked text in the document, we will attempt to cancel the IME composition in the
process of clearing out the selection. On macOS, this calls into Editor::cancelComposition() which
subsequently triggers layout under various call stacks (DOM mutations, text event dispatch, and when scrolling
to reveal the selection); this triggers a security release assertion inside Document::updateLayout().

To mitigate this, we avoid calling into this codepath if the Document no longer has a living render tree (i.e.,
the render tree has either been destroyed, is being destroyed, or has not been created yet).

Test: editing/inserting/remove-frame-with-marked-text.html

  • editing/mac/EditorMac.mm:

(WebCore::Editor::selectionWillChange):

Source/WebKit:

Deploy a similar fix on iOS, to avoid any attempts to compute editor state due to discarding uncommitted marked
text during Document teardown. This is required in order to avoid the same security assertion when running the
new layout test on iOS.

  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::sendEditorStateUpdate):

Tools:

Make a small adjustment to DumpRenderTree, such that TextInputController targets the selected frame (or the main
frame, if there is no DOM selection). This behavior matches that of WebKitTestRunner, and allows layout tests
that use TextInputController to simulate setting marked text inside subframes.

  • DumpRenderTree/mac/TextInputControllerMac.m:

(-[TextInputController selectedOrMainFrame]):
(-[TextInputController textInput]):

LayoutTests:

Add a layout test to exercise the crash.

  • editing/inserting/remove-frame-with-marked-text-expected.txt: Added.
  • editing/inserting/remove-frame-with-marked-text.html: Added.
3:40 PM Changeset in webkit [280761] by commit-queue@webkit.org
  • 4 edits in trunk/Source/JavaScriptCore

Fix ODR violations in JSC
https://bugs.webkit.org/show_bug.cgi?id=228876

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-07
Reviewed by Yusuke Suzuki.

When built with LTO enabled, GCC will warn about violations of C++'s one-definition rule.
JSC currently has two violations. The first is JSC::SpeciesConstructResult, which has two
different declarations, one in ArrayPrototype.cpp and the other in
JSArrayBufferPrototype.cpp. I decided to change the version in ArrayPrototype.cpp to make
the declarations match.

The next problem is JSC::SignalContext. We have two different versions of this struct, one
in VMTraps.cpp and the other in SigillCrashAnalyzer.cpp. In this case, I decided to change
the one in VMTraps.cpp from JSC::SignalContext to JSC::VMTraps::SignalContext.

  • runtime/ArrayPrototype.cpp:
  • runtime/VMTraps.cpp:

(JSC::VMTraps::tryInstallTrapBreakpoints):

  • runtime/VMTraps.h:
2:38 PM Changeset in webkit [280760] by keith_miller@apple.com
  • 68 edits
    11 adds in trunk

for-in should only emit one loop in bytecode
https://bugs.webkit.org/show_bug.cgi?id=227989

Reviewed by Yusuke Suzuki.

JSTests:

  • microbenchmarks/for-in-double-array-with-own-named.js: Added.

(test):

  • microbenchmarks/for-in-double-array.js: Added.

(test):

  • microbenchmarks/for-in-getters.js: Added.

(test):

  • microbenchmarks/for-in-int32-array-with-own-named.js: Added.

(test):

  • microbenchmarks/for-in-int32-array.js: Added.

(test):

  • microbenchmarks/for-in-int32-object-with-own-named-and-getters.js: Added.

(test):

  • microbenchmarks/for-in-int32-object-with-own-named.js: Added.

(test):

  • microbenchmarks/for-in-object-with-own-named.js: Added.

(sum):
(opaqueSet):

  • microbenchmarks/for-in-string-array.js: Added.

(test):

  • microbenchmarks/for-of-iterate-array-map-set.js: Added.

(sum):
(let.generator):

  • stress/for-in-array-mode.js:

(test):

  • stress/for-in-base-reassigned-later.js:
  • stress/for-in-delete-during-iteration.js:
  • stress/for-in-primitive-index-on-prototype.js: Added.

(test):

  • stress/for-in-tests.js:
  • stress/has-own-property-structure-for-in-loop-correctness.js:

(test5):

Source/JavaScriptCore:

This patch redesigns how we implement for-in loops. Before this patch we would emit three copies of the for-in loop body. One for the indexed properties, one for the named-own properties, and one for generic properties (anything else). This had a couple of problems. Firstly, it meant bytecode size grew exponentially to number of nested for-in loops. This in turn meant DFG/FTL compilation took much longer.

Going off our experience with fast for-of, this patch turns for-in loops specializations into
a "fused" opcode that internally switches on the enumeration mode it currently sees. For example, if we are enumerating an own-named property, the new enumerator_get_by_val bytecode will check the enumerator cell's cached structure matches the base's then load the property offset directly.

There are four new opcodes this patch adds, which replace the various operations we had for the specialized loops previously. The new opcodes are EnumeratorGetByVal, EnumeratorInByVal, EnumeratorHasOwnProperty, and EnumeratorNext. The first three correspond to GetByVal, InByVal, and HasOwnProperty respectively. The EnumeratorNext opcode has three results in bytecode, the next enumeration value's mode, the index of the property name, and the property name string itself. When enumeration is done EnumeratorNext returns JS null as the property name string. Since the DFG doesn't support tuples yet this opcode is spilt into four new nodes. The first computes the updated index and mode for the next enumeration key, which is encoded into a single JS number. Then there are two nodes that extract the mode and index. Finally, the last new node produces the property name string or null based on the extracted mode and index.

Since, in most benchmarks, any given enumeration opcode tends to profile exactly one enumeration mode. This patch focuses primarily on reimplementing all the optimizations we have for any one specific mode. This means there are still potential optimizations for the multi-mode flavors of each new opcode.

The main optimizations implemented for each new opcode are:

EnumeratorNext:
1) IndexedMode loops are loaded and checked for presence inline (DFG/FTL).
2) NamedMode is computed inline as long as the cached structure on the enumerator cell matches the base (Baseline+). This can only differ if there's a transition.
3) property names are extracted from the cached buffer inline (Baseline+).

EnumeratorGetByVal:
EnumeratorInByVal:
EnumeratorHasOwnProperty:
1) IndexedMode has all the optimizations of a normal XByVal on indexed properties (DFG/FTL).
2) NamedMode will extract the value directly from the inline/out-of-line offset if the structure matches the enumerator's (Baseline+).

There are also a few interesting changes worth mentioning here:
1) If a for-in loop would produce an empty enumerator we now always
return the VMs empty enumerator. This has two benefits, most importantly, it distingishes between an unprofiled for-in loop and empty enumeration, which prevents OSR exit loops. Also, it means that the various Enumerator opcodes no longer need to handle undefined/null when toObjecting the base value.

2) The enumerator now contains a bit set of all the modes it will produce. This removes a few extra branches when speculating on the modes we will see in EnumeratorNext.

3) In the DFG, enumerator GetByVal relies on compileGetByVal to set the result it also passes a prefix callback which emits code after the various cases set up their operands but before code is emitting to help satisfy the branch over register allocation validation. Also, the array mode branch in compileGetByVal passes the data format that it would prefer, which for normal GetByVal is returned. For EnumeratorGetByVal, that preference is completely ignored and it always returns DataFormatJS.

  • assembler/MacroAssemblerARM64.h:

(JSC::MacroAssemblerARM64::or8):

  • assembler/MacroAssemblerX86Common.h:

(JSC::MacroAssemblerX86Common::or8):

  • assembler/MacroAssemblerX86_64.h:

(JSC::MacroAssemblerX86_64::rshift64):
(JSC::MacroAssemblerX86_64::or8): Deleted.

  • builtins/BuiltinNames.h:
  • bytecode/BytecodeList.rb:
  • bytecode/BytecodeUseDef.cpp:

(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):

  • bytecode/CodeBlock.cpp:

(JSC::CodeBlock::finishCreation):

  • bytecode/LinkTimeConstant.h:
  • bytecode/Opcode.h:
  • bytecompiler/BytecodeGenerator.cpp:

(JSC::BytecodeGenerator::recordHasOwnPropertyInForInLoop):
(JSC::BytecodeGenerator::emitInByVal):
(JSC::BytecodeGenerator::emitGetByVal):
(JSC::BytecodeGenerator::emitEnumeratorNext):
(JSC::BytecodeGenerator::emitEnumeratorHasOwnProperty):
(JSC::BytecodeGenerator::pushForInScope):
(JSC::BytecodeGenerator::popForInScope):
(JSC::rewriteOp):
(JSC::ForInContext::finalize):
(JSC::BytecodeGenerator::findForInContext):
(JSC::BytecodeGenerator::recordHasOwnStructurePropertyInForInLoop): Deleted.
(JSC::BytecodeGenerator::emitGetEnumerableLength): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableIndexedProperty): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableStructureProperty): Deleted.
(JSC::BytecodeGenerator::emitHasEnumerableProperty): Deleted.
(JSC::BytecodeGenerator::emitHasOwnStructureProperty): Deleted.
(JSC::BytecodeGenerator::emitEnumeratorStructurePropertyName): Deleted.
(JSC::BytecodeGenerator::emitEnumeratorGenericPropertyName): Deleted.
(JSC::BytecodeGenerator::emitToIndexString): Deleted.
(JSC::BytecodeGenerator::pushIndexedForInScope): Deleted.
(JSC::BytecodeGenerator::popIndexedForInScope): Deleted.
(JSC::BytecodeGenerator::pushStructureForInScope): Deleted.
(JSC::BytecodeGenerator::popStructureForInScope): Deleted.
(JSC::StructureForInContext::finalize): Deleted.
(JSC::IndexedForInContext::finalize): Deleted.
(JSC::BytecodeGenerator::findStructureForInContext): Deleted.

  • bytecompiler/BytecodeGenerator.h:

(JSC::ForInContext::isValid const):
(JSC::ForInContext::invalidate):
(JSC::ForInContext::local const):
(JSC::ForInContext::propertyName const):
(JSC::ForInContext::propertyOffset const):
(JSC::ForInContext::enumerator const):
(JSC::ForInContext::mode const):
(JSC::ForInContext::ForInContext):
(JSC::ForInContext::bodyBytecodeStartOffset const):
(JSC::ForInContext::type const): Deleted.
(JSC::ForInContext::isIndexedForInContext const): Deleted.
(JSC::ForInContext::isStructureForInContext const): Deleted.
(JSC::ForInContext::asIndexedForInContext): Deleted.
(JSC::ForInContext::asStructureForInContext): Deleted.
(JSC::StructureForInContext::StructureForInContext): Deleted.
(JSC::StructureForInContext::index const): Deleted.
(JSC::StructureForInContext::property const): Deleted.
(JSC::StructureForInContext::enumerator const): Deleted.
(JSC::StructureForInContext::baseVariable const): Deleted.
(JSC::StructureForInContext::addGetInst): Deleted.
(JSC::StructureForInContext::addInInst): Deleted.
(JSC::StructureForInContext::addHasOwnPropertyJump): Deleted.
(JSC::IndexedForInContext::IndexedForInContext): Deleted.
(JSC::IndexedForInContext::index const): Deleted.
(JSC::IndexedForInContext::addGetInst): Deleted.

  • bytecompiler/NodesCodegen.cpp:

(JSC::HasOwnPropertyFunctionCallDotNode::emitBytecode):
(JSC::ForInNode::emitBytecode):

  • dfg/DFGAbstractInterpreterInlines.h:

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

  • dfg/DFGArrayMode.h:

(JSC::DFG::ArrayMode::isSaneChain const):

  • dfg/DFGBackwardsPropagationPhase.cpp:

(JSC::DFG::BackwardsPropagationPhase::propagate):

  • dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::parseBlock):

  • dfg/DFGCFAPhase.cpp:

(JSC::DFG::CFAPhase::injectOSR):

  • dfg/DFGCapabilities.cpp:

(JSC::DFG::capabilityLevel):

  • dfg/DFGClobberize.h:

(JSC::DFG::clobberize):

  • dfg/DFGDoesGC.cpp:

(JSC::DFG::doesGC):

  • dfg/DFGFixupPhase.cpp:

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

  • dfg/DFGGraph.cpp:

(JSC::DFG::Graph::dump):

  • dfg/DFGIntegerRangeOptimizationPhase.cpp:
  • dfg/DFGMayExit.cpp:
  • dfg/DFGNode.h:

(JSC::DFG::Node::hasHeapPrediction):
(JSC::DFG::Node::hasStorageChild const):
(JSC::DFG::Node::storageChildIndex):
(JSC::DFG::Node::hasArrayMode):
(JSC::DFG::Node::hasEnumeratorMetadata const):
(JSC::DFG::Node::enumeratorMetadata):

  • dfg/DFGNodeType.h:
  • dfg/DFGOpInfo.h:

(JSC::DFG::OpInfo::OpInfo):

  • dfg/DFGOperations.cpp:

(JSC::DFG::JSC_DEFINE_JIT_OPERATION):

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

(JSC::DFG::SSALoweringPhase::handleNode):

  • dfg/DFGSafeToExecute.h:

(JSC::DFG::safeToExecute):

  • dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithString):
(JSC::DFG::SpeculativeJIT::compileGetByValForObjectWithSymbol):
(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdateIndexAndMode):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractIndex):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextExtractMode):
(JSC::DFG::SpeculativeJIT::compileEnumeratorNextUpdatePropertyName):
(JSC::DFG::SpeculativeJIT::compileEnumeratorGetByVal):
(JSC::DFG::SpeculativeJIT::compileEnumeratorHasProperty):
(JSC::DFG::SpeculativeJIT::compileEnumeratorInByVal):
(JSC::DFG::SpeculativeJIT::compileEnumeratorHasOwnProperty):
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
(JSC::DFG::SpeculativeJIT::compileGetEnumerableLength): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasEnumerableProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileToIndexString): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasEnumerableStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasOwnStructurePropertyImpl): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasOwnStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileInStructureProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetEnumeratorPname): Deleted.
(JSC::DFG::SpeculativeJIT::compileGetDirectPname): Deleted.

  • dfg/DFGSpeculativeJIT.h:

(JSC::DFG::SpeculativeJIT::allocate):
(JSC::DFG::JSValueOperand::regs):
(JSC::DFG::JSValueOperand::gpr):
(JSC::DFG::StorageOperand::StorageOperand):
(JSC::DFG::StorageOperand::~StorageOperand):
(JSC::DFG::StorageOperand::emplace):
(JSC::DFG::JSValueRegsTemporary::operator bool):
(JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):

  • dfg/DFGSpeculativeJIT32_64.cpp:

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

  • dfg/DFGSpeculativeJIT64.cpp:

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

  • dfg/DFGTypeCheckHoistingPhase.cpp:

(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):

  • ftl/FTLAbstractHeapRepository.h:
  • ftl/FTLCapabilities.cpp:

(JSC::FTL::canCompile):

  • ftl/FTLLowerDFGToB3.cpp:

(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByValImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAtImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):

  • ftl/FTLOutput.h:

(JSC::FTL::Output::phi):

  • generator/DSL.rb:
  • interpreter/Register.h:
  • interpreter/RegisterInlines.h:

(JSC::Register::operator=):

  • jit/AssemblyHelpers.h:
  • jit/JIT.cpp:

(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):

  • jit/JIT.h:
  • jit/JITOpcodes.cpp:

(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_structure_propertyImpl): Deleted.
(JSC::JIT::emit_op_has_enumerable_structure_property): Deleted.
(JSC::JIT::emit_op_has_own_structure_property): Deleted.
(JSC::JIT::emit_op_in_structure_property): Deleted.
(JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emit_op_get_direct_pname): Deleted.
(JSC::JIT::emit_op_enumerator_structure_pname): Deleted.
(JSC::JIT::emit_op_enumerator_generic_pname): Deleted.

  • jit/JITOpcodes32_64.cpp:

(JSC::JIT::privateCompileHasIndexedProperty):
(JSC::JIT::emit_op_has_structure_propertyImpl): Deleted.
(JSC::JIT::emit_op_has_enumerable_structure_property): Deleted.
(JSC::JIT::emit_op_has_own_structure_property): Deleted.
(JSC::JIT::emit_op_in_structure_property): Deleted.
(JSC::JIT::emit_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property): Deleted.
(JSC::JIT::emit_op_get_direct_pname): Deleted.
(JSC::JIT::emit_op_enumerator_structure_pname): Deleted.
(JSC::JIT::emit_op_enumerator_generic_pname): Deleted.

  • jit/JITPropertyAccess.cpp:

(JSC::JIT::generateGetByValSlowCase):
(JSC::JIT::emitSlow_op_get_by_val):
(JSC::JIT::emit_op_enumerator_next):
(JSC::JIT::emit_op_enumerator_get_by_val):
(JSC::JIT::emitSlow_op_enumerator_get_by_val):
(JSC::JIT::emit_enumerator_has_propertyImpl):
(JSC::JIT::emit_op_enumerator_in_by_val):
(JSC::JIT::emit_op_enumerator_has_own_property):

  • jit/JITPropertyAccess32_64.cpp:

(JSC::JIT::emit_op_enumerator_next):
(JSC::JIT::emit_op_enumerator_get_by_val):
(JSC::JIT::emitSlow_op_enumerator_get_by_val):
(JSC::JIT::emit_op_enumerator_in_by_val):
(JSC::JIT::emit_op_enumerator_has_own_property):

  • llint/LowLevelInterpreter.asm:
  • llint/LowLevelInterpreter64.asm:
  • runtime/CommonSlowPaths.cpp:

(JSC::JSC_DEFINE_COMMON_SLOW_PATH):

  • runtime/CommonSlowPaths.h:
  • runtime/FileBasedFuzzerAgent.cpp:

(JSC::FileBasedFuzzerAgent::getPredictionInternal):

  • runtime/FileBasedFuzzerAgentBase.cpp:

(JSC::FileBasedFuzzerAgentBase::opcodeAliasForLookupKey):

  • runtime/JSGlobalObject.cpp:

(JSC::JSGlobalObject::init):

  • runtime/JSPropertyNameEnumerator.cpp:

(JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
(JSC::JSPropertyNameEnumerator::computeNext):

  • runtime/JSPropertyNameEnumerator.h:

(JSC::propertyNameEnumerator):

  • runtime/PredictionFileCreatingFuzzerAgent.cpp:

(JSC::PredictionFileCreatingFuzzerAgent::getPredictionInternal):

1:55 PM Changeset in webkit [280759] by aakash_jain@apple.com
  • 3 edits in trunk/Tools

[ews] Ensure file handle is not leaked in loadConfig.py
https://bugs.webkit.org/show_bug.cgi?id=228866

Reviewed by Alexey Proskuryakov.

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

(loadBuilderConfig):

  • CISupport/ews-build/loadConfig.py:

(loadBuilderConfig):

11:50 AM Changeset in webkit [280758] by mmaxfield@apple.com
  • 36 edits
    6 copies in trunk/Source

Deduplicate logging channel algorithms
https://bugs.webkit.org/show_bug.cgi?id=228809

Reviewed by Fujii Hironori.

Source/WebCore:

No new tests because there is no behavior change.

  • Sources.txt:
  • WebCore.xcodeproj/project.pbxproj:
  • accessibility/AXLogger.cpp:
  • inspector/agents/page/PageConsoleAgent.cpp:
  • page/Page.cpp:
  • platform/LogInitialization.cpp: Copied from Source/WebCore/platform/LogInitialization.h.

(WebCore::logChannels):
(WebCore::getLogChannel):

  • platform/LogInitialization.h:
  • platform/Logging.cpp:

(WebCore::isLogChannelEnabled): Deleted.
(WebCore::setLogChannelToAccumulate): Deleted.
(WebCore::clearAllLogChannelsToAccumulate): Deleted.
(WebCore::initializeLogChannelsIfNecessary): Deleted.
(WebCore::getLogChannel): Deleted.

  • platform/Logging.h:
  • testing/js/WebCoreTestSupport.cpp:

(WebCoreTestSupport::setLogChannelToAccumulate):
(WebCoreTestSupport::clearAllLogChannelsToAccumulate):
(WebCoreTestSupport::initializeLogChannelsIfNecessary):

Source/WebKit:

  • GPUProcess/GPUConnectionToWebProcess.cpp:
  • GPUProcess/GPUProcess.cpp:

(WebKit::GPUProcess::initializeGPUProcess):

  • Platform/LogInitialization.cpp: Copied from Source/WebKit/Shared/WebKit2Initialize.cpp.

(WebKit::logChannels):
(WebKit::getLogChannel):

  • Platform/LogInitialization.h:
  • Platform/Logging.cpp:

(WebKit::initializeLogChannelsIfNecessary): Deleted.
(WebKit::getLogChannel): Deleted.

  • Platform/Logging.h:
  • Shared/AuxiliaryProcess.cpp:

(WebKit::AuxiliaryProcess::initialize):

  • Shared/WebKit2Initialize.cpp:

(WebKit::InitializeWebKit2):

  • Sources.txt:
  • UIProcess/WebPageProxy.cpp:
  • UIProcess/WebProcessPool.cpp:
  • WebKit.xcodeproj/project.pbxproj:
  • WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::platformInitializeWebProcess):

Source/WebKitLegacy:

  • WebKitLegacy.xcodeproj/project.pbxproj:

Source/WebKitLegacy/mac:

  • Misc/WebKitLogInitialization.h: Copied from Source/WebKit/Platform/LogInitialization.h.
  • Misc/WebKitLogInitialization.mm: Copied from Source/WebKitLegacy/mac/Misc/WebKitLogging.m.

(WebKit::logChannels):
(ReportDiscardedDelegateException):

  • Misc/WebKitLogging.h:
  • Misc/WebKitLogging.m:

(ReportDiscardedDelegateException): Deleted.

  • WebCoreSupport/WebDragClient.mm:
  • WebView/WebDelegateImplementationCaching.mm:
  • WebView/WebView.mm:

(-[WebView _commonInitializationWithFrameName:groupName:]):

Source/WTF:

The current infrastructure (before this patch) had the following duplicated for each framework:

  • A .cpp file declared the list of logging channels for that framework
  • The .cpp file also had algorithms to search, modify, and initialize these logging channels

Each framework's .cpp file had duplicate algorithms. (The initialization algorithm was even
duplicated 3 times!)

Because the algorithms directly name their specific list of logging channels, a naive deduplication
would have had to add new parameters to these algorithms to pass in the appropriate framework's
list. That's fine, but this is exactly the sort of thing classes were designed for - classes are
an association of algorithms and data. The algorithms are shared but the data isn't, which really
just means we should have 3 instances of a shared class - one for the 3 sets of data.

So, this patch creates the LogChannels class which contains the deduplicated algorithms, and each
framework has a NeverDestroyed singleton instance of that class. There is a single virtual method
in the class, so the appropriate "default write" variable can be queried for each framework.

The instances cannot be declared in the Logging.h files in the frameworks, because certain WebKit2
files want to initialize all 3 instances of LogChannels, but you can't #include multiple Logging.h
files at the same time because their LOG_CHANNEL_PREFIX #defines will collide with each other.
Luckily, LogInitialization.h files exist exactly to solve this purpose, so that's where the
LogChannels instances are declared in. After this change, the Logging.h files are just for the
declarations of the logging channels themselves, and the LogInitialization.h files are for the
LogChannels instances which contain the searching/modifying/initializing algorithms on the list of
logging channels. If you just want to LOG(...) something, #include the relevant Logging.h file, and
if you want to search/modify/initialize across the entire list of channels, then #include the
relevant LogInitialization.h file.

  • WTF.xcodeproj/project.pbxproj:
  • wtf/CMakeLists.txt:
  • wtf/LogChannels.cpp: Copied from Source/WebCore/platform/Logging.cpp.

(WTF::LogChannels::isLogChannelEnabled):
(WTF::LogChannels::setLogChannelToAccumulate):
(WTF::LogChannels::clearAllLogChannelsToAccumulate):
(WTF::LogChannels::initializeLogChannelsIfNecessary):
(WTF::LogChannels::getLogChannel):

  • wtf/LogChannels.h: Copied from Source/WebCore/platform/LogInitialization.h.
9:34 AM Changeset in webkit [280757] by commit-queue@webkit.org
  • 34 edits
    6 deletes in trunk/Source

Unreviewed, reverting r280756.
https://bugs.webkit.org/show_bug.cgi?id=228897

Broke gtk build

Reverted changeset:

"Deduplicate logging channel algorithms"
https://bugs.webkit.org/show_bug.cgi?id=228809
https://commits.webkit.org/r280756

12:54 AM Changeset in webkit [280756] by mmaxfield@apple.com
  • 34 edits
    6 copies in trunk/Source

Deduplicate logging channel algorithms
https://bugs.webkit.org/show_bug.cgi?id=228809

Reviewed by Fujii Hironori.

Source/WebCore:

No new tests because there is no behavior change.

  • Sources.txt:
  • WebCore.xcodeproj/project.pbxproj:
  • accessibility/AXLogger.cpp:
  • inspector/agents/page/PageConsoleAgent.cpp:
  • page/Page.cpp:
  • platform/LogInitialization.cpp: Copied from Source/WebCore/platform/LogInitialization.h.

(WebCore::logChannels):
(WebCore::getLogChannel):

  • platform/LogInitialization.h:
  • platform/Logging.cpp:

(WebCore::isLogChannelEnabled): Deleted.
(WebCore::setLogChannelToAccumulate): Deleted.
(WebCore::clearAllLogChannelsToAccumulate): Deleted.
(WebCore::initializeLogChannelsIfNecessary): Deleted.
(WebCore::getLogChannel): Deleted.

  • platform/Logging.h:
  • testing/js/WebCoreTestSupport.cpp:

(WebCoreTestSupport::setLogChannelToAccumulate):
(WebCoreTestSupport::clearAllLogChannelsToAccumulate):
(WebCoreTestSupport::initializeLogChannelsIfNecessary):

Source/WebKit:

  • GPUProcess/GPUConnectionToWebProcess.cpp:
  • GPUProcess/GPUProcess.cpp:

(WebKit::GPUProcess::initializeGPUProcess):

  • Platform/LogInitialization.cpp: Copied from Source/WebKit/Shared/WebKit2Initialize.cpp.

(WebKit::logChannels):
(WebKit::getLogChannel):

  • Platform/LogInitialization.h:
  • Platform/Logging.cpp:

(WebKit::initializeLogChannelsIfNecessary): Deleted.
(WebKit::getLogChannel): Deleted.

  • Platform/Logging.h:
  • Shared/AuxiliaryProcess.cpp:

(WebKit::AuxiliaryProcess::initialize):

  • Shared/WebKit2Initialize.cpp:

(WebKit::InitializeWebKit2):

  • Sources.txt:
  • UIProcess/WebPageProxy.cpp:
  • UIProcess/WebProcessPool.cpp:
  • WebKit.xcodeproj/project.pbxproj:
  • WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::WebProcess::platformInitializeWebProcess):

Source/WebKitLegacy:

  • WebKitLegacy.xcodeproj/project.pbxproj:

Source/WebKitLegacy/mac:

  • Misc/WebKitLogInitialization.h: Copied from Source/WebKit/Platform/LogInitialization.h.
  • Misc/WebKitLogInitialization.mm: Copied from Source/WebKitLegacy/mac/Misc/WebKitLogging.m.

(WebKit::logChannels):
(ReportDiscardedDelegateException):

  • Misc/WebKitLogging.h:
  • Misc/WebKitLogging.m:

(ReportDiscardedDelegateException): Deleted.

  • WebCoreSupport/WebDragClient.mm:
  • WebView/WebDelegateImplementationCaching.mm:
  • WebView/WebView.mm:

(-[WebView _commonInitializationWithFrameName:groupName:]):

Source/WTF:

The current infrastructure (before this patch) had the following duplicated for each framework:

  • A .cpp file declared the list of logging channels for that framework
  • The .cpp file also had algorithms to search, modify, and initialize these logging channels

Each framework's .cpp file had duplicate algorithms. (The initialization algorithm was even
duplicated 3 times!)

Because the algorithms directly name their specific list of logging channels, a naive deduplication
would have had to add new parameters to these algorithms to pass in the appropriate framework's
list. That's fine, but this is exactly the sort of thing classes were designed for - classes are
an association of algorithms and data. The algorithms are shared but the data isn't, which really
just means we should have 3 instances of a shared class - one for the 3 sets of data.

So, this patch creates the LogChannels class which contains the deduplicated algorithms, and each
framework has a NeverDestroyed singleton instance of that class. There is a single virtual method
in the class, so the appropriate "default write" variable can be queried for each framework.

The instances cannot be declared in the Logging.h files in the frameworks, because certain WebKit2
files want to initialize all 3 instances of LogChannels, but you can't #include multiple Logging.h
files at the same time because their LOG_CHANNEL_PREFIX #defines will collide with each other.
Luckily, LogInitialization.h files exist exactly to solve this purpose, so that's where the
LogChannels instances are declared in. After this change, the Logging.h files are just for the
declarations of the logging channels themselves, and the LogInitialization.h files are for the
LogChannels instances which contain the searching/modifying/initializing algorithms on the list of
logging channels. If you just want to LOG(...) something, #include the relevant Logging.h file, and
if you want to search/modify/initialize across the entire list of channels, then #include the
relevant LogInitialization.h file.

  • WTF.xcodeproj/project.pbxproj:
  • wtf/CMakeLists.txt:
  • wtf/LogChannels.cpp: Copied from Source/WebCore/platform/Logging.cpp.

(WTF::LogChannels::isLogChannelEnabled):
(WTF::LogChannels::setLogChannelToAccumulate):
(WTF::LogChannels::clearAllLogChannelsToAccumulate):
(WTF::LogChannels::initializeLogChannelsIfNecessary):
(WTF::LogChannels::getLogChannel):

  • wtf/LogChannels.h: Copied from Source/WebCore/platform/LogInitialization.h.

Aug 6, 2021:

11:30 PM Changeset in webkit [280755] by commit-queue@webkit.org
  • 1 edit
    2 adds in trunk/LayoutTests

[SOUP] test imported/w3c/web-platform-tests/html/cross-origin-opener-policy/header-parsing.https.html fails
https://bugs.webkit.org/show_bug.cgi?id=228851

Unreviewed test gardening. Add a GLIB-specific baseline for the
failing subtest

Patch by Arcady Goldmints-Orlov <Arcady Goldmints-Orlov> on 2021-08-06

  • platform/glib/imported/w3c/web-platform-tests/html/cross-origin-opener-policy/header-parsing.https-expected.txt: Added.
9:29 PM Changeset in webkit [280754] by Simon Fraser
  • 2 edits in trunk/Source/WebKit

Clarify some identifier naming in RemoteRenderingBackend
https://bugs.webkit.org/show_bug.cgi?id=228886

Reviewed by Said Abou-Hallawa.

Rename some "identifier" variables to differentiate between resource identifiers and
item buffer identifiers.

No behavior change.

  • GPUProcess/graphics/RemoteRenderingBackend.cpp:

(WebKit::RemoteRenderingBackend::createImageBuffer):
(WebKit::RemoteRenderingBackend::wakeUpAndApplyDisplayList):
(WebKit::RemoteRenderingBackend::cacheNativeImage):
(WebKit::RemoteRenderingBackend::cacheFont):
(WebKit::RemoteRenderingBackend::didCreateSharedDisplayListHandle):

9:29 PM Changeset in webkit [280753] by Simon Fraser
  • 2 edits in trunk/Source/WebKit

Page on mhlw.go.jp triggers WebContent termination by GPU process
https://bugs.webkit.org/show_bug.cgi?id=228885
<rdar://81603231>

Reviewed by Wenson Hsieh.

https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000164708_00001.html triggered an issue
where RemoteRenderingBackend::finalizeRenderingUpdate() would be called when the
GPU process had just processed a "switching to next item buffer" meta command,
but had not yet received the new item buffer. This triggered the
MESSAGE_CHECK(initialHandle, "Missing initial shared display list handle");
in RemoteRenderingBackend::wakeUpAndApplyDisplayList().

Protect against this by having finalizeRenderingUpdate() check that
arguments.itemBufferIdentifier had been received, which is similar to what happens
inside the loop in wakeUpAndApplyDisplayList() already.

Not easily testable.

  • GPUProcess/graphics/RemoteRenderingBackend.cpp:

(WebKit::RemoteRenderingBackend::finalizeRenderingUpdate):

7:04 PM Changeset in webkit [280752] by timothy_horton@apple.com
  • 2 edits in trunk/Source/WebKit

Disable WKHoverPlatter for now
https://bugs.webkit.org/show_bug.cgi?id=228880

Reviewed by Wenson Hsieh.

  • UIProcess/ios/WKHoverPlatterParameters.mm:

(-[WKHoverPlatterParameters setDefaultValues]):
Flip the switch.

6:39 PM Changeset in webkit [280751] by timothy_horton@apple.com
  • 2 edits in trunk/Source/WebKit

REGRESSION (r185111): Links to App Store doesn't work when opening a PDF in Safari on iOS and iPadOS
https://bugs.webkit.org/show_bug.cgi?id=228881
rdar://81294035

Reviewed by Andy Estes.

  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::navigateToPDFLinkWithSimulatedClick):
Clicking a link in PDF should absolutely be allowed to launch an external app.
Humorously, r185111 applied the correct value to PDFPlugin (macOS), but the
wrong value to WKPDFView (iOS). Bring them into alignment.

6:33 PM Changeset in webkit [280750] by Alan Coon
  • 8 edits in branches/safari-612.1.27.0-branch/Source

Versioning.

WebKit-7612.1.27.0.3

6:29 PM Changeset in webkit [280749] by Robert Jenner
  • 2 edits in trunk/LayoutTests

[ Monterey wk2 Release ] fast/scrolling/iframe-scrollable-after-back.html is a flaky timeout
https://bugs.webkit.org/show_bug.cgi?id=228200

Unreviewed test gardening. Remove no longer needed expectation.

  • platform/mac-wk2/TestExpectations:
6:18 PM Changeset in webkit [280748] by Robert Jenner
  • 2 edits in trunk/LayoutTests

[BigSur Release Wk2 Arm64] imported/w3c/web-platform-tests/navigation-timing/test_performance_attributes.sub.html is flaky failing
https://bugs.webkit.org/show_bug.cgi?id=224784
Unreviewed test gardening. Removing no longer needed expectation.

  • platform/mac-wk2/TestExpectations:
6:16 PM Changeset in webkit [280747] by Kate Cheney
  • 2 edits in trunk/Source/WebCore

CrashTracer: com.apple.WebKit.WebContent at com.apple.WebCore: WebCore::CryptoKeyRSA::exportJwk const
https://bugs.webkit.org/show_bug.cgi?id=228878
<rdar://problem/60147231>

Reviewed by Brent Fulgham.

exportData() could return nullptr. We should check the value of
rsaComponents before trying to use it.

  • crypto/keys/CryptoKeyRSA.cpp:

(WebCore::CryptoKeyRSA::exportJwk const):

5:57 PM Changeset in webkit [280746] by Robert Jenner
  • 2 edits in trunk/LayoutTests

[BigSur Wk2 Arm64] http/tests/privateClickMeasurement/store-private-click-measurement-with-source-nonce.html is flaky failing
https://bugs.webkit.org/show_bug.cgi?id=224783

Unreviewed test gardening. Removing no longer needed test expectation.

  • platform/mac-wk2/TestExpectations:
5:26 PM Changeset in webkit [280745] by ysuzuki@apple.com
  • 2 edits in trunk/Source/JavaScriptCore

Unreviewed, build fix on Debug build
https://bugs.webkit.org/show_bug.cgi?id=228810

  • yarr/YarrJIT.h:

(JSC::Yarr::BoyerMooreBitmap::addCharacters):
(JSC::Yarr::BoyerMooreBitmap::addRanges):

5:02 PM Changeset in webkit [280744] by ysuzuki@apple.com
  • 3 edits in trunk/Source/JavaScriptCore

[JSC] Yarr's character tracking for BoyerMoore search should be more precise
https://bugs.webkit.org/show_bug.cgi?id=228810

Reviewed by Saam Barati.

We should track up to 2 candidate characters without masking, so
that we can search a character without masking. To track candidates,
we introduce BoyerMooreCharacterCandidates.

We also add support for m_table because m_table can be used
for important CharacterClass like \s, and still that does not have
many character candidates if the mode is Char8.

To make \s work on Char8 case, we use Char8 / Char16 information
to filter characters that never appears in BoyreMoore search bitmap
construction.

  • yarr/YarrJIT.cpp:

(JSC::Yarr::BoyerMooreInfo::BoyerMooreInfo):
(JSC::Yarr::BoyerMooreInfo::set):
(JSC::Yarr::BoyerMooreInfo::addCharacters):
(JSC::Yarr::BoyerMooreInfo::addRanges):
(JSC::Yarr::BoyerMooreInfo::create):
(JSC::Yarr::BoyerMooreInfo::createCandidateBitmap const):

  • yarr/YarrJIT.h:

(JSC::Yarr::BoyerMooreCharacterCandidates::isValid const):
(JSC::Yarr::BoyerMooreCharacterCandidates::invalidate):
(JSC::Yarr::BoyerMooreCharacterCandidates::isEmpty const):
(JSC::Yarr::BoyerMooreCharacterCandidates::size const):
(JSC::Yarr::BoyerMooreCharacterCandidates::at const):
(JSC::Yarr::BoyerMooreCharacterCandidates::add):
(JSC::Yarr::BoyerMooreCharacterCandidates::merge):
(JSC::Yarr::BoyerMooreBitmap::characterCandidates const):
(JSC::Yarr::BoyerMooreBitmap::add):
(JSC::Yarr::BoyerMooreBitmap::addCharacters):
(JSC::Yarr::BoyerMooreBitmap::addRanges):
(JSC::Yarr::BoyerMooreBitmap::isMaskEffective const): Deleted.

4:21 PM Changeset in webkit [280743] by commit-queue@webkit.org
  • 2 edits in trunk/LayoutTests

[GTK] Remove some expectations for tests that don't fail anymore
https://bugs.webkit.org/show_bug.cgi?id=225644

Unreviewed test gardening.

Patch by Arcady Goldmints-Orlov <Arcady Goldmints-Orlov> on 2021-08-06

  • platform/gtk/TestExpectations:
4:14 PM Changeset in webkit [280742] by Alexander Mikhaylenko
  • 2 edits in trunk/Source/WebCore

REGRESSION(r279987): [GTK][WPE] It caused 2 new test failures
https://bugs.webkit.org/show_bug.cgi?id=228160

Reviewed by Michael Catanzaro.

Normally adjustText*() are only called for unstyled elements to adjust their platform
appearance, However, for entries we always call it since
https://bugs.webkit.org/show_bug.cgi?id=173572 and it causes problems.

That change was done for RenderThemeGtk and is not relevant anymore, so we can revert
it.

  • rendering/RenderTheme.cpp:

(WebCore::RenderTheme::adjustStyle):

4:11 PM Changeset in webkit [280741] by Robert Jenner
  • 2 edits in trunk/LayoutTests

[ Monterey Release wk2 arm64 ] platform/mac/fast/overflow/overflow-scrollbar-hit-test.html is a flaky crash
https://bugs.webkit.org/show_bug.cgi?id=228200

Unreviewed test gardening.

  • platform/mac-wk2/TestExpectations:
3:18 PM Changeset in webkit [280740] by Fujii Hironori
  • 3 edits
    2 adds in trunk

ASSERTION FAILED: !m_networkLoad in NetworkResourceLoader::~NetworkResourceLoader()
https://bugs.webkit.org/show_bug.cgi?id=228853

Reviewed by Alex Christensen.

Source/WebKit:

~NetworkResourceLoader() had the assertion ensuring m_networkLoad
was empty. But, this could fail in the following scenario. If a
'keepalive' fetch request is not finished and the page is
navigated away, its NetworkResourceLoader is transferred to the
NetworkSession by NetworkConnectionToWebProcess::transferKeptAliveLoad.
And, before the request is finished, if the NetworkSession is
destroyed, the kept alive NetworkResourceLoader is destroyed.

Test: http/tests/fetch/keepalive-fetch.html

  • NetworkProcess/NetworkSession.cpp:

(WebKit::NetworkSession::~NetworkSession): Abort m_keptAliveLoads.

LayoutTests:

  • http/tests/fetch/keepalive-fetch-expected.txt: Added.
  • http/tests/fetch/keepalive-fetch.html: Added.
3:16 PM Changeset in webkit [280739] by Jonathan Bedard
  • 11 edits
    2 adds in trunk/Tools

[git-webkit] Add setup function
https://bugs.webkit.org/show_bug.cgi?id=225985
<rdar://problem/78226729>

Reviewed by Dewei Zhu.

  • Scripts/libraries/webkitcorepy/setup.py: Bump version.
  • Scripts/libraries/webkitcorepy/webkitcorepy/init.py: Ditto.
  • Scripts/libraries/webkitcorepy/webkitcorepy/credentials.py:

(credentials): Key should be pulled from environment variable with key_name in it.

  • Scripts/libraries/webkitscmpy/setup.py: Bump version.
  • Scripts/libraries/webkitscmpy/webkitscmpy/init.py: Ditto.
  • Scripts/libraries/webkitscmpy/webkitscmpy/mocks/local/git.py:

(Git): Move config regexes.
(Git.init): Add git remote add, git config and git fetch fork.
(Git.config): Add user.email to default configuration.
(Git.edit_config): Modify configuration file.

  • Scripts/libraries/webkitscmpy/webkitscmpy/mocks/remote/git_hub.py:

(GitHub): Add list of forks.
(GitHub.enter): Correctly mock token.
(GitHub.request): Add fork check and fork addition.

  • Scripts/libraries/webkitscmpy/webkitscmpy/program/init.py:

(main): Add setup function.

  • Scripts/libraries/webkitscmpy/webkitscmpy/remote/git_hub.py:

(GitHub.credentials): Strip email domain, guide user on token permissions.

  • Scripts/libraries/webkitscmpy/webkitscmpy/program/setup.py: Added.

(Setup.github): Ensure that GitHub credentials are in the keychain.
(Setup.git): Set the user for the repository, along with merge strategy.
(Setup.parser):
(Setup.main):

  • Scripts/libraries/webkitscmpy/webkitscmpy/test/git_unittest.py:

(test_config): Change user name.
(test_global_config): Ditto.

  • Scripts/libraries/webkitscmpy/webkitscmpy/test/setup_unittest.py: Added.

(TestSetup):
(TestSetup.setUp):
(TestSetup.test_svn):
(TestSetup.test_github):
(TestSetup.test_git):
(TestSetup.test_github_checkout):

3:13 PM Changeset in webkit [280738] by commit-queue@webkit.org
  • 3 edits in trunk/PerformanceTests

MallocBench: fix ODR violation
https://bugs.webkit.org/show_bug.cgi?id=228874

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-06
Reviewed by Geoffrey Garen.

When built with LTO enabled, GCC will warn about violations of C++'s one-definition rule.
MallocBench has two different Objects in two different files, which is illegal. We could
rename one of them, but I decided it's simplest to just put them each in anonymous
namespaces in order to restrict them to file scope.

  • MallocBench/MallocBench/big.cpp:
  • MallocBench/MallocBench/stress.cpp:
3:09 PM Changeset in webkit [280737] by commit-queue@webkit.org
  • 2 edits in trunk/LayoutTests

[GTK] Mark some WPT CSS tests as still failing on GTK
https://bugs.webkit.org/show_bug.cgi?id=228871

These tests were fixed for most platforms in r279568 and r279698 but
still fail on GTK.
Unreviewed test gardening.

Patch by Arcady Goldmints-Orlov <Arcady Goldmints-Orlov> on 2021-08-06

  • platform/gtk/TestExpectations:
2:59 PM Changeset in webkit [280736] by Aditya Keerthi
  • 10 edits in trunk/Source/WebKit

[macOS] 3 second IPC deadlocks involving WebPageProxy::acceptsFirstMouse
https://bugs.webkit.org/show_bug.cgi?id=228834
rdar://75390908

Reviewed by Wenson Hsieh and Tim Horton.

Reports show 3 second hangs in WebPageProxy::acceptsFirstMouse, which is
the timeout for the sync IPC sent by the method. While this method has
always sent a sync IPC, logs show the WebProcess is also blocked on sync
IPC, under WebProcess::ensureGPUProcessConnection.

If a Web<->GPU process connection has not been established,
WebProcess::ensureGPUProcessConnection sends a sync IPC from the
WebProcess to the UIProcess to establish get the connection. However, to
get the connection, the UIProcess then sends an async IPC with a reply
block to the GPUProcess (see GPUProcessProxy::getGPUProcessConnection).
The WebProcess remains blocked until the UIProcess receives the reply
from the GPUProcess, and then sends a reply to the WebProcess.

Now, if a call to acceptsFirstMouse occurs in between the time the async
UIProcess -> GPUProcess IPC is sent, and the reply is received, we will
experience deadlock. The UIProcess will be blocked waiting on the
WebProcess' reply to acceptsFirstMouse, and the reply from the GPUProcess
will not be dispatched. Since the reply from the GPUProcess will not be
dispatched until the UIProcess is unblocked, the WebProcess will be
waiting under WebProcess:ensureGPUProcessConnection, and unable to reply
to acceptsFirstMouse.

A simple fix for the described scenario would be to introduce a
replySendOptions parameter to sendWithAsyncReply, so that the UIProcess
could be re-entered to dispatch the GPUProcess reply, even when waiting
for acceptsFirstMouse. However, this will not work in cases where the
GPUProcess is being launched, due to being blocked on the reply from
xpc_connection_send_message_with_reply in ProcessLauncherMac, which is
before the IPC::Connection has been established.

Since re-entering the UIProcess is not possible in this scenario, given
the existing architecture, the next simplest solution is to re-enter
the WebProcess on acceptsFirstMouse instead. Consequently, one part of
the fix involves sending the acceptsFirstMouse IPC with
IPC::SendOption::DispatchMessageEvenWhenWaitingForUnboundedSyncReply and
tagging WebProcess::getGPUProcessConnection as unbounded sync IPC.

Then, we must also consider the fact that, in the WebProcess,
acceptsFirstMouse performs hit-testing. Hit-testing triggers layout and
could cause script to run. Script could result in a GPUProcess connection
being established, eventually leading us down the path towards the
aforementioned deadlock. To avoid deadlock in this scenario, we need to
interrupt acceptsFirstMouse if a message to get the GPUProcess connection
is received. This is achieved by using waitForAndDispatchImmediately with
the InterruptWaitingIfSyncMessageArrives option, and splitting up
acceptsFirstMouse into two separate IPCs.

  • UIProcess/WebPageProxy.h:
  • UIProcess/WebPageProxy.messages.in:
  • UIProcess/ios/WebPageProxyIOS.mm:

Implementation not required for iOS.

  • UIProcess/mac/WebPageProxyMac.mm:

(WebKit::WebPageProxy::acceptsFirstMouse):

Send an async IPC with IPC::SendOption::DispatchMessageEvenWhenWaitingForUnboundedSyncReply
so that the WebProcess can be re-entered to resolve deadlock if
necessary. Then, use waitForAndDispatchImmediately to wait for the reply
(essentially making it a sync IPC), so that the wait can be interrupted
if another sync message, such as getGPUProcessConnection, is received.

(WebKit::WebPageProxy::handleAcceptsFirstMouse):

Store the result of the reply from the WebProcess.

  • WebProcess/WebPage/WebPage.h:
  • WebProcess/WebPage/WebPage.messages.in:

Split the sync IPC into two async IPCs, in order to support the use of
waitForAndDispatchImmediately.

  • WebProcess/WebPage/ios/WebPageIOS.mm:

Implementation not required for iOS.

  • WebProcess/WebPage/mac/WebPageMac.mm:

(WebKit::WebPage::requestAcceptsFirstMouse):

Exit early if re-entering the WebProcess, to avoid running script on
re-entry.

  • WebProcess/WebProcess.cpp:

(WebKit::WebProcess::getGPUProcessConnection):

Tag as unbounded sync IPC, so the WebProcess can be re-entered to
resolve deadlock.

2:45 PM Changeset in webkit [280735] by Russell Epstein
  • 1 copy in tags/Safari-612.1.27.0.2

Tag Safari-612.1.27.0.2.

1:24 PM Changeset in webkit [280734] by Fujii Hironori
  • 2 edits in trunk/Tools

[Win][WebKitTestRunner] WTR::PlatformWebView leaks m_view (WKViewRef)
https://bugs.webkit.org/show_bug.cgi?id=228857

Reviewed by Don Olmstead.

Windows WebKitTestRunner leaked a lot of object because it leaked
WebKit::WebView that retains WebKit::WebPageProxy.

  • WebKitTestRunner/win/PlatformWebViewWin.cpp:

(WTR::PlatformWebView::~PlatformWebView): Release m_view.

12:56 PM Changeset in webkit [280733] by Eric Hutchison
  • 2 edits in trunk/LayoutTests

Re-baselined imported/w3c/web-platform-tests/html/dom/idlharness.https.html.
https://bugs.webkit.org/show_bug.cgi?id=228751.

Unreviewed test gardening.

  • platform/ipad/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
12:06 PM Changeset in webkit [280732] by youenn@apple.com
  • 4 edits in trunk

[GPUP] Test WebKit2.CrashGPUProcessAfterApplyingConstraints fails when Media in GPU Process is enabled
https://bugs.webkit.org/show_bug.cgi?id=228759
<rdar://problem/81529641>

Reviewed by Geoffrey Garen.

Source/WebCore:

Revert part of https://trac.webkit.org/changeset/279940/webkit.

  • platform/mediastream/RealtimeVideoSource.cpp:

(WebCore::RealtimeVideoSource::sourceSettingsChanged):
Covered by API test.

Tools:

  • TestWebKitAPI/Tests/WebKit/GetUserMedia.mm:

Reenable test.

12:04 PM Changeset in webkit [280731] by youenn@apple.com
  • 15 edits in trunk/Source

WebKit::SampleBufferDisplayLayer needs to handle GPUProcess crash
https://bugs.webkit.org/show_bug.cgi?id=228824
<rdar://problem/81564477>

Reviewed by Eric Carlson.

Source/WebCore:

Manually tested.

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

(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::sampleBufferDisplayLayerStatusDidChange):
Recreate a new layer if the previous one failed.

Source/WebKit:

Make WebKit::SampleBufferDisplayLayer listen to GPUProcess connection being closed.
When that happens, notify its client that it failed.

  • WebProcess/GPU/GPUProcessConnection.cpp:
  • WebProcess/GPU/GPUProcessConnection.h:
  • WebProcess/GPU/media/RemoteMediaPlayerManager.cpp:
  • WebProcess/GPU/webrtc/SampleBufferDisplayLayer.cpp:

(WebKit::SampleBufferDisplayLayer::create):
(WebKit::SampleBufferDisplayLayer::SampleBufferDisplayLayer):
(WebKit::SampleBufferDisplayLayer::~SampleBufferDisplayLayer):
(WebKit::SampleBufferDisplayLayer::setDidFail):
(WebKit::SampleBufferDisplayLayer::gpuProcessConnectionDidClose):

  • WebProcess/GPU/webrtc/SampleBufferDisplayLayer.h:
  • WebProcess/GPU/webrtc/SampleBufferDisplayLayerManager.cpp:

(WebKit::SampleBufferDisplayLayerManager::createLayer):

  • WebProcess/GPU/webrtc/SampleBufferDisplayLayerManager.h:
12:02 PM Changeset in webkit [280730] by Alan Coon
  • 2 edits in branches/safari-612.1.27.0-branch/Source/WebKit

Cherry-pick r280722. rdar://problem/81618758

REGRESSION: ASSERTION FAILED: !DeprecatedGlobalSettings::shouldManageAudioSessionCategory()
AudioSession::sharedSession().category() == AudioSession::CategoryType::PlayAndRecord

https://bugs.webkit.org/show_bug.cgi?id=228847
<rdar://problem/81587101>

Reviewed by Jer Noble.

No new tests, fixes a crashing test.

  • UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp: (WebKit::UserMediaCaptureManagerProxy::SourceProxy::audioUnitWillStart): Restore.

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

11:24 AM Changeset in webkit [280729] by Russell Epstein
  • 1 copy in tags/Safari-612.1.26.1.4

Tag Safari-612.1.26.1.4.

11:19 AM Changeset in webkit [280728] by Russell Epstein
  • 8 edits in branches/safari-612.1.26.1-branch/Source

Versioning.

WebKit-7612.1.26.1.4

9:52 AM Changeset in webkit [280727] by Andres Gonzalez
  • 2 edits in trunk/Source/WebCore

Crash at WebKit::WebPage::requestTextRecognition caused by accessibility invocation.
https://bugs.webkit.org/show_bug.cgi?id=228864
rdar://80679512

Reviewed by Chris Fleizach.

  • accessibility/AXImage.cpp:

(WebCore::AXImage::imageOverlayElements):
It was calling requestTextRecognition with *element(), but element() can
return nullptr, which would lead to the crash.

9:38 AM Changeset in webkit [280726] by Peng Liu
  • 14 edits
    1 delete in trunk

[macOS] Clean up Feature Flags related code
https://bugs.webkit.org/show_bug.cgi?id=228803
<rdar://problem/81142982>

Reviewed by Tim Horton.

Source/WebKit:

On macOS, Safari Technology Preview or a local build WebKit/Safari will always
get the default preference values through the "Feature Flags" SPI. Unfortunately,
this approach won't work if the OS does not provide correct default preference values.

With this patch, we only get default preference values with the SPI for system
WebKit on macOS. For all other cases, we use hardcoded values. So that
WebKit will always get the correct default preference values.

This patch also fixes a few mistakes in two preferences: "webm_webaudio" and "vp8_decoder".

  • FeatureFlags/WebKit-appletvos.plist:
  • FeatureFlags/WebKit-ios.plist:
  • FeatureFlags/WebKit-macos.plist:
  • FeatureFlags/WebKit-watchos.plist:
  • Shared/Cocoa/WebPreferencesDefaultValuesCocoa.mm:

(WebKit::isFeatureFlagEnabled):

  • Shared/WebPreferencesDefaultValues.cpp:

(WebKit::isFeatureFlagEnabled):
(WebKit::defaultAsyncFrameAndOverflowScrollingEnabled):
(WebKit::defaultUseGPUProcessForCanvasRenderingEnabled):
(WebKit::defaultUseGPUProcessForDOMRenderingEnabled):
(WebKit::defaultUseGPUProcessForMediaEnabled):
(WebKit::defaultUseGPUProcessForWebGLEnabled):
(WebKit::defaultCaptureAudioInGPUProcessEnabled):
(WebKit::defaultCaptureVideoInGPUProcessEnabled):
(WebKit::defaultWebRTCCodecsInGPUProcess):
(WebKit::defaultIncrementalPDFEnabled):
(WebKit::defaultWebMFormatReaderEnabled):
(WebKit::defaultVP8DecoderEnabled):
(WebKit::defaultVP9DecoderEnabled):
(WebKit::defaultVP9SWDecoderEnabledOnBattery):
(WebKit::defaultWebMParserEnabled):
(WebKit::defaultWebMWebAudioEnabled):
(WebKit::defaultInAppBrowserPrivacy): Deleted.

  • Shared/WebPreferencesDefaultValues.h:
  • UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::creationParameters): Fix a typo.

Source/WebKitLegacy/mac:

On macOS, Safari Technology Preview or a local build WebKit/Safari will always
get the default preference values through the "Feature Flags" SPI. Unfortunately,
this approach won't work if the OS does not provide correct default preference values.

With this patch, we only get default preference values with the SPI for system
WebKit on macOS. For all other cases, we use hardcoded values. So that
WebKit will always get the correct default preference values.

This patch also fixes a few mistakes in two preferences: "webm_webaudio" and "vp8_decoder".

  • WebView/WebPreferencesDefaultValues.h:
  • WebView/WebPreferencesDefaultValues.mm:

(WebKit::isFeatureFlagEnabled):
(WebKit::defaultIncrementalPDFEnabled):
(WebKit::defaultWebXREnabled):
(WebKit::defaultWebMParserEnabled):
(WebKit::defaultWebMWebAudioEnabled):
(WebKit::defaultVP8DecoderEnabled):
(WebKit::defaultVP9DecoderEnabled):

LayoutTests:

Update a mac-bigsur specific test expectation file because the test is passing now.

  • platform/mac/imported/w3c/web-platform-tests/media-source/mediasource-addsourcebuffer-expected.txt: Removed.
  • platform/mac-bigsur/imported/w3c/web-platform-tests/media-source/mediasource-addsourcebuffer-expected.txt:
9:25 AM Changeset in webkit [280725] by aakash_jain@apple.com
  • 2 edits in trunk/Tools

[ews] Make config.json compact
https://bugs.webkit.org/show_bug.cgi?id=228862

Reviewed by Jonathan Bedard.

  • CISupport/ews-build/config.json:
9:03 AM Changeset in webkit [280724] by Russell Epstein
  • 9 edits in branches/safari-612.1.27.0-branch/Source

Cherry-pick r280702. rdar://problem/81618758

[iOS] getUserMedia sometimes doesn't capture from specified microphone
https://bugs.webkit.org/show_bug.cgi?id=228753
rdar://79704226

Reviewed by Youenn Fablet.

Source/WebCore:

The system will always choose the "default" audio input source unless
+[AVAudioSession setPreferredInput:error:] is called first, and that only works
if the audio session category has been set to PlayAndRecord *before* it is called,
so configure the audio session for recording before we choose and configure the
audio capture device.

Tested manually, this only reproduces on hardware.

  • platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::activeAudioSessionRequired const): Audio capture requires an active audio session. (WebCore::PlatformMediaSessionManager::removeSession): Move #if USE(AUDIO_SESSION) guard inside of maybeDeactivateAudioSession so it isn't spread throughout the file. (WebCore::PlatformMediaSessionManager::sessionWillBeginPlayback): Ditto. (WebCore::PlatformMediaSessionManager::processWillSuspend): Ditto. (WebCore::PlatformMediaSessionManager::processDidResume): Ditto. (WebCore::PlatformMediaSessionManager::sessionCanProduceAudioChanged): Add logging, call maybeActivateAudioSession() so we activate the audio session if necessary. (WebCore::PlatformMediaSessionManager::addAudioCaptureSource): Call updateSessionState instead of scheduleUpdateSessionState so the audio session category is updated immediately. (WebCore::PlatformMediaSessionManager::maybeDeactivateAudioSession): Move #if USE(AUDIO_SESSION) into the function so it doesn't need to be spread throughout the file. (WebCore::PlatformMediaSessionManager::maybeActivateAudioSession): Ditto.
  • platform/audio/PlatformMediaSessionManager.h: (WebCore::PlatformMediaSessionManager::isApplicationInBackground const):
  • platform/audio/ios/AudioSessionIOS.mm: (WebCore::AudioSessionIOS::setPreferredBufferSize): Log an error if we are unable to set the preferred buffer size.
  • platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.h:
  • platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm: (WebCore::AVAudioSessionCaptureDeviceManager::setPreferredAudioSessionDeviceUID): New, set the preferred input so capture will use select the device we want. (WebCore::AVAudioSessionCaptureDeviceManager::scheduleUpdateCaptureDevices): Remove m_recomputeDevices, setAudioCaptureDevices has been restructured so we don't need it. (WebCore::AVAudioSessionCaptureDeviceManager::computeCaptureDevices): Ditto. (WebCore::AVAudioSessionCaptureDeviceManager::setAudioCaptureDevices): Don't update the list of capture devices when the default device changes, only when a device is added, removed, enabled, or disabled.
  • platform/mediastream/mac/CoreAudioCaptureSource.cpp: (WebCore::CoreAudioSharedUnit::setCaptureDevice): Call setPreferredAudioSessionDeviceUID so the correct device is selected. (WebCore::CoreAudioSharedUnit::cleanupAudioUnit): Clear m_persistentID. (WebCore::CoreAudioCaptureSource::create): Return an error with a string, or the web process can detect a failure. (WebCore::CoreAudioCaptureSource::stopProducingData): Add logging.

Source/WebKit:

  • UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp: Re (WebKit::UserMediaCaptureManagerProxy::SourceProxy::audioUnitWillStart): Delete, we don't need it now that the web process configures the audio session before capture begins.

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

8:09 AM Changeset in webkit [280723] by jer.noble@apple.com
  • 7 edits in trunk/Source

[Cocoa] Remove support for AVAssetImageGenerator
https://bugs.webkit.org/show_bug.cgi?id=228560
<rdar://problem/81336280>

Reviewed by Eric Carlson.

Source/WebCore:

A much more minimal approach to removing support for AVAssetImageGenerator.

The only time we use an AVAssetImageGenerator (as opposed to an AVPlayerItemVideoOutput)
is when the latter does not currently have an available image enqueued. Because painting
is a synchronous operation, we use a synchronous API (the generator) to create an image
for that operation. However, this can create deadlocks if (for example) the resource needs
to load data on the main thread in order to complete the painting operation.

Instead, allow the main runloop to spin while waiting (up to 1_s) for the video output
to receive a decoded frame.

Drive-by fixes:

  • Don't create an AVPlayerLayer at AVPlayer-creation; this causes the AVPlayerItemVideoOutput to never receive a decoded frambe (as the layer is not in a CALayer-heirarchy).
  • preferredRenderingMode() shouldn't be "none" when the page isn't visible. We already just mark the layer as "hidden" in that case.
  • Don't tear down the AVPlayerItemVideoOutput when creating an AVPlayerLayer; it'll just get re-created anyway.
  • platform/graphics/avfoundation/MediaPlayerPrivateAVFoundation.cpp:

(WebCore::MediaPlayerPrivateAVFoundation::preferredRenderingMode const):
(WebCore::MediaPlayerPrivateAVFoundation::setUpVideoRendering):

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

(WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayer):
(WebCore::MediaPlayerPrivateAVFoundationObjC::paintCurrentFrameInContext):
(WebCore::MediaPlayerPrivateAVFoundationObjC::createVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::paintWithVideoOutput):
(WebCore::MediaPlayerPrivateAVFoundationObjC::waitForVideoOutputMediaDataWillChange):
(WebCore::MediaPlayerPrivateAVFoundationObjC::outputMediaDataWillChange):
(-[WebCoreAVFPullDelegate outputMediaDataWillChange:]):
(-[WebCoreAVFPullDelegate setParent:]):

Source/WebKit:

Drive-by fix: we're passing the wrong value into acceleratedRenderingStateChanged(), and
we're not setting the correct initial value on MediaPlayerPrivateRemote creation.

  • GPUProcess/media/RemoteMediaPlayerProxy.h:
  • WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:

(WebKit::MediaPlayerPrivateRemote::MediaPlayerPrivateRemote):
(WebKit::MediaPlayerPrivateRemote::acceleratedRenderingStateChanged):

8:04 AM Changeset in webkit [280722] by eric.carlson@apple.com
  • 2 edits in trunk/Source/WebKit
REGRESSION: ASSERTION FAILED: !DeprecatedGlobalSettings::shouldManageAudioSessionCategory()
AudioSession::sharedSession().category() == AudioSession::CategoryType::PlayAndRecord

https://bugs.webkit.org/show_bug.cgi?id=228847
<rdar://problem/81587101>

Reviewed by Jer Noble.

No new tests, fixes a crashing test.

  • UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp:

(WebKit::UserMediaCaptureManagerProxy::SourceProxy::audioUnitWillStart): Restore.

6:42 AM Changeset in webkit [280721] by Antti Koivisto
  • 8 edits
    2 adds in trunk

REGRESSION (r274038): Keyframe animation with top/left with percentages fails to animate
https://bugs.webkit.org/show_bug.cgi?id=228811
<rdar://problem/81568266>

Reviewed by Alan Bujtas.

LayoutTests/imported/w3c:

  • web-platform-tests/css/css-position/animations/bottom-composition-expected.txt:
  • web-platform-tests/css/css-position/animations/left-composition-expected.txt:
  • web-platform-tests/css/css-position/animations/right-composition-expected.txt:
  • web-platform-tests/css/css-position/animations/top-composition-expected.txt:

Source/WebCore:

r274038 ended up disabling interpolation of percent values for top/left/bottom/right.

Test: animations/top-left-percent-interpolation.html

  • animation/CSSPropertyAnimation.cpp:

(WebCore::CSSPropertyAnimationWrapperMap::CSSPropertyAnimationWrapperMap):

Enable them.

LayoutTests:

  • animations/top-left-percent-interpolation-expected.txt: Added.
  • animations/top-left-percent-interpolation.html: Added.
2:15 AM Changeset in webkit [280720] by youenn@apple.com
  • 12 edits
    2 adds in trunk

MediaPlayerPrivateMediaStreamAVFObjC should skip enqueuing frames when not visible
https://bugs.webkit.org/show_bug.cgi?id=228816
<rdar://81077972>

Reviewed by Eric Carlson.

Source/WebCore:

Do not create layers when not needed.
This prevents enqueuing frames in a AVSampleBufferDisplayLayer that will only buffer them, thus breaking camera capture/video decoding.
We do this by not calling ensureLayers when getting a new track. Instead we react upon player renderingCanBeAccelerated value.

It is also unnecessary and takes CPU cycles to enqueue frames when the video element is not visible.
HTMLMediaElement and RenderVideo thus pass to MediaPlayer a new flag telling whether the video element is visible in the view port.
MediaPlayerPrivateMediaStreamAVFObjC will then skip enqueueing frames if not needed.

Add getter and internals API to cover these changes.

Test: fast/mediastream/mediaPlayer-visibility.html

  • html/HTMLMediaElement.cpp:

(WebCore::HTMLMediaElement::isVisibleInViewportChanged):

  • platform/graphics/MediaPlayer.cpp:

(WebCore::MediaPlayer::loadWithNextMediaEngine):
(WebCore::MediaPlayer::setVisibleInViewport):

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

(WebCore::MediaPlayerPrivateInterface::setVisibleInViewport):

  • platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.h:
  • platform/graphics/avfoundation/objc/MediaPlayerPrivateMediaStreamAVFObjC.mm:

(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::enqueueVideoSample):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::setVisible):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::setVisibleInViewport):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::checkSelectedVideoTrack):
(WebCore::MediaPlayerPrivateMediaStreamAVFObjC::paintCurrentFrameInContext):

  • rendering/RenderVideo.cpp:

(WebCore::RenderVideo::updatePlayer):

  • testing/Internals.cpp:

(WebCore::Internals::isPlayerVisibleInViewport const):

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

LayoutTests:

  • fast/mediastream/mediaPlayer-visibility-expected.txt: Added.
  • fast/mediastream/mediaPlayer-visibility.html: Added.

Aug 5, 2021:

8:30 PM Changeset in webkit [280719] by Ryan Haddad
  • 2 edits in trunk/LayoutTests

Unreviewed test garening, skip test that is unsupported on WK1.

  • platform/win/TestExpectations:
8:10 PM Changeset in webkit [280718] by Cameron McCormack
  • 12 edits in trunk/Source

Stop tracking form elements with FormController
https://bugs.webkit.org/show_bug.cgi?id=228724
<rdar://problem/81435095>

Reviewed by Darin Adler.

Source/WebCore:

FormController currently tracks the insertion order of
HTMLFormElementWithState objects in the document. But we don't need
to know this list of form controls until the time we need to save
form state for the document (e.g. on pagehide). So we instead
traverse the document to find those elements at the point we need
them, rather than maintain FormController::m_formElementsWithState.

This is a small speedup (1-2%) on a few of the Speedometer subtests
that insert and remove many input elements.

A future optimization could record on the Document whether there are
any input elements that have had their value changed, since it's
probably common for pages with form controls to never be changed.

  • dom/Document.cpp:

(WebCore::Document::formElementsState const): Traverse the document to
find all the HTMLFormElementWithState objects.

  • dom/Element.h:

(WebCore::Element::isFormControlElementWithState const):

  • html/FormController.cpp:

(WebCore::FormController::createSavedFormStateMap):
(WebCore::FormController::formElementsState const):

  • html/FormController.h:
  • html/HTMLFormControlElementWithState.cpp:

(WebCore::HTMLFormControlElementWithState::insertedIntoAncestor):
Track the order that HTMLFormControlElementWithState objects are
inserted into the document.
(WebCore::HTMLFormControlElementWithState::removedFromAncestor):

  • html/HTMLFormControlElementWithState.h:

(WebCore::HTMLFormControlElementWithState::insertionIndex const):
(isType):

  • page/Frame.h: Remove unused formElementsCharacterCount.
  • page/ios/FrameIOS.mm:

Source/WebKitLegacy/mac:

formElementsCharacterCount is unused and can be removed.

  • WebView/WebFrame.mm:
  • WebView/WebFramePrivate.h:
7:39 PM Changeset in webkit [280717] by Diego Pino Garcia
  • 2 edits in trunk/Tools

[buildbot] Add new post-commit bot to build WPE on Ubuntu-LTS
https://bugs.webkit.org/show_bug.cgi?id=228535

Reviewed by Alexey Proskuryakov.

Currently we only had a bot to build WebKitGTK on Ubuntu LTS. This is
not enough to detect build regressions in WPE.

  • CISupport/build-webkit-org/config.json:
6:59 PM Changeset in webkit [280716] by commit-queue@webkit.org
  • 3 edits
    1 add in trunk

Assertion failure when checking array in DFG (32 bits)
https://bugs.webkit.org/show_bug.cgi?id=228839

Patch by Mikhail R. Gadelha <Mikhail R. Gadelha> on 2021-08-05
Reviewed by Yusuke Suzuki.

JSTests:

  • stress/check-array-empty-32.js: Added.

(a.b.catch.print.c):
(a.b):
(a.e):
(a):

Source/JavaScriptCore:

Since empty values don't pass the cell check in 32 bits, we need to
guard the SpecEmpty check to only happen in 64 bits archs

  • dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::checkArray):

6:56 PM Changeset in webkit [280715] by timothy_horton@apple.com
  • 9 edits
    1 delete in trunk

fast/canvas/canvas-crash.html doesn't test what it intends to on iOS
https://bugs.webkit.org/show_bug.cgi?id=228747

Reviewed by Simon Fraser.

Source/WebCore:

The test fast/canvas/canvas-crash.html intends to test changes made
to actual canvas code (see r215632); however, on the iOS simulator
the test doesn't even manage to make a canvas context because of
"maximum area" and "maximum backing store size" limits, which differ
per-platform. This results in unique test results for iOS, as well
as the test not actually exercising the code it was intended to.

Fix this by adding an override for the maximum area limit (we already
had one for maximum backing store size), and overriding them in
this test (and another similarly afflicted test).

  • html/HTMLCanvasElement.cpp:

(WebCore::maxCanvasArea):
(WebCore::HTMLCanvasElement::setMaxCanvasAreaForTesting):
(WebCore::HTMLCanvasElement::createImageBuffer const):

  • html/HTMLCanvasElement.h:
  • testing/Internals.cpp:

(WebCore::Internals::resetToConsistentState):
(WebCore::Internals::setMaxCanvasArea):

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

LayoutTests:

  • fast/canvas/canvas-crash.html:
  • fast/canvas/canvas-skia-excessive-size.html:
  • platform/ios-simulator/fast/canvas/canvas-crash-expected.txt: Removed.
  • platform/ios-simulator/fast/canvas/canvas-skia-excessive-size-expected.txt: Removed.

Delete the iOS-specific results, and adopt the new overrides in these two tests.

6:02 PM Changeset in webkit [280714] by Alan Coon
  • 1 copy in tags/Safari-612.1.27.3.1

Tag Safari-612.1.27.3.1.

6:01 PM Changeset in webkit [280713] by Ryan Haddad
  • 2 edits in trunk/Tools

REGRESSION (r279855): TestWebKitAPI.AppleLanguagesTest.UpdateAppleLanguages is failing
https://bugs.webkit.org/show_bug.cgi?id=228309

Unreviewed test gardening.

This test has been skipped on Apple Silicon because of timeouts, and
now it is a flaky failure on Intel machines. Disable it outright for
the time being.

  • TestWebKitAPI/Tests/WebKit/OverrideAppleLanguagesPreference.mm:

(TEST_F):

5:57 PM Changeset in webkit [280712] by Alan Coon
  • 2 edits in branches/safari-612.1.27.3-branch/Source/JavaScriptCore

Cherry-pick r280659. rdar://problem/81592180

[ARM64] Fix Zoom black screen during video meeting on Safari
https://bugs.webkit.org/show_bug.cgi?id=228776

Reviewed by Saam Barati.

The problem (rdar://81434487) reports that Zoom turns to a black screen during the video
meeting on Safari. The reproduction of this problem is verified and bisected to the previous patch
(https://bugs.webkit.org/show_bug.cgi?id=228057). Previously, we introduce a pattern
matching for instruction EON-with-shift on ARM64, where the pattern is d = n ((m ShiftType amount) -1).

x = m ShiftType amount
y = x -1
z = n
y

We check canBeInternal() on x but not on y based on the computing cost analysis in that patch,
which is totally wrong. If the pattern matching is triggered, then the compiler would not emit
the corresponding Air of x after lowering, leading to data corruption or system crash since y
depends on x.

In the real world example (Zoom video meeting), we find the B3 IR:

...
Int32 b@528 = SShr(b@526, $31(b@527), Wasm: {opcode: I32ShrS, location: 0x26b})
Int32 b@529 = BitXor(b@528, $-1(b@144), Wasm: {opcode: I32Xor, location: 0x26e})
...
Int32 b@551 = BitXor(b@446, b@529, Wasm: {opcode: I32Xor, location: 0x28e})
...

After Lowering to Air:

...
Not32 %fp, %x2, b@529
...
XorNotRightShift32 %tmp199, %tmp211, $31, %tmp209, b@551
...

Since the implementation of the previous patch does commitInternal() on b@528, the operand of
b@529 turns to a frame pointer. To resolve this problem, we should either check canBeInternal()
on both b@528 and b@529 or not at all.

  • b3/B3LowerToAir.cpp:

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

5:53 PM Changeset in webkit [280711] by commit-queue@webkit.org
  • 1 edit
    3 copies
    3 moves in trunk/LayoutTests

[GLIB] Unreviewed test gardening, move some expected results to GTK/WPE specific directories
https://bugs.webkit.org/show_bug.cgi?id=228844

Some expected results have diverged between GTK and WPE and need to be
moved to the more specific directories.

Patch by Arcady Goldmints-Orlov <Arcady Goldmints-Orlov> on 2021-08-05

  • platform/gtk/fast/selectors/unqualified-hover-strict-expected.txt: Copied from LayoutTests/platform/glib/fast/selectors/unqualified-hover-strict-expected.txt.
  • platform/gtk/media/video-playing-and-pause-expected.txt: Copied from LayoutTests/platform/glib/media/video-playing-and-pause-expected.txt.
  • platform/gtk/tables/mozilla/core/col_span-expected.txt: Copied from LayoutTests/platform/glib/tables/mozilla/core/col_span-expected.txt.
  • platform/wpe/fast/selectors/unqualified-hover-strict-expected.txt: Renamed from LayoutTests/platform/glib/fast/selectors/unqualified-hover-strict-expected.txt.
  • platform/wpe/media/video-playing-and-pause-expected.txt: Renamed from LayoutTests/platform/glib/media/video-playing-and-pause-expected.txt.
  • platform/wpe/tables/mozilla/core/col_span-expected.txt: Renamed from LayoutTests/platform/glib/tables/mozilla/core/col_span-expected.txt.
5:48 PM Changeset in webkit [280710] by Alan Coon
  • 8 edits in branches/safari-612.1.27.3-branch/Source

Versioning.

WebKit-7612.1.27.3.1

5:40 PM Changeset in webkit [280709] by Russell Epstein
  • 8 edits in branches/safari-612.1.27.0-branch/Source

Versioning.

WebKit-7612.1.27.0.2

5:23 PM Changeset in webkit [280708] by Chris Dumez
  • 2 edits in trunk/LayoutTests

REGRESSION (r280541): [ BigSur Debug ] accessibility/roles-computedRoleString.html is timing out
https://bugs.webkit.org/show_bug.cgi?id=228744
<rdar://problem/81472432>

Unreviewed, speed up test a bit as it is timing out flakily in Debug.

  • accessibility/roles-computedRoleString.html:
5:20 PM Changeset in webkit [280707] by Russell Epstein
  • 1 copy in tags/Safari-612.1.27.0.1

Tag Safari-612.1.27.0.1.

4:47 PM Changeset in webkit [280706] by Kate Cheney
  • 4 edits in trunk

LoadWebArchive.FailNavigation1 test is a false positive
https://bugs.webkit.org/show_bug.cgi?id=228848
<rdar://problem/81587448>

Reviewed by Brent Fulgham.

Source/WebKit:

Drive by logging fix.

  • UIProcess/WebProcessProxy.cpp:

(WebKit::WebProcessProxy::fetchWebsiteData):
(WebKit::WebProcessProxy::deleteWebsiteData):

Tools:

Update LoadWebArchive.FailNavigation1 to test the case of a webarchive
being loaded with a host for better test coverage.

  • TestWebKitAPI/Tests/mac/load-web-archive-1.html:
3:47 PM Changeset in webkit [280705] by Andres Gonzalez
  • 5 edits
    1 add in trunk

VoiceOver is not announcing the state as selected/unselected when an item is selected in a grid.
https://bugs.webkit.org/show_bug.cgi?id=228840
<rdar://78225826>

Reviewed by Chris Fleizach.

Source/WebCore:

Test: accessibility/selected-state-changed-notifications.html.

On iOS, a table/grid cell element is not exposed to AX clients. Instead
the content of the cell is. This patch ensures that if the cell element
is selected, the AX objects that represent the content inside the cell
will inherit the selected state from the cell.

  • accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:

(-[WebAccessibilityObjectWrapper _accessibilityTraitsFromAncestors]):

LayoutTests:

  • accessibility/selected-state-changed-notifications.html:
  • platform/ios/TestExpectations:
  • platform/ios/accessibility/selected-state-changed-notifications-expected.txt: Added.
3:39 PM Changeset in webkit [280704] by rmorisset@apple.com
  • 2 edits in trunk/Source/JavaScriptCore

REGRESSION (r280507): ASSERTION FAILED: !undominatedPhis.contains(value) in JSC::B3::(anonymous namespace)::Validater::validatePhisAreDominatedByUpsilons()
https://bugs.webkit.org/show_bug.cgi?id=228838
<rdar://problem/81579314>

Reviewed by Geoffrey Garen.

When I added validation of the dominance of Phis by their Upsilons, I checked two things:

  • There is no path from the entry point to a Phi without going through a corresponding Upsilon (the actual dominance check)
  • There is no way to execute a Phi twice without going through a corresponding Upsilon in between

The second property is not actually true in B3 IR, I had misunderstood that part of the meaning of Phis/Upsilons.
So this patch just removes this second check.

It has no security/stability/performance implication: this is validation code, which runs automatically in debug mode, but should not run at all on customer machines.

  • b3/B3Validate.cpp:
1:56 PM Changeset in webkit [280703] by ntim@apple.com
  • 34 edits
    4 adds in trunk

Implement support for <dialog> element cancel event
https://bugs.webkit.org/show_bug.cgi?id=227534

Reviewed by Chris Dumez.

This makes <dialog> emit a cancel event then close when the escape key is pressed.

Updated relevant WPT:

  • <dialog> cancel event WPTs: used send_keys instead of test_driver.Actions() (which are unsupported by WebKit test runner)
  • oncancel now is recognized

Failing WPT:

  • dialog-cancel-with-input.html: needs <dialog> focusing steps (webkit.org/b/227537) to be implemented for <input> to get focus
  • dialog-cancel-with-select.html: needs <dialog> focusing steps (webkit.org/b/227537) to be implemented for <select> to get focus
  • dialog-keydown-preventDefault.html: current implementation does not prevent canceling from happening when keydown event has preventDefault()

LayoutTests/imported/w3c:

  • web-platform-tests/html/browsers/the-window-object/security-window/window-security.https-expected.txt:
  • web-platform-tests/html/browsers/the-window-object/window-properties.https-expected.txt:
  • web-platform-tests/html/dom/idlharness.https-expected.txt:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-events-expected.txt:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-events.html:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-preventDefault-expected.txt:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-preventDefault.html:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-with-input-expected.txt:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-with-input.html:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-with-select.html:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-keydown-preventDefault-expected.txt:
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-keydown-preventDefault.html:
  • web-platform-tests/html/webappapis/scripting/events/event-handler-all-global-events-expected.txt:
  • web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-body-window-expected.txt:
  • web-platform-tests/html/webappapis/scripting/events/event-handler-attributes-windowless-body-expected.txt:
  • web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative-expected.txt:

Source/WebCore:

  • dom/GlobalEventHandlers.idl:
  • html/HTMLAttributeNames.in:
  • html/HTMLDialogElement.cpp:

(WebCore::HTMLDialogElement::cancel):

  • html/HTMLDialogElement.h:
  • html/HTMLElement.cpp:

(WebCore::HTMLElement::createEventHandlerNameMap):

  • page/EventHandler.cpp:

(WebCore::EventHandler::internalKeyEvent):

LayoutTests:

  • platform/glib/imported/w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative-expected.txt:
  • platform/gtk/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
  • platform/ios-wk2/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
  • platform/ios-wk2/imported/w3c/web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-events-expected.txt: Added.
  • platform/ios-wk2/imported/w3c/web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-preventDefault-expected.txt: Added.
  • platform/ios-wk2/imported/w3c/web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-with-input-expected.txt: Added.
  • platform/ios-wk2/imported/w3c/web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-keydown-preventDefault-expected.txt: Added.
  • platform/ios-wk2/imported/w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative-expected.txt:
  • platform/mac-wk1/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
  • platform/mac-wk1/imported/w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative-expected.txt:
  • platform/mac-wk2/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
  • platform/mac-wk2/imported/w3c/web-platform-tests/mathml/relations/html5-tree/math-global-event-handlers.tentative-expected.txt:
  • platform/wpe/imported/w3c/web-platform-tests/html/dom/idlharness.https-expected.txt:
12:29 PM Changeset in webkit [280702] by eric.carlson@apple.com
  • 9 edits in trunk/Source

[iOS] getUserMedia sometimes doesn't capture from specified microphone
https://bugs.webkit.org/show_bug.cgi?id=228753
rdar://79704226

Reviewed by Youenn Fablet.

Source/WebCore:

The system will always choose the "default" audio input source unless
+[AVAudioSession setPreferredInput:error:] is called first, and that only works
if the audio session category has been set to PlayAndRecord *before* it is called,
so configure the audio session for recording before we choose and configure the
audio capture device.

Tested manually, this only reproduces on hardware.

  • platform/audio/PlatformMediaSessionManager.cpp:

(WebCore::PlatformMediaSessionManager::activeAudioSessionRequired const): Audio
capture requires an active audio session.
(WebCore::PlatformMediaSessionManager::removeSession): Move #if USE(AUDIO_SESSION)
guard inside of maybeDeactivateAudioSession so it isn't spread throughout the file.
(WebCore::PlatformMediaSessionManager::sessionWillBeginPlayback): Ditto.
(WebCore::PlatformMediaSessionManager::processWillSuspend): Ditto.
(WebCore::PlatformMediaSessionManager::processDidResume): Ditto.
(WebCore::PlatformMediaSessionManager::sessionCanProduceAudioChanged): Add logging,
call maybeActivateAudioSession() so we activate the audio session if necessary.
(WebCore::PlatformMediaSessionManager::addAudioCaptureSource): Call updateSessionState
instead of scheduleUpdateSessionState so the audio session category is updated
immediately.
(WebCore::PlatformMediaSessionManager::maybeDeactivateAudioSession): Move
#if USE(AUDIO_SESSION) into the function so it doesn't need to be spread
throughout the file.
(WebCore::PlatformMediaSessionManager::maybeActivateAudioSession): Ditto.

  • platform/audio/PlatformMediaSessionManager.h:

(WebCore::PlatformMediaSessionManager::isApplicationInBackground const):

  • platform/audio/ios/AudioSessionIOS.mm:

(WebCore::AudioSessionIOS::setPreferredBufferSize): Log an error if we are unable
to set the preferred buffer size.

  • platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.h:
  • platform/mediastream/ios/AVAudioSessionCaptureDeviceManager.mm:

(WebCore::AVAudioSessionCaptureDeviceManager::setPreferredAudioSessionDeviceUID):
New, set the preferred input so capture will use select the device we want.
(WebCore::AVAudioSessionCaptureDeviceManager::scheduleUpdateCaptureDevices): Remove
m_recomputeDevices, setAudioCaptureDevices has been restructured so we don't need it.
(WebCore::AVAudioSessionCaptureDeviceManager::computeCaptureDevices): Ditto.
(WebCore::AVAudioSessionCaptureDeviceManager::setAudioCaptureDevices): Don't update
the list of capture devices when the default device changes, only when a device is
added, removed, enabled, or disabled.

  • platform/mediastream/mac/CoreAudioCaptureSource.cpp:

(WebCore::CoreAudioSharedUnit::setCaptureDevice): Call setPreferredAudioSessionDeviceUID
so the correct device is selected.
(WebCore::CoreAudioSharedUnit::cleanupAudioUnit): Clear m_persistentID.
(WebCore::CoreAudioCaptureSource::create): Return an error with a string, or the
web process can detect a failure.
(WebCore::CoreAudioCaptureSource::stopProducingData): Add logging.

Source/WebKit:

  • UIProcess/Cocoa/UserMediaCaptureManagerProxy.cpp: Re

(WebKit::UserMediaCaptureManagerProxy::SourceProxy::audioUnitWillStart): Delete,
we don't need it now that the web process configures the audio session before
capture begins.

11:30 AM Changeset in webkit [280701] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.0-branch/Source/JavaScriptCore

Cherry-pick r280659. rdar://problem/81569033

[ARM64] Fix Zoom black screen during video meeting on Safari
https://bugs.webkit.org/show_bug.cgi?id=228776

Reviewed by Saam Barati.

The problem (rdar://81434487) reports that Zoom turns to a black screen during the video
meeting on Safari. The reproduction of this problem is verified and bisected to the previous patch
(https://bugs.webkit.org/show_bug.cgi?id=228057). Previously, we introduce a pattern
matching for instruction EON-with-shift on ARM64, where the pattern is d = n ((m ShiftType amount) -1).

x = m ShiftType amount
y = x -1
z = n
y

We check canBeInternal() on x but not on y based on the computing cost analysis in that patch,
which is totally wrong. If the pattern matching is triggered, then the compiler would not emit
the corresponding Air of x after lowering, leading to data corruption or system crash since y
depends on x.

In the real world example (Zoom video meeting), we find the B3 IR:

...
Int32 b@528 = SShr(b@526, $31(b@527), Wasm: {opcode: I32ShrS, location: 0x26b})
Int32 b@529 = BitXor(b@528, $-1(b@144), Wasm: {opcode: I32Xor, location: 0x26e})
...
Int32 b@551 = BitXor(b@446, b@529, Wasm: {opcode: I32Xor, location: 0x28e})
...

After Lowering to Air:

...
Not32 %fp, %x2, b@529
...
XorNotRightShift32 %tmp199, %tmp211, $31, %tmp209, b@551
...

Since the implementation of the previous patch does commitInternal() on b@528, the operand of
b@529 turns to a frame pointer. To resolve this problem, we should either check canBeInternal()
on both b@528 and b@529 or not at all.

  • b3/B3LowerToAir.cpp:

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

11:03 AM Changeset in webkit [280700] by Alan Bujtas
  • 4 edits in trunk/Source/WebCore

Document::isLayoutTimerActive should read isLayoutPending
https://bugs.webkit.org/show_bug.cgi?id=228835

Reviewed by Antti Koivisto.

Callers of this function curious about whether there's a layout scheduled.

  • dom/Document.cpp:

(WebCore::Document::isLayoutPending const):
(WebCore::Document::isLayoutTimerActive const): Deleted.

  • dom/Document.h:
  • html/parser/HTMLParserScheduler.cpp:

(WebCore::HTMLParserScheduler::continueNextChunkTimerFired):

10:18 AM Changeset in webkit [280699] by youenn@apple.com
  • 2 edits in trunk/Source/WebKit

GPUProcessProxy should send tccd mach lookup sandbox extension
https://bugs.webkit.org/show_bug.cgi?id=228827

Reviewed by Per Arne Vollan.

In https://bugs.webkit.org/show_bug.cgi?id=225319, I mistakenly moved from mach lookup extension to generic extension.
Reverting that change.

  • UIProcess/GPU/GPUProcessProxy.cpp:

(WebKit::addTCCDSandboxExtension):

10:05 AM Changeset in webkit [280698] by eric.carlson@apple.com
  • 3 edits in trunk/Source/WebKit

[GPUP] RemoteAudioSessionProxyManager should use the shared audio session
https://bugs.webkit.org/show_bug.cgi?id=228795
<rdar://problem/81530450>

Reviewed by Jer Noble.

RemoteAudioSessionProxyManager creates and uses a private AudioSession, which means
that any code that moves from the WebProcess to the GPUProcess and uses
AudioSession::sharedSession will be using a separate platform audio session wrapper
object. RemoteAudioSessionProxyManager doesn't need a private AudioSession, so
change it to use AudioSession::sharedSession.

  • GPUProcess/media/RemoteAudioSessionProxyManager.cpp:

(WebKit::RemoteAudioSessionProxyManager::RemoteAudioSessionProxyManager): Don't
create a new AudioSession.
(WebKit::RemoteAudioSessionProxyManager::~RemoteAudioSessionProxyManager): Use
AudioSession::sharedSession().
(WebKit::RemoteAudioSessionProxyManager::updateCategory): Ditto.
(WebKit::RemoteAudioSessionProxyManager::setPreferredBufferSizeForProcess): Ditto.
(WebKit::RemoteAudioSessionProxyManager::tryToSetActiveForProcess): Ditto.

9:44 AM Changeset in webkit [280697] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebCore

Suppress more -Wreturn-type warnings
https://bugs.webkit.org/show_bug.cgi?id=228831

Unreviewed.

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-05

  • platform/KeyboardScrollingAnimator.cpp:

(WebCore::KeyboardScrollingAnimator::keyboardScrollForKeyboardEvent const):

9:27 AM Changeset in webkit [280696] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.0-branch/Source/WebKit

Cherry-pick r280652. rdar://problem/81568994

[GPUProcess] REGRESSION: A noticeable slow down when browsing Live Photos album on iCloud.com
https://bugs.webkit.org/show_bug.cgi?id=228673
<rdar://81353138>

Reviewed by Wenson Hsieh.

RemoteImageBufferProxy::flushDrawingContext() assumes a FlushContext item
is always appended to its DisplayList when it calls flushDrawingContextAsync()
and this is why it waits up to 3 seconds for the DidFlush message. But this
does not happen if the DisplayList of RemoteImageBufferProxy is empty.

In addition to checking whether the DisplayList is empty, we can check also
whether we do not have pending a FlushContext item before appending a new
one.

  • WebProcess/GPU/graphics/RemoteImageBufferProxy.h:

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

9:26 AM Changeset in webkit [280695] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.0-branch/Source/WebCore

Cherry-pick r280648. rdar://problem/81568979

REGRESSION(?): subtitle text sizing is sometimes inconsistent
https://bugs.webkit.org/show_bug.cgi?id=228786
<rdar://problem/80525509>

Reviewed by Eric Carlson.

Tested manually. I'm still not 100% sure of the root cause of this, but after talking with
some folks more familiar with WebKit's media "stack" it seems like this only happens with
in-band non-VTT subtitle tracks that have their own styling. The fix is also pretty obvious.

  • html/track/TextTrackCueGeneric.cpp: (WebCore::TextTrackCueGeneric::setFontSize): We should still pass along the new font size (and bool important) even if we don't have a display tree yet, as the font size (and bool important) are used when the display tree is created, meaning that we shouldn't have to wait for another setFontSize call after the display tree is created in order to update the font size.

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

9:26 AM Changeset in webkit [280694] by Russell Epstein
  • 3 edits in branches/safari-612.1.27.0-branch/Source/WebKit

Cherry-pick r280639. rdar://problem/81568951

[GPU Process] REGRESSION: iCloud Photos Web app may crash WebProcess once the GPUProcess is relaunched
https://bugs.webkit.org/show_bug.cgi?id=228665

Reviewed by Simon Fraser.

When the GPUProcess is relaunched, ensure NativeImage is detached from
the RemoteResourceCacheProxy once it is removed from its m_nativeImages.

Otherwise the NativeImage later will ask RemoteResourceCacheProxy to
release its corresponding NativeImage from RemoteResourceCache even
though it was destroyed when the GPUProcess was relaunched.

  • WebProcess/GPU/graphics/RemoteResourceCacheProxy.cpp: (WebKit::RemoteResourceCacheProxy::~RemoteResourceCacheProxy): (WebKit::RemoteResourceCacheProxy::clearNativeImageMap): (WebKit::RemoteResourceCacheProxy::remoteResourceCacheWasDestroyed):
  • WebProcess/GPU/graphics/RemoteResourceCacheProxy.h:

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

9:26 AM Changeset in webkit [280693] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.0-branch/Source/WebCore

Cherry-pick r280623. rdar://problem/81517664

Null check self.session after calling _cancel instead of before
https://bugs.webkit.org/show_bug.cgi?id=228757
<rdar://79224868>

Patch by Alex Christensen <achristensen@webkit.org> on 2021-08-03
Reviewed by Geoffrey Garen.

_cancel already null checks self.session before using it.
It seems to be setting self.session to null after the null check, so move the null check to before we use it.
This should fix an occasional crash during teardown.

  • platform/network/cocoa/WebCoreNSURLSession.mm: (-[WebCoreNSURLSessionDataTask _restart]):

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

9:26 AM Changeset in webkit [280692] by Russell Epstein
  • 2 edits in branches/safari-612.1.27.0-branch/Source/WebKit

Cherry-pick r280606. rdar://problem/81475582

[iOS] Fix sandbox violation in GPU process
https://bugs.webkit.org/show_bug.cgi?id=228743
<rdar://problem/81334849>

Reviewed by Brent Fulgham.

Allow reading "hw.product" in the GPU process' sandbox.

  • Resources/SandboxProfiles/ios/com.apple.WebKit.GPU.sb:

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

9:23 AM Changeset in webkit [280691] by Robert Jenner
  • 1 edit
    2 adds in trunk/LayoutTests

( Rebaseline) [ iOS ] fast/forms/ios/inputmode-none.html is a constant failure
https://bugs.webkit.org/show_bug.cgi?id=228200

Uneviewed test gardening.

  • platform/ios/fast/forms/ios/inputmode-none-expected.txt: Added.
9:03 AM Changeset in webkit [280690] by Wenson Hsieh
  • 3 edits in trunk/Source/WebKit

[macOS Monterey] Translate popover becomes detached from webpage after scrolling
https://bugs.webkit.org/show_bug.cgi?id=228807
rdar://81540115

Reviewed by Sam Weinig.

Close the context menu translation popover in WebViewImpl::dismissContentRelativeChildWindowsFromViewOnly
(along with all other content-relative UI) to prevent the popover from being detached from its translated text
upon scrolling or zooming.

  • UIProcess/Cocoa/WebViewImpl.h:
  • UIProcess/Cocoa/WebViewImpl.mm:

(WebKit::WebViewImpl::dismissContentRelativeChildWindowsFromViewOnly):
(WebKit::WebViewImpl::handleContextMenuTranslation):

Save a weak pointer to the current translation popover when we're about to present it, and use it to force the
popover to -close when dismissing content-relative child windows. Also take this opportunity to remove some
staging declarations on LTUITranslationViewController that have long since landed in the macOS 12 SDK.

8:27 AM Changeset in webkit [280689] by commit-queue@webkit.org
  • 16 edits in trunk

GCC 11 builds should use -Wno-array-bounds, -Wno-nonnull
https://bugs.webkit.org/show_bug.cgi?id=228601

Patch by Michael Catanzaro <Michael Catanzaro> on 2021-08-05
Reviewed by Carlos Garcia Campos.

.:

Prior to GCC 11, these were good warnings that could catch serious errors. But GCC 11 has
just become too sensitive and it's flagging what appear to be harmless cases, and not
providing enough feedback to know why. This has resulted in me littering our code with
pragmas to suppress GCC's false positives, and I think it's reached the point where it's
nicer to just turn off the warnings until such time that GCC gets this under control, and
rely on Clang instead in the meantime.

The GCC developers have indicated that these warnings will *always* produce false positives
in some circumstances, but with GCC 11 it's just too become too much IMO.

  • Source/cmake/WebKitCompilerFlags.cmake:

Source/JavaScriptCore:

  • b3/air/AirAllocateRegistersByGraphColoring.cpp:
  • jit/JITCall.cpp:

(JSC::JIT::compileOpCall):

Source/WebCore:

  • css/CSSValue.h:

(WebCore::CSSValue::deref):

  • css/StyleRule.h:

(WebCore::StyleRuleBase::deref const):

  • dom/Node.h:

(WebCore::Node::deref const):

Source/WebKit:

  • WebProcess/Plugins/PluginView.cpp:

(WebKit::PluginView::Stream::~Stream):

Source/WTF:

  • wtf/Bitmap.h:

(WTF::WordType>::clear):

  • wtf/Compiler.h:
  • wtf/Packed.h:

(WTF::PackedAlignedPtr::get const):

  • wtf/RefPtr.h:

(WTF::DefaultRefDerefTraits::derefIfNotNull):

8:26 AM Changeset in webkit [280688] by ntim@apple.com
  • 2 edits
    10 adds in trunk/LayoutTests/imported/w3c

Re-import html/semantics/interactive-elements/the-dialog-element WPT
https://bugs.webkit.org/show_bug.cgi?id=228822

Unreviewed.

Upstream commit: https://github.com/web-platform-tests/wpt/commit/1fa1d40a251a1a9e506caec3fdfba5fe2c7ef6f6

  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-events-expected.txt: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-events.html: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-preventDefault-expected.txt: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-preventDefault.html: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-with-input-expected.txt: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-with-input.html: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-with-select-expected.txt: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-cancel-with-select.html: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-keydown-preventDefault-expected.txt: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/dialog-keydown-preventDefault.html: Added.
  • web-platform-tests/html/semantics/interactive-elements/the-dialog-element/w3c-import.log:
8:14 AM Changeset in webkit [280687] by commit-queue@webkit.org
  • 3 edits in trunk/Source/JavaScriptCore

Use reinterpret_cast_ptr in KeywordLookupGenerator, PropertyMapHashTable
https://bugs.webkit.org/show_bug.cgi?id=228819

Patch by Zan Dobersek <zdobersek@igalia.com> on 2021-08-05
Reviewed by Adrian Perez de Castro.

Switch to using reinterpret_cast_ptr in KeywordLookupGenerator (which
generates the KeywordLookup.h header) and PropertyMapHashTable, reducing
a bit the GCC warning spewage when compiling for targets benefitting
from the reinterpret_cast_ptr workaround.

  • KeywordLookupGenerator.py:
  • runtime/PropertyMapHashTable.h:

(JSC::PropertyTable::table):
(JSC::PropertyTable::table const):

8:02 AM Changeset in webkit [280686] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebCore

Fix warning in HTTPParsers.parseStructuredFieldValue
https://bugs.webkit.org/show_bug.cgi?id=228815

Patch by Rob Buis <rbuis@igalia.com> on 2021-08-05
Reviewed by Sam Weinig.

UChar is unsigned, so it is not needed to check that it is
zewro or greater.

  • platform/network/HTTPParsers.cpp:

(WebCore::parseStructuredFieldValue):

7:34 AM Changeset in webkit [280685] by Adrian Perez de Castro
  • 2 edits in trunk/Tools/buildstream

[Flatpak SDK] Update libwpe to 1.11.1
https://bugs.webkit.org/show_bug.cgi?id=228793

Reviewed by Alejandro G. Castro.

  • elements/sdk/libwpe.bst: Bump to version 1.11.1, which includes the

new fullscreen API support.

7:13 AM Changeset in webkit [280684] by aboya@igalia.com
  • 2 edits in trunk/LayoutTests

Unreviewed GStreamer MSE microgardening
https://bugs.webkit.org/show_bug.cgi?id=228823

  • platform/glib/TestExpectations:
5:57 AM Changeset in webkit [280683] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WTF

Avoid reinterpret_cast alignment increase warnings with GCC on CPU(RISCV64)
https://bugs.webkit.org/show_bug.cgi?id=228818

Patch by Zan Dobersek <zdobersek@igalia.com> on 2021-08-05
Reviewed by Adrian Perez de Castro.

  • wtf/StdLibExtras.h: As with 32-bit ARM and MIPS targets, RISC-V 64-bit

builds with GCC also spawn warnings when the use of reinterpret_cast
causes an increase in alignment. Workaround via reinterpret_cast_ptr is
thus required for CPU(RISCV64).

5:25 AM Changeset in webkit [280682] by commit-queue@webkit.org
  • 2 edits in trunk/Tools

run-jsc-stress-tests: detect the riscv64 architecture
https://bugs.webkit.org/show_bug.cgi?id=228817

Patch by Zan Dobersek <zdobersek@igalia.com> on 2021-08-05
Reviewed by Adrian Perez de Castro.

  • Scripts/run-jsc-stress-tests: Detect the riscv64 architecture when

examining ELF binaries. For the moment, this architecture should be
marked as not supporting FTL.

12:40 AM Changeset in webkit [280681] by imanol
  • 6 edits in trunk/Source

Fix XR related clang warnings in WPE
https://bugs.webkit.org/show_bug.cgi?id=228779

Reviewed by Sam Weinig.

Fix a few compiler warnings.

Source/WebCore:

  • platform/xr/openxr/OpenXRInputSource.cpp:

(PlatformXR::OpenXRInputSource::getButton const):

  • platform/xr/openxr/OpenXRSwapchain.cpp:

(PlatformXR::OpenXRSwapchain::create):
(PlatformXR::OpenXRSwapchain::OpenXRSwapchain):
(PlatformXR::OpenXRSwapchain::acquireImage):

  • platform/xr/openxr/OpenXRSwapchain.h:

Source/WebKit:

  • Shared/XR/XRDeviceProxy.cpp:

(WebKit::XRDeviceProxy::views const):

Note: See TracTimeline for information about the timeline view.