Context Navigation

← Previous Period
Next Period →

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:

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.

Add ARM64 disassembler support ldp and stp for FP registers. This includes fixing A64DOpcodeLoadStoreRegisterPair::mask to not exclude the FP versions of the instructions.

Add ARM64Assembler query methods for determining if an immediate is encodable as the signed 12 bit immediate of ldp and stp instructions.

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.

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.

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.

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

Context Navigation

Timeline

Aug 9, 2021:

Aug 8, 2021:

Download in other formats: