Timeline



Jul 30, 2019:

10:18 PM Changeset in webkit [248030] by timothy_horton@apple.com
  • 2 edits in trunk/Tools

Remove some needless comments that snuck into the tree

  • TestRunnerShared/UIScriptContext/UIScriptController.h:

(WTR::UIScriptController::setHardwareKeyboardAttached):
(WTR::UIScriptController::playBackEventStream):

10:13 PM Changeset in webkit [248029] by Fujii Hironori
  • 12 edits
    2 adds in trunk

[WebKit] Add PageLoadState::Observer C API
https://bugs.webkit.org/show_bug.cgi?id=199848

Reviewed by Alex Christensen.

Source/WebKit:

There is no WebKit C API to get the timing of title changed since
WKPageLoaderClientV0::didReceiveTitleForFrame has been removed in
r235398. Cocoa and glib WebKit API exist.

  • PlatformWin.cmake:
  • UIProcess/API/C/WKPage.cpp:

(WKPageSetPageStateClient):

  • UIProcess/API/C/WKPage.h: Added WKPageSetPageStateClient.
  • UIProcess/API/C/WKPageStateClient.h: Added.
  • UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::setPageLoadStateObserver):

  • UIProcess/WebPageProxy.h:
  • WebKit.xcodeproj/project.pbxproj:

Tools:

  • MiniBrowser/win/WebKitBrowserWindow.cpp:

(WebKitBrowserWindow::WebKitBrowserWindow):
(WebKitBrowserWindow::didChangeTitle):
(WebKitBrowserWindow::didFinishNavigation): Deleted.

  • MiniBrowser/win/WebKitBrowserWindow.h:
  • TestWebKitAPI/CMakeLists.txt:
  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WebKit/PageLoadState.cpp: Added.

(TestWebKitAPI::PageLoadTestState::PageLoadTestState):
(TestWebKitAPI::didChangeActiveURL):
(TestWebKitAPI::didChangeCanGoBack):
(TestWebKitAPI::didChangeCanGoForward):
(TestWebKitAPI::didChangeCertificateInfo):
(TestWebKitAPI::didChangeEstimatedProgress):
(TestWebKitAPI::didChangeHasOnlySecureContent):
(TestWebKitAPI::didChangeIsLoading):
(TestWebKitAPI::didChangeNetworkRequestsInProgress):
(TestWebKitAPI::didChangeTitle):
(TestWebKitAPI::didChangeWebProcessIsResponsive):
(TestWebKitAPI::didSwapWebProcesses):
(TestWebKitAPI::willChangeActiveURL):
(TestWebKitAPI::willChangeCanGoBack):
(TestWebKitAPI::willChangeCanGoForward):
(TestWebKitAPI::willChangeCertificateInfo):
(TestWebKitAPI::willChangeEstimatedProgress):
(TestWebKitAPI::willChangeHasOnlySecureContent):
(TestWebKitAPI::willChangeIsLoading):
(TestWebKitAPI::willChangeNetworkRequestsInProgress):
(TestWebKitAPI::willChangeTitle):
(TestWebKitAPI::willChangeWebProcessIsResponsive):
(TestWebKitAPI::didFinishNavigation):
(TestWebKitAPI::TEST):

10:01 PM Changeset in webkit [248028] by timothy_horton@apple.com
  • 2 edits in trunk/Source/WebCore

ASSERTion failure under takeSnapshot after r247846

  • page/TextIndicator.cpp:

(WebCore::takeSnapshots):
We now sometimes inflate the scale factor; allow this.

6:35 PM Changeset in webkit [248027] by ysuzuki@apple.com
  • 11 edits in trunk/Source/JavaScriptCore

[JSC] Emit write barrier after storing instead of before storing
https://bugs.webkit.org/show_bug.cgi?id=200193

Reviewed by Saam Barati.

I reviewed tricky GC-related code including visitChildren and manual writeBarrier, and I found that we have several problems with write-barriers.

  1. Some write-barriers are emitted before stores happen

Some code like LazyProperty emits write-barrier before we store the value. This is wrong since JSC has concurrent collector. Let's consider the situation like this.

  1. Cell "A" is not marked yet
  2. Write-barrier is emitted onto "A"
  3. Concurrent collector scans "A"
  4. Store to "A"'s field happens
  5. (4)'s field is not rescaned

We should emit write-barrier after stores. This patch places write-barriers after stores happen.

  1. Should emit write-barrier after the stored fields are reachable from the owner.

We have code that is logically the same to the following.

`
auto data = std::make_unique<XXX>();
data->m_field.set(vm, owner, value);

storeStoreBarrier();
owner->m_data = WTFMove(data);
`

This is not correct. When write-barrier is emitted, the owner cannot reach to the field that is stored.
The actual example is AccessCase. We are emitting write-barriers with owner when creating AccessCase, but this is not
effective until this AccessCase is chained to StructureStubInfo, which is reachable from CodeBlock.

I don't think this is actually an issue because currently AccessCase generation is guarded by CodeBlock->m_lock. And CodeBlock::visitChildren takes this lock.
But emitting a write-barrier at the right place is still better. This patch places write-barriers when StructureStubInfo::addAccessCase is called.

Speculative GC fix, it was hard to reproduce the crash since we need to control concurrent collector and main thread's scheduling in an instruction-level.

  • bytecode/BytecodeList.rb:
  • bytecode/CodeBlock.cpp:

(JSC::CodeBlock::finishCreation):

  • bytecode/StructureStubInfo.cpp:

(JSC::StructureStubInfo::addAccessCase):

  • bytecode/StructureStubInfo.h:

(JSC::StructureStubInfo::considerCaching):

  • dfg/DFGPlan.cpp:

(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):

  • jit/JITOperations.cpp:
  • llint/LLIntSlowPaths.cpp:

(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::setupGetByIdPrototypeCache):

  • runtime/CommonSlowPaths.cpp:

(JSC::SLOW_PATH_DECL):

  • runtime/LazyPropertyInlines.h:

(JSC::ElementType>::setMayBeNull):

  • runtime/RegExpCachedResult.h:

(JSC::RegExpCachedResult::record):

6:22 PM Changeset in webkit [248026] by ysuzuki@apple.com
  • 4 edits
    1 add in trunk

[JSC] Make StructureChain less-tricky by using Auxiliary Buffer
https://bugs.webkit.org/show_bug.cgi?id=200192

Reviewed by Saam Barati.

JSTests:

  • stress/structure-chain-stress.js: Added.

(keys):

Source/JavaScriptCore:

StructureChain has a bit tricky write barrier / mutator fence to use UniqueArray for its underlying storage.
But, since the size of StructureChain is fixed at initialization, we should allocate an underlying storage from auxiliary memory and
set it in its constructor instead of finishCreation. We can store values in the finishCreation so that we do not need to have
a hacky write-barrier and mutator fence. Furthermore, we can make StructureChain non-destructible.

This patch leverages auxiliary buffer for the implementation of StructureChain. And it also adds a test that stresses StructureChain creation.

  • runtime/StructureChain.cpp:

(JSC::StructureChain::StructureChain):
(JSC::StructureChain::create):
(JSC::StructureChain::finishCreation):
(JSC::StructureChain::visitChildren):
(JSC::StructureChain::destroy): Deleted.

  • runtime/StructureChain.h:
5:31 PM Changeset in webkit [248025] by sbarati@apple.com
  • 2 edits in trunk/Source/WebCore

[WHLSL] Add a fast path for TypeNamer::insert where we've already seen the type
https://bugs.webkit.org/show_bug.cgi?id=200284

Reviewed by Myles C. Maxfield.

This is a ~27% speedup in the WHLSL::prepare for the compute_boids test.
This optimization makes sense since my previous patch to make UnnamedType
ref counted was also a huge speedup. So the TypeNamer is seeing many
UnnamedTypes which are the same pointer value. On compute_boids, this
makes generateMetalCode ~40ms faster.

  • Modules/webgpu/WHLSL/Metal/WHLSLTypeNamer.cpp:

(WebCore::WHLSL::Metal::TypeNamer::insert):

4:52 PM Changeset in webkit [248024] by rniwa@webkit.org
  • 2 edits in trunk/Source/WebCore

WorkerGlobalScope::wrapCryptoKey/unwrapCryptoKey should use local heap objects for replies
https://bugs.webkit.org/show_bug.cgi?id=200179
<rdar://problem/52334658>

Reviewed by Brent Fulgham.

Based on the patch by Jiewen Tan.

WorkerGlobalScope::wrapCryptoKey and WorkerGlobalScope::unwrapCryptoKey had a bug that they could exit
the function before the main thread had finished writing to the result vector passed in to these functions
when the worker's runloop receives MessageQueueTerminated before the main thread finishes writing.

Fixed the bug by creating a new temporary Vector inside a ThreadSafeRefCounted object shared between
the main thread and the worker thread, which extends the lifetime of the Vector until when the worker thread
receives the result or when the main thread finishes writing to the Vector, whichever happens last.

Unfortunately no new tests since there is no reproducible test case, and this crash is highly racy.

  • workers/WorkerGlobalScope.cpp:

(WebCore::CryptoBufferContainer): Added.
(WebCore::CryptoBufferContainer::create): Added.
(WebCore::CryptoBufferContainer::buffer): Added.
(WebCore::WorkerGlobalScope::wrapCryptoKey):
(WebCore::WorkerGlobalScope::unwrapCryptoKey):

4:46 PM Changeset in webkit [248023] by Alan Coon
  • 1 copy in tags/Safari-608.2.1

Tag Safari-608.2.1.

4:42 PM Changeset in webkit [248022] by sbarati@apple.com
  • 3 edits
    2 adds in trunk

[WHLSL] Checker sets wrong type for property access instruction with an ander
https://bugs.webkit.org/show_bug.cgi?id=200282

Reviewed by Myles C. Maxfield.

Source/WebCore:

We were assigning resulting type based on the base value instead of the ander
of the base value. For example, consider:
`
struct Point { float x; float y; }
compute main(device Point[] buffer) { buffer[0]; }
`

The local variable "buffer" is in the "thread" address space. So we would end up
trying to use the thread address space for "buffer[0]". This caused us to
generate invalid Metal code because we would call a "thread" ander with a
"device" pointer. The fix is to use the "device" address space, which is
the type of the ander we were already setting on this property access instruction.

Test: webgpu/whlsl/device-proper-type-checker.html

  • Modules/webgpu/WHLSL/WHLSLChecker.cpp:

(WebCore::WHLSL::Checker::finishVisiting):

LayoutTests:

  • webgpu/whlsl/device-proper-type-checker-expected.txt: Added.
  • webgpu/whlsl/device-proper-type-checker.html: Added.
4:41 PM Changeset in webkit [248021] by sbarati@apple.com
  • 8 edits in trunk/Source/WebCore

[WHLSL] Make ASTDumper dump types and address spaces
https://bugs.webkit.org/show_bug.cgi?id=200281

Reviewed by Robin Morisset.

This makes it much easier to gain insight into what type resolution
the checker does. I used this logging to debug https://bugs.webkit.org/show_bug.cgi?id=200282

  • Modules/webgpu/WHLSL/AST/WHLSLAddressSpace.h:

(WebCore::WHLSL::AST::TypeAnnotation::isAbstractLeftValue const):

  • Modules/webgpu/WHLSL/AST/WHLSLArrayReferenceType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLArrayType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLPointerType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLTypeReference.h:
  • Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.h:
  • Modules/webgpu/WHLSL/WHLSLASTDumper.cpp:

(WebCore::WHLSL::ASTDumper::visit):

3:36 PM Changeset in webkit [248020] by Brent Fulgham
  • 22 edits
    3 copies
    8 adds in trunk/Source/WebCore

[FTW] Refactor Direct2D code to follow Cairo's model to support modern WebKit
https://bugs.webkit.org/show_bug.cgi?id=200270

Reviewed by Dean Jackson.

Refactor the Direct2D code in WebCore so that the core routines can be shared
between GraphicsContext and GraphicsContextImpl. Implement PlatformContext,
BackingStoreBackend, and GraphicsContextImpl for the Direct2D engine.

This patch effectively just moves code around.

  • PlatformFTW.cmake:
  • platform/graphics/GraphicsContext.h:
  • platform/graphics/GraphicsContextImpl.h:
  • platform/graphics/ImageSource.cpp:
  • platform/graphics/Pattern.h:
  • platform/graphics/displaylists/DisplayListRecorder.cpp:
  • platform/graphics/displaylists/DisplayListRecorder.h:
  • platform/graphics/win/BackingStoreBackendDirect2D.h: Added.
  • platform/graphics/win/BackingStoreBackendDirect2DImpl.cpp: Added.
  • platform/graphics/win/BackingStoreBackendDirect2DImpl.h: Added.
  • platform/graphics/win/Direct2DOperations.cpp: Added.
  • platform/graphics/win/Direct2DOperations.h: Added.
  • platform/graphics/win/Direct2DUtilities.cpp: Added.
  • platform/graphics/win/Direct2DUtilities.h: Added.
  • platform/graphics/win/FontCascadeDirect2D.cpp:
  • platform/graphics/win/GradientDirect2D.cpp:
  • platform/graphics/win/GraphicsContextDirect2D.cpp:
  • platform/graphics/win/GraphicsContextImplDirect2D.cpp: Added.
  • platform/graphics/win/GraphicsContextImplDirect2D.h: Added.
  • platform/graphics/win/GraphicsContextPlatformPrivateDirect2D.h:
  • platform/graphics/win/ImageBufferDataDirect2D.h:
  • platform/graphics/win/ImageBufferDirect2D.cpp:
  • platform/graphics/win/NativeImageDirect2D.cpp:
  • platform/graphics/win/PathDirect2D.cpp:
  • platform/graphics/win/PatternDirect2D.cpp:
  • platform/graphics/win/PlatformContextDirect2D.cpp: Added.
  • platform/graphics/win/PlatformContextDirect2D.h: Added.
  • platform/win/DragImageWin.cpp:
  • svg/graphics/SVGImage.cpp:
3:25 PM Changeset in webkit [248019] by Nikita Vasilyev
  • 2 edits in trunk/Source/WebInspectorUI

Web Inspector: Resources: Display outline around images when viewing image collections
https://bugs.webkit.org/show_bug.cgi?id=200212

Reviewed by Devin Rousso.

  • UserInterface/Views/CollectionContentView.css:

(.content-view.collection .resource.image img):
(.content-view.collection .resource.image img:hover):

2:48 PM Changeset in webkit [248018] by mmaxfield@apple.com
  • 6 edits in trunk/Source

REGRESSION(r241288): Text on Yahoo Japan mobile looks too bold
https://bugs.webkit.org/show_bug.cgi?id=200065
<rdar://problem/50912757>

Reviewed by Simon Fraser.

Source/WebCore:

Before r241288, we were mapping Japanese sans-serif to Hiragino Kaku Gothic ProN, which
has a 300 weight and a 600 weight. However, we can't use that font because it's user-installed,
so in r241288 we switched to using Hiragino Sans, which has a 300 weight, a 600 weight, and an
800 weight. According to the CSS font selection algorithm, sites that request a weight of 700
would get the 800 weight instead of the 600 weight, which caused the text to look too heavy.
Therefore, the apparent visual change is from a weight change from 600 to 800.

In general, this is working as intended. However, text on Yahoo Japan looks too heavy in weight

  1. Instead, this patch adds a quirk specific to Yahoo Japan that overwrites any font requests

to give them a weight of 600 instead of 700. This way, the lighter font will be used.

No new tests because quirks cannot be tested.

  • css/CSSFontSelector.cpp:

(WebCore::resolveGenericFamily):
(WebCore::CSSFontSelector::fontRangesForFamily):

  • page/Quirks.cpp:

(WebCore::Quirks::shouldLightenJapaneseBoldSansSerif const):

  • page/Quirks.h:

Source/WTF:

  • wtf/Platform.h:
2:09 PM BuildingGtk edited by Michael Catanzaro
Tweak language, "CMake module" has a specific meaning, and it's not … (diff)
2:04 PM Changeset in webkit [248017] by Ryan Haddad
  • 8 edits
    7 copies
    53 adds in trunk/LayoutTests

Add test expectations and baselines for iPad
https://bugs.webkit.org/show_bug.cgi?id=199711

Unreviewed test gardening.

  • platform/ipad-12/TestExpectations: Added.
  • platform/ipad-12/fast/scrolling/ios/overflow-scrolling-ancestor-clip-expected.txt: Copied from LayoutTests/platform/ipad/fast/scrolling/ios/overflow-scrolling-ancestor-clip-expected.txt.
  • platform/ipad-12/fast/scrolling/ios/overflow-scrolling-ancestor-clip-size-expected.txt: Copied from LayoutTests/platform/ipad/fast/scrolling/ios/overflow-scrolling-ancestor-clip-size-expected.txt.
  • platform/ipad-12/fast/scrolling/ios/subpixel-overflow-scrolling-with-ancestor-expected.txt: Copied from LayoutTests/platform/ipad/fast/scrolling/ios/subpixel-overflow-scrolling-with-ancestor-expected.txt.
  • platform/ipad-12/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-tall-expected.txt: Copied from LayoutTests/platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-tall-expected.txt.
  • platform/ipad-12/platform/ios/ios/fast/text/opticalFontWithTextStyle-expected.txt: Copied from LayoutTests/platform/ipad/platform/ios/ios/fast/text/opticalFontWithTextStyle-expected.txt.
  • platform/ipad-12/scrollingcoordinator/ios/ui-scrolling-tree-expected.txt: Copied from LayoutTests/platform/ipad/scrollingcoordinator/ios/ui-scrolling-tree-expected.txt.
  • platform/ipad/compositing/overflow/scrolling-content-clip-to-viewport-expected.txt: Added.
  • platform/ipad/compositing/rtl/rtl-scrolling-with-transformed-descendants-expected.txt: Added.
  • platform/ipad/editing/caret/ios/fixed-caret-position-after-scroll-expected.txt: Added.
  • platform/ipad/editing/selection/ios/do-not-hide-selection-in-visible-container-expected.txt: Added.
  • platform/ipad/fast/dom/navigator-iOS-userAgent-expected.txt: Added.
  • platform/ipad/fast/scrolling/ios/change-scrollability-on-content-resize-nested-expected.txt: Added.
  • platform/ipad/fast/scrolling/ios/overflow-scrolling-ancestor-clip-expected.txt:
  • platform/ipad/fast/scrolling/ios/overflow-scrolling-ancestor-clip-size-expected.txt:
  • platform/ipad/fast/scrolling/ios/reconcile-layer-position-recursive-expected.txt: Added.
  • platform/ipad/fast/scrolling/ios/subpixel-overflow-scrolling-with-ancestor-expected.txt:
  • platform/ipad/fast/viewport/ios/shrink-to-fit-for-page-without-viewport-meta-expected.txt: Added.
  • platform/ipad/fast/viewport/ios/width-is-device-width-overflowing-body-overflow-hidden-tall-expected.txt:
  • platform/ipad/imported/w3c/web-platform-tests/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/open-features-non-integer-height-expected.txt: Added.
  • platform/ipad/imported/w3c/web-platform-tests/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/open-features-non-integer-innerheight-expected.txt: Added.
  • platform/ipad/imported/w3c/web-platform-tests/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/open-features-non-integer-innerwidth-expected.txt: Added.
  • platform/ipad/imported/w3c/web-platform-tests/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/open-features-non-integer-width-expected.txt: Added.
  • platform/ipad/imported/w3c/web-platform-tests/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/open-features-tokenization-innerheight-innerwidth-expected.txt: Added.
  • platform/ipad/imported/w3c/web-platform-tests/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/open-features-tokenization-width-height-expected.txt: Added.
  • platform/ipad/imported/w3c/web-platform-tests/workers/WorkerNavigator_platform-expected.txt: Added.
  • platform/ipad/imported/w3c/web-platform-tests/workers/interfaces/WorkerUtils/navigator/004-expected.txt: Added.
  • platform/ipad/platform/ios/ios/fast/text/opticalFontWithTextStyle-expected.txt:
  • platform/ipad/scrollingcoordinator/ios/fixed-in-frame-layer-reconcile-layer-position-expected.txt: Added.
  • platform/ipad/scrollingcoordinator/ios/fixed-in-overflow-scroll-scrolling-tree-expected.txt: Added.
  • platform/ipad/scrollingcoordinator/ios/fixed-scrolling-with-keyboard-expected.txt: Copied from LayoutTests/platform/ipad/scrollingcoordinator/ios/ui-scrolling-tree-expected.txt.
  • platform/ipad/scrollingcoordinator/ios/non-stable-viewport-scroll-expected.txt: Added.
  • platform/ipad/scrollingcoordinator/ios/ui-scrolling-tree-expected.txt:
2:01 PM Changeset in webkit [248016] by Jonathan Bedard
  • 2 edits in trunk/Tools

DumpRenderTree.app: Add CFBundleShortVersionString
https://bugs.webkit.org/show_bug.cgi?id=200269
<rdar://problem/53412596>

Rubber-stamped by Aakash Jain.

  • DumpRenderTree/ios/Info.plist:
1:21 PM Changeset in webkit [248015] by Simon Fraser
  • 3 edits
    2 adds in trunk

Can't scroll on yummly.co.uk recipe (scale(0) div covers the content and hit-tests)
https://bugs.webkit.org/show_bug.cgi?id=200263
rdar://problem/53679408

Reviewed by Antti Koivisto.

Source/WebKit:

The content on this page had a scale(0) div overlaying an overflow:scroll element,
and our UI-side hit-testing code would find this scale(0) element, because apparently
-[UIView convertPoint:fromView:] will happily work with non-invertible matrices, and
-[UIView pointInside:withEvent:] just compares the point with the view bounds.

Since the view frame takes the transform into account, we can look for an empty frame
to detect these non-invertible transforms.

  • UIProcess/RemoteLayerTree/ios/RemoteLayerTreeViews.mm:

(WebKit::collectDescendantViewsAtPoint):

LayoutTests:

  • fast/scrolling/ios/non-invertible-transformed-over-scroller-expected.txt: Added.
  • fast/scrolling/ios/non-invertible-transformed-over-scroller.html: Added.
12:54 PM Changeset in webkit [248014] by Chris Dumez
  • 5 edits in trunk/Source/WebKit

Fix non-thread safe use of WeakPtr under sendSecItemRequest()
https://bugs.webkit.org/show_bug.cgi?id=200249

Reviewed by Alex Christensen.

The function was calling globalNetworkProcess() from a background thread. This is not safe because
globalNetworkProcess() deferences a WeakPtr<NetworkProcess> internally and the NetworkProcess object
gets destroyed on the main thread.

  • Shared/mac/SecItemShim.cpp:

(WebKit::sendSecItemRequest):

11:41 AM Changeset in webkit [248013] by Michael Catanzaro
  • 2 edits in trunk/Source/WebCore

Unreviewed, fix GTK build after SoupNetworkSession ownership rework.

  • platform/network/soup/SocketStreamHandleImplSoup.cpp:
10:28 AM Changeset in webkit [248012] by Michael Catanzaro
  • 3 edits in trunk/Source/WebCore

[GTK] Compilation errors when GL is disabled
https://bugs.webkit.org/show_bug.cgi?id=200223

Unreviewed, keep trying to fix build with -DENABLE_OPENGL=OFF.

The previous commit was sufficient for the 2.24 branch, but on trunk there are more
problems. This doesn't solve all of them, but it gets us closer.

  • SourcesGTK.txt:
  • platform/graphics/GLContext.h:
10:23 AM Changeset in webkit [248011] by dbates@webkit.org
  • 2 edits in trunk/LayoutTests

picture-in-picture.html fails because webkitpresentationmodechanged sometimes dispatched multiple times
using Apple Internal build
<rdar://problem/36455352>

Workaround by only listening for the first webkitpresentationmodechanged event dispatched. This test
is the canary in the coal mine that revealed that multiple webkitpresentationmodechanged events are
dispatched when one is expected. However this was not the primary purpose of the test and in absence
of a timeframe for a fix for <rdar://problem/36455352> work around this bug to avoid losing test coverage
when using an Apple Internal build.

  • platform/ipad/media/controls/resources/picture-in-picture.html:
9:31 AM Changeset in webkit [248010] by Carlos Garcia Campos
  • 21 edits in trunk/Source

[SOUP] Move SoupNetworkSession ownership from NetworkStorageSession to NetworkSession
https://bugs.webkit.org/show_bug.cgi?id=200076

Reviewed by Michael Catanzaro.

Source/WebCore:

Remove the SoupNetworkSession from NetworkStorageSession.

  • platform/network/NetworkStorageSession.h:

(WebCore::NetworkStorageSession::cookieStorage const): Return the cookie jar.

  • platform/network/StorageSessionProvider.h:

(WebCore::StorageSessionProvider::soupSession const): Temporary add this virtual method that is required by
SocketStreamHandleImplSoup. It will be removed once we switch to libsoup WebSockets API soon.

  • platform/network/soup/DNSResolveQueueSoup.cpp:

(WebCore::globalDefaultSoupSessionAccessor): Rework the accessor to return the SoupSession directly since
that's what we really want.
(WebCore::DNSResolveQueueSoup::setGlobalDefaultSoupSessionAccessor):
(WebCore::DNSResolveQueueSoup::updateIsUsingProxy):
(WebCore::DNSResolveQueueSoup::platformResolve):
(WebCore::DNSResolveQueueSoup::resolve):

  • platform/network/soup/DNSResolveQueueSoup.h:
  • platform/network/soup/NetworkStorageSessionSoup.cpp:

(WebCore::NetworkStorageSession::NetworkStorageSession): Create and setup the default cookie jar.
(WebCore::NetworkStorageSession::~NetworkStorageSession): Only disconnect the cookie jar signals.
(WebCore::NetworkStorageSession::setCookieStorage): Update the cookie jar, now we know it's always a new one.

  • platform/network/soup/SocketStreamHandleImplSoup.cpp:

(WebCore::SocketStreamHandleImpl::create): Use the new virtual method from StorageSessionProvider to get the SoupSession.

  • platform/network/soup/SoupNetworkSession.cpp:

(WebCore::SoupNetworkSession::SoupNetworkSession): Remove the SoupCookieJar parameter.

  • platform/network/soup/SoupNetworkSession.h:

Source/WebKit:

NetworkStorageSession should only own the cookie jar, since it's the only thing it handles from the session.

  • NetworkProcess/Cookies/soup/WebCookieManagerSoup.cpp:

(WebKit::WebCookieManager::setCookiePersistentStorage): Use the network session instead of the storage session
to set the peristent cookie storage.

  • NetworkProcess/CustomProtocols/soup/LegacyCustomProtocolManagerSoup.cpp:

(WebKit::LegacyCustomProtocolManager::registerScheme): Iterate network sessions instead of storage sessions to
access the SoupNetworkSession.

  • NetworkProcess/NetworkConnectionToWebProcess.cpp:

(WebKit::NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated): Use
NetworkProcess::forEachNetworkSession() to iterate network sessions.

  • NetworkProcess/NetworkProcess.cpp:

(WebKit::NetworkProcess::lowMemoryHandler): Ditto.
(WebKit::NetworkProcess::forEachNetworkSession): Added to iterate network sessions intead of exposing the map
that is always used to iterate the sessions.
(WebKit::NetworkProcess::switchToNewTestingSession): Use the new NetworkStorageSession constructor API.
(WebKit::NetworkProcess::ensureSession): Ditto.
(WebKit::NetworkProcess::destroySession): Allow to destroy the default session for soup based ports. This is
only called right before process exit to ensure we don't leak network resources like the cookies database.
(WebKit::NetworkProcess::setResourceLoadStatisticsEnabled): Use NetworkProcess::forEachNetworkSession() to
iterate network sessions.
(WebKit::NetworkProcess::fetchWebsiteData): Ditto.
(WebKit::NetworkProcess::deleteWebsiteDataForOrigins): Ditto.
(WebKit::NetworkProcess::deleteWebsiteDataForRegistrableDomains): Ditto.
(WebKit::NetworkProcess::registrableDomainsWithWebsiteData): Ditto.
(WebKit::NetworkProcess::setCacheModel): Ditto.
(WebKit::NetworkProcess::actualPrepareToSuspend): Ditto.
(WebKit::NetworkProcess::resume): Ditto.

  • NetworkProcess/NetworkProcess.h:
  • NetworkProcess/NetworkStorageSessionProvider.h:
  • NetworkProcess/cocoa/NetworkProcessCocoa.mm:

(WebKit::NetworkProcess::clearDiskCache): Ditto.

  • NetworkProcess/ios/NetworkProcessIOS.mm:

(WebKit::NetworkProcess::clearCacheForAllOrigins): Ditto.

  • NetworkProcess/soup/NetworkProcessMainSoup.cpp: Destroy the default session before process exists.
  • NetworkProcess/soup/NetworkProcessSoup.cpp:

(WebKit::NetworkProcess::userPreferredLanguagesChanged): Iterate network sessions instead of storage sessions to
access the SoupNetworkSession.
(WebKit::NetworkProcess::platformCreateDefaultStorageSession const): Use the new NetworkStorageSession constructor API.
(WebKit::NetworkProcess::clearDiskCache): Use NetworkProcess::forEachNetworkSession() to iterate network sessions.
(WebKit::NetworkProcess::setNetworkProxySettings): Iterate network sessions instead of storage sessions to
access the SoupNetworkSession.

  • NetworkProcess/soup/NetworkSessionSoup.cpp:

(WebKit::NetworkSessionSoup::NetworkSessionSoup): Create the SoupNetworkSession and setup cookies.
(WebKit::NetworkSessionSoup::soupSession const): Return the SoupSession of SoupNetworkSession.
(WebKit::NetworkSessionSoup::setCookiePersistentStorage): Setup a new cookie jar.

  • NetworkProcess/soup/NetworkSessionSoup.h:
9:18 AM WebKitGTK/2.24.x edited by Michael Catanzaro
(diff)
9:17 AM Changeset in webkit [248009] by Michael Catanzaro
  • 2 edits in trunk/Source/WebCore

[GTK] Compilation errors when GL is disabled
https://bugs.webkit.org/show_bug.cgi?id=200223

Unreviewed, fix build with -DENABLE_OPENGL=OFF.

  • platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:

(WebCore::MediaPlayerPrivateGStreamer::createGSTPlayBin):

9:04 AM Changeset in webkit [248008] by Michael Catanzaro
  • 2 edits in trunk/Source/WTF

Fix CRASH_WITH_INFO() so that it doesn't complain about unused parameters on non Clang / MSVC compilers.
https://bugs.webkit.org/show_bug.cgi?id=200243

Reviewed by Mark Lam.

For GCC, we'll implement WTFCrashWithInfo as a function rather than a macro. To use
##VA_ARGS we would need to enable GNU extensions, and don't want to do that. The proper
solution, format
VA_OPT(,) VA_ARGS, requires C++20. So just use an inline function
for now as a workaround.

  • wtf/Assertions.h:

(CRASH_WITH_INFO):
(CRASH_WITH_SECURITY_IMPLICATION_AND_INFO):

9:04 AM Changeset in webkit [248007] by Dewei Zhu
  • 2 edits in trunk/Websites/perf.webkit.org

Should not render latest build information if there is no data points for a config.
https://bugs.webkit.org/show_bug.cgi?id=200250

Reviewed by Ryosuke Niwa.

Fix a bug test freshness page that tooltip cannot be rendered when a cell does not have
a data point.

  • public/v3/pages/test-freshness-page.js: Added a null check on commit set before rendering

latest build informaiton.
(TestFreshnessPage.prototype._renderTooltip):

8:40 AM Changeset in webkit [248006] by Truitt Savell
  • 5 edits in trunk/Source/WebKit

Unreviewed, rolling out r247932.

Broke 8 API tests across all platforms.

Reverted changeset:

"Fix non-thread safe use of WeakPtr under
sendSecItemRequest()"
https://bugs.webkit.org/show_bug.cgi?id=200249
https://trac.webkit.org/changeset/247932

8:24 AM Changeset in webkit [248005] by Truitt Savell
  • 2 edits in trunk/LayoutTests

(r247440) imported/w3c/web-platform-tests/wasm/jsapi/interface.any.worker.html is a flakey failure
https://bugs.webkit.org/show_bug.cgi?id=200258

Unreviewed test gardening.

  • platform/mac/TestExpectations:

Jul 29, 2019:

10:29 PM Changeset in webkit [248004] by Devin Rousso
  • 2 edits in trunk/Source/WebInspectorUI

Web Inspector: Resources: add a "Show Grid" navigation item for the Images collection
https://bugs.webkit.org/show_bug.cgi?id=200260

Reviewed by Joseph Pecoraro.

Each subview WI.ImageResourceContentView already listens for changes to the underlying
WI.settings.showImageGrid and adds the .show-grid class if enabled. As such, this change
just adds a WI.ButtonNavigationItem for toggling WI.settings.showImageGrid from the
Images "folder".

  • UserInterface/Views/ResourceCollectionContentView.js:

(WI.ResourceCollectionContentView):
(WI.ResourceCollectionContentView.prototype.get navigationItems):
(WI.ResourceCollectionContentView.prototype.attached): Added.
(WI.ResourceCollectionContentView.prototype.detached): Added.
(WI.ResourceCollectionContentView.prototype._updateImageTypeScopeBar):
Drive-by: hide the image type WI.ScopeBar if there's only one type of image.
(WI.ResourceCollectionContentView.prototype._handleShowGridButtonClicked): Added.
(WI.ResourceCollectionContentView.prototype._handleShowImageGridSettingChanged): Added.

8:57 PM Changeset in webkit [248003] by Alan Coon
  • 3 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247823. rdar://problem/53449739

Unreviewed, fix -Wredundant-move warning spam after r247672
https://bugs.webkit.org/show_bug.cgi?id=199967
<rdar://problem/53351435>

  • Platform/IPC/ArgumentCoders.cpp: (IPC::decodeStringText):
  • Platform/IPC/ArgumentCoders.h:

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

8:56 PM Changeset in webkit [248002] by Alan Coon
  • 9 edits in branches/safari-608-branch

Cherry-pick r247673. rdar://problem/53449723

Speed up HashTable decoding by reserving capacity and avoiding rehashing
https://bugs.webkit.org/show_bug.cgi?id=199982

Reviewed by Saam Barati.

Source/WebKit:

Use HashMap::reserveInitialCapacity() in the HashMap IPC decoder for
performance. I measured a ~35% improvement when decoding a very large
HashMap of Strings (~160k entries) in the context of the
StorageManager::GetValues IPC.

  • Platform/IPC/ArgumentCoders.h:
  • Shared/API/c/WKDictionary.cpp: (WKDictionaryCreate):

Source/WTF:

Introduce reserveInitialCapacity() on HashMap to reserve capacity on a
HashMap and cut down on rehashing cost when possible.

  • wtf/HashMap.h:
  • wtf/HashTable.h: (WTF::HashTable::reserveInitialCapacity):
  • wtf/persistence/PersistentCoders.h: Use HashMap::reserveInitialCapacity() in the HashMap persistent decoder for performance.

Tools:

Add API test coverage.

  • TestWebKitAPI/Tests/WTF/HashMap.cpp: (TestWebKitAPI::TEST):

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

8:56 PM Changeset in webkit [248001] by Alan Coon
  • 3 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247672. rdar://problem/53449739

Micro-optimize HashMap & String IPC decoding
https://bugs.webkit.org/show_bug.cgi?id=199967

Reviewed by Geoffrey Garen.

The legacy HashMap decoder (returning a boolean) was failing to WTFMove()
the key & value when calling HashMap::add(). The modern decoder (returning
an Optional) was properly using WTFMove(). Rewrite the legacy HashMap decoder
to call the modern one to reduce code duplication and to get this optimization.

Also, encode HashMap::size() as a uint32_t instead of a uint64_t since
HashMap::size() returns an 'unsigned int' type. Finally, update the modern
decoder to WTFMove(hashMap) when returning. Because the function returns an
Optional<HashMap> and not a HashMap, I do not believe we get return value
optimization (RVO).

Do similar changes to String IPC coders.

  • Platform/IPC/ArgumentCoders.cpp: (IPC::decodeStringText): (IPC::ArgumentCoder<String>::decode):
  • Platform/IPC/ArgumentCoders.h:

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

8:56 PM Changeset in webkit [248000] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247890. rdar://problem/53647283

Allow more syscalls in the WebContent process' sandbox profile
https://bugs.webkit.org/show_bug.cgi?id=200182
<rdar://problem/53594973>

Reviewed by Geoffrey Garen.

I reviewed all crash traces attached to the radar and found the following
syscalls that we not yet allowed by the WebContent process's sandbox
profile.

  • WebProcess/com.apple.WebProcess.sb.in:

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

8:56 PM Changeset in webkit [247999] by Alan Coon
  • 6 edits in branches/safari-608-branch

Cherry-pick r247885. rdar://problem/53648025

NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting
https://bugs.webkit.org/show_bug.cgi?id=200150
<rdar://problem/53280170>

Reviewed by Brent Fulgham.

Source/WebKit:

NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting
as the page might have already changed the location.

  • UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.h:
  • UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm: (WebKit::NavigationSOAuthorizationSession::shouldStartInternal): (WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow): (WebKit::NavigationSOAuthorizationSession::pageActiveURLDidChangeDuringWaiting const):
  • UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm: (WebKit::SubFrameSOAuthorizationSession::abortInternal):

Tools:

  • TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm: (TestWebKitAPI::TEST):

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

8:56 PM Changeset in webkit [247998] by Alan Coon
  • 3 edits
    2 adds in branches/safari-608-branch

Cherry-pick r247880. rdar://problem/53647903

Do not fire readystatechange events at documents about to get replaced by javascript URLs.
<rdar://problem/51665406> and https://bugs.webkit.org/show_bug.cgi?id=198786

Reviewed by Ryosuke Niwa.

Source/WebCore:

Test: http/tests/dom/ready-state-on-javascript-replace.html

We were firing too many readystatechange events, more than other browsers.
Our behavior on this test with this patch now matches Chrome.

(There was even an ancient FIXME alluding to this referencing a spec issue, and that issues has long been resolvedv)

  • loader/FrameLoader.cpp: (WebCore::FrameLoader::stopLoading):

LayoutTests:

  • http/tests/dom/ready-state-on-javascript-replace-expected.txt: Added.
  • http/tests/dom/ready-state-on-javascript-replace.html: Added.

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

8:56 PM Changeset in webkit [247997] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247879. rdar://problem/53648230

[iPadOS] wix.com cannot select a template to edit or view
https://bugs.webkit.org/show_bug.cgi?id=200174
<rdar://problem/53281296>

Reviewed by Simon Fraser.

Opt out of simulated mouse event sending for template selection on wix.com.
When wix.com receives a simulated mouse event during the touch events, it calls preventDefault() which prevents us from running the hover heuristics -> no click.

  • page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const):

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

8:56 PM Changeset in webkit [247996] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247876. rdar://problem/53647283

Crashes under XPCServiceMain() / mach_msg_trap() due to sandboxing
https://bugs.webkit.org/show_bug.cgi?id=200173
<rdar://problem/53594973>

Reviewed by Per Arne Vollan.

Allow a few more syscalls as they appear to be needed by mach_msg_trap().

  • WebProcess/com.apple.WebProcess.sb.in:

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

8:56 PM Changeset in webkit [247995] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247875. rdar://problem/53648065

[iOS] REGRESSION: Keyboard dismisses and reappears when typing 2FA pin on appleid.apple.com
https://bugs.webkit.org/show_bug.cgi?id=200171
<rdar://problem/50245251>

Reviewed by Wenson Hsieh.

Take out an InputViewUpdateDeferrer token (if we don't already have one) to temporarily defer
tearing down the input view (keyboard) before bluring the previously focused element as part
of switching between focused elements. This avoid a noticeable flash caused by UIKit animating
out and animating in the keyboard should the newly focused element require the keyboard. We
only take out the InputViewUpdateDeferrer until we fall off the end of _elementDidFocus: (or
bail early). Once we fall of the end UIKit will update input view UI.

  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):

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

8:56 PM Changeset in webkit [247994] by Alan Coon
  • 4 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247873. rdar://problem/53648217

slides.google.com: opening speaker notes while presenting causes a fatal error in the web app on iPad
https://bugs.webkit.org/show_bug.cgi?id=199933
<rdar://problem/53034345>

Reviewed by Darin Adler.

docs.google.com might sometimes try to window.open an about URL that not about:blank or about:srcdoc.
In that case, WebKit is opening a window but is considering that the window is cross origin with its opener.
This breaks docs.google.com as they want to access the website.
Add a site-specific hack so as to treat all about URLs being opened through window.open as about:blank.

Manually tested on docs.google.com website.

  • page/DOMWindow.cpp: (WebCore::DOMWindow::createWindow): (WebCore::DOMWindow::open):
  • page/Quirks.cpp: (WebCore::Quirks::needsYouTubeOverflowScrollQuirk const): (WebCore::Quirks::shouldOpenAsAboutBlank const):
  • page/Quirks.h:

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

8:56 PM Changeset in webkit [247993] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247872. rdar://problem/53647297

Avoid WebContent process SIGKILL when using kevent()
https://bugs.webkit.org/show_bug.cgi?id=200170
<rdar://problem/51559921>

Reviewed by Per Arne Vollan.

Avoid WebContent process SIGKILL when using kevent() by updated its sandboxing profile.

  • WebProcess/com.apple.WebProcess.sb.in:

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

8:56 PM Changeset in webkit [247992] by Alan Coon
  • 17 edits
    2 moves in branches/safari-608-branch

Cherry-pick r247868. rdar://problem/53648207

[iOS] WebPage::TouchEventSync() & WebPage::GetPositionInformation() sync IPC causes UIProcess hangs
https://bugs.webkit.org/show_bug.cgi?id=200138
<rdar://problem/52698157>

Reviewed by Geoffrey Garen.

Source/WebKit:

Revert most of r247822 and use an alternative approach to address hangs. In this patch, the proposal
is to add a SendSyncOption::ForceDispatchWhenDestinationIsWaitingForUnboundedSyncReply flag on the
WebPage::TouchEventSync() & WebPage::GetPositionInformation() sendSync() calls in the UIProcess.
Those will cause this IPCs to get dispatched right away in the WebContent process, even if the
WebContent process is itself currently stuck on unbounded (i.e. potentially slow) synchronous IPC
(JS alerts / prompts & sync XHR). Because re-entering WebCore on sync IPC is generally unsafe, this
patch also updates the WebPage::getPositionInformation() & WebPage::touchEventSync() to return early
(i.e. cancelled) if they get called while the WebContent process is stuck on a slow sendSync.

This approach should address the UIProcess hangs caused by the WebPage::TouchEventSync() and
WebPage::GetPositionInformation() sync IPC messages when the WebContent process is busy on a slow XHR
or a JS prompt / alert. It should be safe because we do not re-enter WebCore. The only drawback is that
those IPCs will be cancelled (early return with default value) when the WebContent process is busy.
However, I am being told that this is likely acceptable in practice.

  • Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendMessage): (IPC::Connection::sendSyncMessage): (IPC::Connection::dispatchMessage):
  • Platform/IPC/Connection.h: (IPC::UnboundedSynchronousIPCScope::UnboundedSynchronousIPCScope): (IPC::UnboundedSynchronousIPCScope::~UnboundedSynchronousIPCScope): (IPC::UnboundedSynchronousIPCScope::hasOngoingUnboundedSyncIPC):
  • Platform/IPC/Decoder.cpp: (IPC::Decoder::shouldDispatchMessageWhenWaitingForSyncReply const):
  • Platform/IPC/Decoder.h:
  • Platform/IPC/Encoder.cpp: (IPC::Encoder::shouldDispatchMessageWhenWaitingForSyncReply const): (IPC::Encoder::setShouldDispatchMessageWhenWaitingForSyncReply): (IPC::Encoder::wrapForTesting):
  • Platform/IPC/Encoder.h:
  • Platform/IPC/MessageFlags.h:
  • UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::handleTouchEventSynchronously):
  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView ensurePositionInformationIsUpToDate:]):
  • WebProcess/Network/WebLoaderStrategy.cpp: (WebKit::WebLoaderStrategy::loadResourceSynchronously):
  • WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply): (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt):
  • WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::layerVolatilityTimerFired): (WebKit::WebPage::markLayersVolatile): (WebKit::WebPage::cancelMarkLayersVolatile): (WebKit::WebPage::touchEventSync): (WebKit::WebPage::didCompletePageTransition): (WebKit::WebPage::updatePreferences): (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
  • WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply):
  • WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::getPositionInformation):

LayoutTests:

Update existing layout test accordingly.

  • fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply-expected.txt: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt.
  • fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply.html: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html.

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

8:56 PM Changeset in webkit [247991] by Alan Coon
  • 3 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247864. rdar://problem/53647289

AX: web process should load correct bundle path for MACCATALYST
https://bugs.webkit.org/show_bug.cgi?id=200122

Patch by Eric Liang <ericliang@apple.com> on 2019-07-26
Reviewed by Brent Fulgham.

Added the path to accessibility bundle for Mac Catalyst.
Added sandbox profile to read accessibility settings.

  • WebProcess/cocoa/WebProcessCocoa.mm: (WebKit::registerWithAccessibility):
  • WebProcess/com.apple.WebProcess.sb.in:

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

8:56 PM Changeset in webkit [247990] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247853. rdar://problem/53648225

Unreviewed, build fix after r247851

  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::decidePolicyForNavigationAction): Reverts an unnecessary change.

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

8:56 PM Changeset in webkit [247989] by Alan Coon
  • 6 edits in branches/safari-608-branch

Cherry-pick r247851. rdar://problem/53648225

WebPageProxy::receivedPolicyDecision should check navigation ID before clear pendingAPIRequest
https://bugs.webkit.org/show_bug.cgi?id=200108
<rdar://problem/53521238>

Reviewed by Chris Dumez.

Source/WebKit:

Assuming there are two loads happening one after another. There is an issue when clients save
the first decisionHandler and then call WKNavigationActionPolicyCancel for it right after the
second decisionHandler received, -[WKWebView URL] could return a null string even though it is
loading the second one.

To solve that, this patch pairs a navigationID with the pendingAPIRequestURL such that
WebPageProxy::receivedPolicyDecision could clear the pendingAPIRequestURL only if
the passed navigation ID matches the current one.

  • UIProcess/PageLoadState.cpp: (WebKit::PageLoadState::reset): (WebKit::PageLoadState::activeURL): (WebKit::PageLoadState::estimatedProgress): (WebKit::PageLoadState::pendingAPIRequestURL const): (WebKit::PageLoadState::pendingAPIRequest const): (WebKit::PageLoadState::setPendingAPIRequest): (WebKit::PageLoadState::clearPendingAPIRequest): (WebKit::PageLoadState::isLoading): (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted. (WebKit::PageLoadState::clearPendingAPIRequestURL): Deleted.
  • UIProcess/PageLoadState.h: (WebKit::PageLoadState::setPendingAPIRequest): (WebKit::PageLoadState::setPendingAPIRequestURL): Deleted.
  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::launchProcessForReload): (WebKit::WebPageProxy::loadRequestWithNavigationShared): (WebKit::WebPageProxy::loadFile): (WebKit::WebPageProxy::loadDataWithNavigationShared): (WebKit::WebPageProxy::loadAlternateHTML): (WebKit::WebPageProxy::loadWebArchiveData): (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::goToBackForwardItem): (WebKit::WebPageProxy::receivedPolicyDecision): (WebKit::WebPageProxy::continueNavigationInNewProcess): (WebKit::WebPageProxy::didStartProvisionalLoadForFrameShared): (WebKit::WebPageProxy::didSameDocumentNavigationForFrame): (WebKit::WebPageProxy::decidePolicyForNavigationAction):

Tools:

Added an API test.

  • TestWebKitAPI/Tests/WebKitCocoa/DecidePolicyForNavigationAction.mm: (-[DecidePolicyForNavigationActionController webView:decidePolicyForNavigationAction:decisionHandler:]): (TEST):

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

8:56 PM Changeset in webkit [247988] by Alan Coon
  • 4 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247846. rdar://problem/53647613

Subpixel fringes around TextIndicator snapshots at non-integral scale factors
https://bugs.webkit.org/show_bug.cgi?id=200145

Reviewed by Simon Fraser.

  • page/FrameSnapshotting.cpp: (WebCore::snapshotFrameRectWithClip):
  • page/FrameSnapshotting.h:
  • page/TextIndicator.cpp: (WebCore::snapshotOptionsForTextIndicatorOptions): Round the scale factor up, and snappily enclose the clip rects.

TextIndicator doesn't require the use of the precise scale factor that
the page is painted at, but we want it to be sharp, so we overshoot!

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

8:56 PM Changeset in webkit [247987] by Alan Coon
  • 6 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247840. rdar://problem/53647624

REGRESSION (r243637): Some web fonts fail to load on Google docs
https://bugs.webkit.org/show_bug.cgi?id=200106

Reviewed by Geoffrey Garen.

Prior to r243637, WebKit threw an exception if the font family name didn't parse as a CSS identifier in the setter
of family IDL attribute of FontFace interface because WebKit implemented the old spec faithfully unlike Chrome
and Firefox which basically treated it as a string and didn't throw any exception. [1]

To account for this browser behavior difference, Google docs implemented a workaround for Safari which is to wrap
some identifiers in font family names with quotation marks: docs-Amatic SC as 'docs-Amatic SC' and
docs-Playfair Display as docs-'Playfair Display'. Unfortunately, this in turn causes the latest Safari to
not match these font face family with those that appear in stylesheet since we no longer parse it as a CSS identifier.

This patch adds a site specific quirk for Google docs to undo this workaround by stripping away single quotation marks.

[1] See https://github.com/w3c/csswg-drafts/issues/3776 for the context.

  • css/FontFace.cpp: (WebCore::FontFace::create): (WebCore::FontFace::setFamily):
  • css/FontFace.h:
  • css/FontFace.idl:
  • page/Quirks.cpp: (WebCore::Quirks::shouldStripQuotationMarkInFontFaceSetFamily const):
  • page/Quirks.h:

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

8:56 PM Changeset in webkit [247986] by Alan Coon
  • 12 edits
    2 adds in branches/safari-608-branch

Cherry-pick r247839. rdar://problem/53647896

[iOS WK2] A top fixed bar can flicker when scrolling with the keyboard up
https://bugs.webkit.org/show_bug.cgi?id=200105
rdar://problem/52871975

Reviewed by Wenson Hsieh.

Source/WebCore:

ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition() computes a visual viewport
from the current scroll position and scrollableAreaSize(). This doesn't know anything about
the impact of keyboards on the visual viewport, so it computes a too-large visual viewport
when the keyboard is up, triggering incorrect manipulations of the layout viewport. This
leads to the top bar flashing to position 0 when it should be hidden off the top.

Fix by feeding into the scrolling tree the height of the visual viewport which takes
FrameView::visualViewportOverrideRect() into account. This is stored on ScrollingStateFrameScrollingNode/
ScrollingTreeFrameScrollingNode.

Test: scrollingcoordinator/ios/fixed-scrolling-with-keyboard.html

  • page/FrameView.h:
  • page/scrolling/AsyncScrollingCoordinator.cpp: (WebCore::AsyncScrollingCoordinator::setFrameScrollingNodeState):
  • page/scrolling/ScrollingStateFrameScrollingNode.cpp: (WebCore::ScrollingStateFrameScrollingNode::ScrollingStateFrameScrollingNode): (WebCore::ScrollingStateFrameScrollingNode::setPropertyChangedBitsAfterReattach): (WebCore::ScrollingStateFrameScrollingNode::setOverrideVisualViewportSize): (WebCore::ScrollingStateFrameScrollingNode::dumpProperties const):
  • page/scrolling/ScrollingStateFrameScrollingNode.h:
  • page/scrolling/ScrollingTree.cpp: (WebCore::ScrollingTree::commitTreeState): LOG_WITH_STREAM() doesn't evaluate scrollingTreeAsText() every time.
  • page/scrolling/ScrollingTreeFrameScrollingNode.cpp: (WebCore::ScrollingTreeFrameScrollingNode::commitStateBeforeChildren): (WebCore::ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition const): (WebCore::ScrollingTreeFrameScrollingNode::dumpProperties const):
  • page/scrolling/ScrollingTreeFrameScrollingNode.h:

Source/WebKit:

ScrollingTreeFrameScrollingNode::layoutViewportForScrollPosition() computes a visual viewport
from the current scroll position and scrollableAreaSize(). This doesn't know anything about
the impact of keyboards on the visual viewport, so it computes a too-large visual viewport
when the keyboard is up, triggering incorrect manipulations of the layout viewport. This
leads to the top bar flashing to position 0 when it should be hidden off the top.

Fix by feeding into the scrolling tree the height of the visual viewport which takes
FrameView::visualViewportOverrideRect() into account. This is stored on ScrollingStateFrameScrollingNode/
ScrollingTreeFrameScrollingNode.

  • Shared/RemoteLayerTree/RemoteScrollingCoordinatorTransaction.cpp: (ArgumentCoder<ScrollingStateFrameScrollingNode>::encode): (ArgumentCoder<ScrollingStateFrameScrollingNode>::decode):

LayoutTests:

  • resources/ui-helper.js: (window.UIHelper.ensureStablePresentationUpdate.return.new.Promise): (window.UIHelper.ensureStablePresentationUpdate):
  • scrollingcoordinator/ios/fixed-scrolling-with-keyboard-expected.txt: Added.
  • scrollingcoordinator/ios/fixed-scrolling-with-keyboard.html: Added.

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

8:56 PM Changeset in webkit [247985] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247838. rdar://problem/53648220

WebKit/UIProcess/ios/WKContentViewInteraction.mm: error: implementing deprecated method contextMenuInteractionWillPresent
https://bugs.webkit.org/show_bug.cgi?id=200136
<rdar://problem/53547698>

Reviewed by Wenson Hsieh.

Ignore deprecation warnings for these UIContextMenuInteraction delegates.

  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView contextMenuInteractionWillPresent:]): (-[WKContentView contextMenuInteraction:willCommitWithAnimator:]): (-[WKContentView contextMenuInteractionDidEnd:]):

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

8:56 PM Changeset in webkit [247984] by Alan Coon
  • 30 edits in branches/safari-608-branch/Source

Cherry-pick r247837. rdar://problem/53648220

Add helper for ignoring deprecated implementation warnings
https://bugs.webkit.org/show_bug.cgi?id=200135

Reviewed by Wenson Hsieh.

Add ALLOW_DEPRECATED_IMPLEMENTATIONS_BEGIN/END macro which
is IGNORE_WARNINGS_BEGIN("deprecated-implementations")

Source/WebCore:

  • accessibility/mac/WebAccessibilityObjectWrapperMac.mm: (-[WebAccessibilityObjectWrapper ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:]): (-[WebAccessibilityObjectWrapper accessibilityIsAttributeSettable:]): (-[WebAccessibilityObjectWrapper accessibilityPerformAction:]): (-[WebAccessibilityObjectWrapper accessibilitySetValue:forAttribute:]): (-[WebAccessibilityObjectWrapper accessibilityActionDescription:]): (-[WebAccessibilityObjectWrapper accessibilityAttributeValue:forParameter:]): (-[WebAccessibilityObjectWrapper IGNORE_WARNINGS_END]): Deleted.
  • platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm: (-[WebAVStreamDataParserListener streamDataParserWillProvideContentKeyRequestInitializationData:forTrackID:]): (-[WebAVStreamDataParserListener streamDataParser:didProvideContentKeyRequestInitializationData:forTrackID:]):
  • platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm: (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveAuthenticationChallenge:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]):

Source/WebKit:

  • UIProcess/API/Cocoa/LegacyBundleForClass.mm:
  • UIProcess/API/Cocoa/WKBrowsingContextController.mm: (IGNORE_WARNINGS_BEGIN): Deleted.
  • UIProcess/API/Cocoa/WKBrowsingContextGroup.mm: (IGNORE_WARNINGS_BEGIN): Deleted.
  • UIProcess/API/Cocoa/WKConnection.mm: (IGNORE_WARNINGS_BEGIN): Deleted.
  • UIProcess/API/Cocoa/WKPreviewElementInfo.mm:
  • UIProcess/API/Cocoa/WKProcessGroup.mm: (IGNORE_WARNINGS_BEGIN): Deleted.
  • UIProcess/API/Cocoa/WKTypeRefWrapper.mm:
  • UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKWebView draggedImage:endedAt:operation:]): (-[WKWebView accessibilityAttributeValue:]): (-[WKWebView accessibilityAttributeValue:forParameter:]): (-[WKWebView namesOfPromisedFilesDroppedAtDestination:]): (-[WKWebView IGNORE_WARNINGS_END]): Deleted.
  • UIProcess/API/Cocoa/WKWebViewConfiguration.mm: (-[WKWebViewConfiguration ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKWebViewConfiguration _setWebsiteDataStore:]): (-[WKWebViewConfiguration IGNORE_WARNINGS_END]): Deleted.
  • UIProcess/API/Cocoa/_WKWebsiteDataStore.mm:
  • UIProcess/API/mac/WKView.mm: (-[WKView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKView draggedImage:endedAt:operation:]): (-[WKView accessibilityAttributeValue:]): (-[WKView accessibilityAttributeValue:forParameter:]): (-[WKView namesOfPromisedFilesDroppedAtDestination:]): (-[WKView IGNORE_WARNINGS_END]): Deleted.
  • UIProcess/WKImagePreviewViewController.mm: (-[WKImagePreviewViewController ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKImagePreviewViewController IGNORE_WARNINGS_END]): Deleted.
  • UIProcess/ios/forms/WKAirPlayRoutePicker.mm: (-[WKAirPlayRoutePicker popoverControllerDidDismissPopover:]):
  • UIProcess/ios/forms/WKFileUploadPanel.mm: (-[WKFileUploadPanel popoverControllerDidDismissPopover:]):
  • UIProcess/ios/forms/WKFormPopover.mm: (-[WKRotatingPopover popoverControllerDidDismissPopover:]):
  • WebProcess/Plugins/PDF/PDFPlugin.mm: (-[WKPDFPluginAccessibilityObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:]): (-[WKPDFPluginAccessibilityObject accessibilityAttributeValue:forParameter:]): (-[WKPDFPluginAccessibilityObject accessibilityPerformAction:]): (-[WKPDFPluginAccessibilityObject accessibilityIsAttributeSettable:]): (-[WKPDFPluginAccessibilityObject accessibilitySetValue:forAttribute:]): (-[WKPDFPluginAccessibilityObject IGNORE_WARNINGS_END]): Deleted.
  • WebProcess/WebPage/mac/WKAccessibilityWebPageObjectMac.mm: (-[WKAccessibilityWebPageObject ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WKAccessibilityWebPageObject accessibilityIsAttributeSettable:]): (-[WKAccessibilityWebPageObject accessibilitySetValue:forAttribute:]): (-[WKAccessibilityWebPageObject accessibilityAttributeValue:]): (-[WKAccessibilityWebPageObject accessibilityAttributeValue:forParameter:]): (-[WKAccessibilityWebPageObject IGNORE_WARNINGS_END]): Deleted.

Source/WebKitLegacy/mac:

  • Misc/WebDownload.mm: (-[WebDownload initWithRequest:delegate:]):
  • Misc/WebIconDatabase.mm:
  • Plugins/WebBaseNetscapePluginView.mm: (-[WebBaseNetscapePluginView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebBaseNetscapePluginView IGNORE_WARNINGS_END]): Deleted.
  • WebView/WebDynamicScrollBarsView.mm: (-[WebDynamicScrollBarsView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebDynamicScrollBarsView IGNORE_WARNINGS_END]): Deleted.
  • WebView/WebHTMLView.mm: (-[WebHTMLView draggingSourceOperationMaskForLocal:]): (-[WebHTMLView draggedImage:endedAt:operation:]): (-[WebHTMLView namesOfPromisedFilesDroppedAtDestination:]): (-[WebHTMLView accessibilityAttributeValue:]): (-[WebHTMLView ALLOW_DEPRECATED_IMPLEMENTATIONS_END]): (-[WebHTMLView characterIndexForPoint:]): (-[WebHTMLView firstRectForCharacterRange:]): (-[WebHTMLView attributedSubstringFromRange:]): (-[WebHTMLView setMarkedText:selectedRange:]): (-[WebHTMLView doCommandBySelector:]): (-[WebHTMLView insertText:]): (-[WebHTMLView IGNORE_WARNINGS_END]): Deleted.

Source/WTF:

  • wtf/Compiler.h:

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

8:55 PM Changeset in webkit [247983] by Alan Coon
  • 1 edit
    2 adds in branches/safari-608-branch/LayoutTests

Cherry-pick r247824. rdar://problem/53647626

Adding iOS-specific expectations for fast/text-indicator/text-indicator-with-low-contrast-text.html.
https://bugs.webkit.org/show_bug.cgi?id=200064

Unreviewed Test Gardening.

  • platform/ios/fast/text-indicator/text-indicator-with-low-contrast-text-expected.txt: Added.

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

8:55 PM Changeset in webkit [247982] by Alan Coon
  • 20 edits
    2 adds in branches/safari-608-branch

Cherry-pick r247822. rdar://problem/53648211

Avoid UI Process hangs when the WebContent process is showing JS prompts / alerts
https://bugs.webkit.org/show_bug.cgi?id=200107
<rdar://problem/53034592>

Reviewed by Geoffrey Garen.

Source/WebCore:

Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply.

Test: fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html

  • page/ChromeClient.h:
  • testing/Internals.cpp: (WebCore::Internals::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
  • testing/Internals.h:
  • testing/Internals.idl:

Source/WebKit:

  • Platform/IPC/Connection.cpp: (IPC::Connection::SyncMessageState::incrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::decrementProcessIncomingSyncMessagesWhenWaitingForSyncReplyCount): (IPC::Connection::SyncMessageState::processIncomingMessage): (IPC::Connection::sendSyncMessage):
  • Platform/IPC/Connection.h: Add support for new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag to allow processing incoming sync messages while sending a particular sync IPC. This is the default behavior in all processes except in the WebContent process, where we try to avoid re-entering to prevent bugs. This flag allows the WebContent process to change its default behavior for some specific IPCs, where we know it is safe to re-enter and where it benefits performance to re-renter.
  • NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
  • NetworkProcess/NetworkConnectionToWebProcess.h:
  • NetworkProcess/NetworkConnectionToWebProcess.messages.in:
  • UIProcess/Network/NetworkProcessProxy.cpp: (WebKit::NetworkProcessProxy::didReceiveSyncMessage): (WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
  • UIProcess/Network/NetworkProcessProxy.h:
  • UIProcess/Network/NetworkProcessProxy.messages.in:
  • WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
  • WebProcess/WebCoreSupport/WebChromeClient.h:
  • WebProcess/WebPage/WebPage.cpp: (WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
  • WebProcess/WebPage/WebPage.h: (WebKit::WebPage::sendSyncWithDelayedReply):
  • WebProcess/WebPage/WebPage.messages.in: SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply Add testing infrastructure for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag.
  • WebProcess/WebCoreSupport/WebChromeClient.cpp: (WebKit::WebChromeClient::runJavaScriptAlert): (WebKit::WebChromeClient::runJavaScriptConfirm): (WebKit::WebChromeClient::runJavaScriptPrompt): Use new SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply flag when sending the synchronous IPC for JS alerts / prompt / confirm. This allows the WebProcess to process incoming synchronous IPC for other processes (in particular the UIProcess) while it is blocked on those synchronous IPCs. It is safe to re-enter the WebContent process on these sync IPCs since they are triggered by JS and we return to JS right after. This should avoid UIProcess hangs when the UIProcess is sending a sync IPC to the WebContent process, which is itself stuck on the sync IPC to show a JS alert.

LayoutTests:

Add layout test coverage for SendSyncOption::ProcessIncomingSyncMessagesWhenWaitingForSyncReply.
Without the flag on the sendSync from the WebContent process of the
NetworkConnectionToWebProcess::TestProcessIncomingSyncMessagesWhenWaitingForSyncReply IPC, the
test would hang. This is because the WebContent process sends a sync IPC to the network process,
which in turns sends one to the UIProcess, which itself sends one back to the WebContent process.
This would attempt to re-enter the WebContent process which is currently sending a sync IPC, which
is not allowed by default.

  • fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt: Added.
  • fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html: Added.

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

8:55 PM Changeset in webkit [247981] by Alan Coon
  • 17 edits in branches/safari-608-branch

Cherry-pick r247817. rdar://problem/53648067

Unable to tap/double tap to open files/folders in Google Drive in Safari
https://bugs.webkit.org/show_bug.cgi?id=200096
<rdar://problem/52748552>

Reviewed by Wenson Hsieh.

Source/WebKit:

This patch reverts to the original double-tap-for-double-click implementation (see r244775 and r246347 for more information).

  • Shared/WebPageCreationParameters.cpp: (WebKit::WebPageCreationParameters::encode const): (WebKit::WebPageCreationParameters::decode):
  • Shared/WebPageCreationParameters.h:
  • UIProcess/PageClient.h:
  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::creationParameters):
  • UIProcess/WebPageProxy.h:
  • UIProcess/ios/PageClientImplIOS.h:
  • UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::doubleTapForDoubleClickDelay): Deleted. (WebKit::PageClientImpl::doubleTapForDoubleClickRadius): Deleted.
  • UIProcess/ios/WKContentViewInteraction.h:
  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView setupInteraction]): (-[WKContentView cleanupInteraction]): (-[WKContentView _removeDefaultGestureRecognizers]): (-[WKContentView _addDefaultGestureRecognizers]): (-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): Do not recognize the single and double gestures the same time. (-[WKContentView gestureRecognizerShouldBegin:]): (-[WKContentView _doubleTapRecognizedForDoubleClick:]): (-[WKContentView _didStartProvisionalLoadForMainFrame]): (-[WKContentView _ensureNonBlockingDoubleTapGestureRecognizer]): Deleted. (-[WKContentView _doubleTapForDoubleClickDelay]): Deleted. (-[WKContentView _doubleTapForDoubleClickRadius]): Deleted.
  • UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::handleDoubleTapForDoubleClickAtPoint):
  • WebProcess/WebPage/WebPage.cpp:
  • WebProcess/WebPage/WebPage.h:
  • WebProcess/WebPage/WebPage.messages.in:
  • WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::handleDoubleTapForDoubleClickAtPoint): (WebKit::WebPage::commitPotentialTap): (WebKit::WebPage::handlePotentialDoubleTapForDoubleClickAtPoint): Deleted.

LayoutTests:

Rebaseline.

  • fast/events/touch/ios/double-tap-for-double-click3-expected.txt:

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

8:55 PM Changeset in webkit [247980] by Alan Coon
  • 4 edits in branches/safari-608-branch/Source

Cherry-pick r247793. rdar://problem/53648076

Regression(r247400): Unable to log into AIB Mobile Banking App
https://bugs.webkit.org/show_bug.cgi?id=200094
<rdar://problem/52519818>

Reviewed by Brent Fulgham.

In r247400, a change was made to only set the 'app has universal sandbox access' flag
only when issueing the sandbox extension for / actually succeeded (it usually fails
in practice). Previously, AIB Mobile Banking app was relying on this behavior to
trigger a load for file:///login which is outside their container. However, now that
the 'app has universal sandbox access' flag is no longer set, it trips our security
checks and the load gets ignored.

To address the issue, apply only the 'app has universal sandbox access' flag fix with
a linked-on-after check.

  • UIProcess/Cocoa/VersionChecks.h:
  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::maybeInitializeSandboxExtensionHandle):

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

8:55 PM Changeset in webkit [247979] by Alan Coon
  • 8 edits
    2 adds in branches/safari-608-branch

Cherry-pick r247792. rdar://problem/53647626

Daring Fireball long press highlights are unnecessarily inflated due to false illegibility
https://bugs.webkit.org/show_bug.cgi?id=200064

Reviewed by Geoff Garen.

Source/WebCore:

If we consider text illegible on the given estimated background color,
we bail from doing a tightly fitted selection-only TextIndicator and
instead just paint the page without modification into the indicator,
causing ugly overlap and an excessively inflated indicator.

Change the mechanism we use to determine illegibility to be based on
a standard, instead of a constant chosen by hand 13 years ago.

Test: fast/text-indicator/text-indicator-with-low-contrast-text.html

  • platform/graphics/ColorUtilities.cpp: (WebCore::luminance): Fix a typo.

(WebCore::contrastRatio):
Add a function that computes the contrast ratio given two colors using
the formula from WCAG.

  • platform/graphics/ColorUtilities.h:
  • rendering/TextPaintStyle.cpp: (WebCore::textColorIsLegibleAgainstBackgroundColor): Make use of WCAG's minimum legible contrast ratio instead of an arbitrary color difference cutoff for determining whether we consider text legible. It seems sensible and also considers the text on DF readable (which it seems to be to me!).
  • testing/Internals.cpp: (WebCore::Internals::TextIndicatorInfo::TextIndicatorInfo):
  • testing/Internals.h:
  • testing/Internals.idl: Expose all of the text rects to Internals, not just the bounding rect. Expose some more TextIndicator options to Internals so that we can turn on the legibility mechanism.

LayoutTests:

  • fast/text-indicator/text-indicator-with-low-contrast-text-expected.txt: Added.
  • fast/text-indicator/text-indicator-with-low-contrast-text.html: Added.

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

8:55 PM Changeset in webkit [247978] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247791. rdar://problem/53647631

Module-enabled users of WKWebProcessPlugInFrame.h fail to build; duplicate declaration
https://bugs.webkit.org/show_bug.cgi?id=200095
<rdar://problem/53512407>

Reviewed by Wenson Hsieh.

  • WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInFrame.h: Import <JavaScriptCore/JavaScriptCore.h> (the module header) instead of <JavaScriptCore/JSContext.h> directly, otherwise we can end up getting JSContext.h included twice, to the compiler's chagrin.

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

8:55 PM Changeset in webkit [247977] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247787. rdar://problem/53647890

Crash in WebContent process with custom schemes.
<rdar://problem/52968793> and https://bugs.webkit.org/show_bug.cgi?id=200062

Reviewed by Andy Estes.

Almost everywhere in WebURLSchemeTaskProxy where we call processNextPendingTask() we first protect the task with a ref.
But not in didReceiveData.
So lets do that.

  • WebProcess/WebPage/WebURLSchemeTaskProxy.cpp: (WebKit::WebURLSchemeTaskProxy::didReceiveData): Protect this.

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

8:55 PM Changeset in webkit [247976] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247786. rdar://problem/53647457

Null check CompletionHandler in WebPreviewLoaderClient::didReceivePassword
https://bugs.webkit.org/show_bug.cgi?id=200080
<rdar://problem/37275772>

Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-24
Reviewed by Chris Dumez.

  • WebProcess/WebCoreSupport/ios/WebPreviewLoaderClient.cpp: (WebKit::WebPreviewLoaderClient::didReceivePassword):

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

8:55 PM Changeset in webkit [247975] by Alan Coon
  • 5 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247784. rdar://problem/53647468

Crash under WebKit:WTF::Detail::CallableWrapper<WebKit::ResourceLoadStatisticsMemoryStore::updateCookieBlocking(WTF::CompletionHandler<void ()>&&)::$_32::operator()()::'lambda'(), void>::call
https://bugs.webkit.org/show_bug.cgi?id=200071
<rdar://problem/53335583>

Reviewed by Brent Fulgham and Youenn Fablet.

The WebResourceLoadStatisticsStore is a main thread object. In its destructor, it was dispatching
to the background queue to destroy the m_statisticsStore / m_persistentStorage data members, which
live on the background queue. It would then synchronously wait for the background queue to finish
destroying them. The idea was to guarantee that the ResourceLoadStatisticsMemoryStore and the
ResourceLoadStatisticsPersistentStorage would never outlive the WebResourceLoadStatisticsStore,
given that they keep a raw pointer back to the WebResourceLoadStatisticsStore (via m_store data
member).

The issue is that *while* the WebResourceLoadStatisticsStore destructor is running on the main
thread, the background queue may be running code in ResourceLoadStatisticsMemoryStore or
ResourceLoadStatisticsPersistentStorage which refs the WebResourceLoadStatisticsStore, even
though its ref count has already reached 0. It is actually a common pattern in
ResourceLoadStatisticsMemoryStore to call RunLoop::main().dispatch() and ref their m_store in
the lambda, so that they can interact with the WebResourceLoadStatisticsStore.

To address the issue, we now destroy m_statisticsStore / m_persistentStorage *before* the
WebResourceLoadStatisticsStore destructor runs. The NetworkSession destructor now calls
WebResourceLoadStatisticsStore::didDestroyNetworkSession() which takes care of destroying
m_statisticsStore / m_persistentStorage on the background queue, synchronously. The
WebResourceLoadStatisticsStore destructor will only run later, once all remaining references
to it are gone.

  • NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::~WebResourceLoadStatisticsStore): (WebKit::WebResourceLoadStatisticsStore::didDestroyNetworkSession):
  • NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h:
  • NetworkProcess/NetworkSession.cpp: (WebKit::NetworkSession::~NetworkSession):

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

8:55 PM Changeset in webkit [247974] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247782. rdar://problem/53647473

SYS_pthread_markcancel is sometimes used by libwebrtc
https://bugs.webkit.org/show_bug.cgi?id=200087
<rdar://problem/53408606>

Reviewed by Brent Fulgham.

  • Resources/SandboxProfiles/ios/com.apple.WebKit.WebContent.sb: Whitelist this unix-call within WebProcess as libwebrtc uses it.

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

8:55 PM Changeset in webkit [247973] by Alan Coon
  • 6 edits in branches/safari-608-branch

Cherry-pick r247780. rdar://problem/53647618

ASSERTION FAILED: settings().textAutosizingEnabled() && settings().textAutosizingUsesIdempotentMode() in WebCore::Page::recomputeTextAutoSizingInAllFrames()
https://bugs.webkit.org/show_bug.cgi?id=200079
<rdar://problem/53474325>

Reviewed by Wenson Hsieh.

Source/WebKit:

Do not reset idempotent values when the text autosizing is off.

  • UIProcess/API/C/WKPreferences.cpp: (WKPreferencesSetTextAutosizingUsesIdempotentMode): (WKPreferencesGetTextAutosizingUsesIdempotentMode):
  • UIProcess/API/C/WKPreferencesRef.h:
  • WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded):

Tools:

Reset textAutosizingUsesIdempotentMode when transitioning to a new test.

  • WebKitTestRunner/ios/TestControllerIOS.mm: (WTR::TestController::platformResetPreferencesToConsistentValues):

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

8:55 PM Changeset in webkit [247972] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247779. rdar://problem/53647892

Add per-document autoplay quirk for netflix.com.
https://bugs.webkit.org/show_bug.cgi?id=200058

Reviewed by Eric Carlson.

Opt netflix.com into the desktop-style per-document autoplay quirk.

  • page/Quirks.cpp: (WebCore::Quirks::needsPerDocumentAutoplayBehavior const):

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

8:55 PM Changeset in webkit [247971] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247756. rdar://problem/53648073

Long press hint has half blue shape in Feedly.com
https://bugs.webkit.org/show_bug.cgi?id=200053
<rdar://problem/53323369>

Reviewed by Simon Fraser.

No new tests, because TextIndicator snapshots are not yet testable.

  • rendering/RenderLayer.cpp: (WebCore::RenderLayer::paintForegroundForFragments): Paint ChildBlockBackgrounds when painting selection AND backgrounds; only exclude it when doing a selection-only paint.

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

8:55 PM Changeset in webkit [247970] by Alan Coon
  • 11 edits in branches/safari-608-branch/Source

Cherry-pick r247755. rdar://problem/53575423

AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak
https://bugs.webkit.org/show_bug.cgi?id=199988

Reviewed by Per Arne Vollan.

Source/WebCore:

Implement the reset state to cancel current speech jobs.

  • Modules/speech/SpeechSynthesis.cpp: (WebCore::SpeechSynthesis::startSpeakingImmediately): (WebCore::SpeechSynthesis::cancel):
  • platform/PlatformSpeechSynthesizer.h:
  • platform/ios/PlatformSpeechSynthesizerIOS.mm: (WebCore::PlatformSpeechSynthesizer::resetState):
  • platform/mac/PlatformSpeechSynthesizerMac.mm: (WebCore::PlatformSpeechSynthesizer::resetState):

Source/WebKit:

Improvements to WebSpeechSynthesis to avoid crashing and improve correctness.

  • Reset and cancel speech jobs on page close or reload (otherwise the synthesizer keeps talking after your page is gone)
  • Have a separate speech finish callback mechanism, use the start speaking callback when the synthesizer tells us.
  • Move an assert on utterance state to only apply when we use the in process synthesizer.
  • UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::didStartSpeaking):
  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::resetSpeechSynthesizer): (WebKit::WebPageProxy::speechSynthesisSetFinishedCallback): (WebKit::WebPageProxy::speechSynthesisSpeak):
  • UIProcess/WebPageProxy.h:
  • UIProcess/WebPageProxy.messages.in:
  • WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp: (WebKit::WebSpeechSynthesisClient::speak):

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

8:55 PM Changeset in webkit [247969] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247734. rdar://problem/53575394

Fix crashes in ScrollingStateNode::insertChild()
https://bugs.webkit.org/show_bug.cgi?id=200023
rdar://problem/53265378

Reviewed by Darin Adler.

Crash data suggest that ScrollingStateNode::insertChild() can be passed an index that
is larger than the size of the vector, causing crashes.

Fix defensively by falling back to append() if the passed index is equal to or larger
than the size of the children vector.

  • page/scrolling/ScrollingStateNode.cpp: (WebCore::ScrollingStateNode::insertChild):

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

8:55 PM Changeset in webkit [247968] by Alan Coon
  • 5 edits
    2 adds in branches/safari-608-branch

Cherry-pick r247730. rdar://problem/53647886

Long press hint of AirPods buy buttons are tall and narrow during animation
https://bugs.webkit.org/show_bug.cgi?id=200036
<rdar://problem/53145697>

Reviewed by Wenson Hsieh.

Source/WebCore:

New test: fast/text-indicator/text-indicator-with-tiny-child.html

  • dom/Range.cpp: (WebCore::Range::borderAndTextRects const):
  • dom/Range.h: Add a BoundingRectBehavior that ignores 1x1 and smaller rects.
  • page/TextIndicator.cpp: (WebCore::absoluteBoundingRectForRange): Enable IgnoreTinyRects.

LayoutTests:

  • fast/text-indicator/text-indicator-with-tiny-child-expected.txt: Added.
  • fast/text-indicator/text-indicator-with-tiny-child.html: Added.

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

8:54 PM Changeset in webkit [247967] by Alan Coon
  • 14 edits
    3 adds in branches/safari-608-branch

Cherry-pick r247722. rdar://problem/53647293

[macOS 10.15] Web process crashes when attempting to show the font panel via Font > Show Fonts
https://bugs.webkit.org/show_bug.cgi?id=200021
<rdar://problem/53301325>

Reviewed by Ryosuke Niwa.

Source/WebCore:

In macOS 10.15, attempting to access ~/Library/FontCollections/ from the web process causes a Sandbox violation
and a subsequent crash. This can be triggered by trying to show the font panel via Font > Show Fonts in the
context menu after right clicking.

In the (near) future, we should fix this by moving logic to show the font panel, color panel and styles panel
from the Editor in the web process to the UI process in WebKit2. However, for the time being, we can just work
around this by adding a new EditorClient hook to determine whether to allow the font panel to show; this returns
true in the legacy macOS WebKit port, and false everywhere else.

Test: editing/mac/style/do-not-crash-when-showing-font-panel.html

  • editing/mac/EditorMac.mm: (WebCore::Editor::showFontPanel):
  • loader/EmptyClients.cpp:
  • page/EditorClient.h:

Source/WebKit:

Always return false from canShowFontPanel in WebKit2.

  • WebProcess/WebCoreSupport/WebEditorClient.h:

Source/WebKitLegacy/mac:

Implement a new editing client hook. In WebKit1, this always returns true on macOS and false on iOS.

  • WebCoreSupport/WebEditorClient.h:

Source/WebKitLegacy/win:

Implement a new editing client hook.

  • WebCoreSupport/WebEditorClient.h:

Tools:

Add support for grabbing the child menu items of a context menu item.

  • WebKitTestRunner/InjectedBundle/EventSendingController.cpp: (WTR::getMenuItemChildrenCallback):

LayoutTests:

Add a new layout test to verify that attempting to show the font panel doesn't crash the web process in WebKit2.
This test is skipped in WebKit1, since EventSender::contextClick() in WebKit1 only returns an array of strings
corresponding to the titles of each menu item.

  • editing/mac/style/do-not-crash-when-showing-font-panel-expected.txt: Added.
  • editing/mac/style/do-not-crash-when-showing-font-panel.html: Added.
  • platform/mac-wk1/TestExpectations:

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

8:54 PM Changeset in webkit [247966] by Alan Coon
  • 10 edits
    3 adds in branches/safari-608-branch

Cherry-pick r247720. rdar://problem/53647897

WebKit should strip away system font names from the pasted content
https://bugs.webkit.org/show_bug.cgi?id=199975
<rdar://problem/53336353>

Reviewed by Darin Adler.

Source/WebCore:

Cocoa HTML Writer sometimes generate system font names such as ".AppleSystemUIFont", ".SFUI-Regular", and ".SF UI Mono".
We need to strip away these font names upon paste to avoid these font names falling back to Times New Roman.

Added the code to strip these font names away in EditingStyle::mergeStyleFromRulesForSerialization, which is used by
StylizedMarkupAccumulator to generate HTML during copy. This works because WebContentReader::readWebArchive invokes
sanitizeMarkupWithArchive which inserts the pasteboard content into a temporary document then re-serializes back to HTML
using StylizedMarkupAccumulator before the actual pasting happens.

This approach has a few benefits over stripping away these font names in ReplaceSelectionCommand:

  1. It would only affect clients that opts-in to copy & paste sanitization. e.g. it won't affect legacy WebKit clients and those that opt out of pasteboard content sanitization.
  1. It preserves font names such as ".SF Blah" that a website may insert as some kind of house keeping purposes if ever. While we don't have any evidence that there is any such a website but it's a real risk nonetheless. The copy side fix would only affect cross-site and cross-app pasting, which is rare and less likely to affect real user scenarios.
  1. It avoids exposing bogus .Apple* or .SF* font names to websites that directly use event.clipboardData.getData. Indeed stripping away bogus markup like this is one of the key features / benefit of using copy & paste sanitization.

Test: editing/pasteboard/paste-cocoa-writer-markup-with-system-fonts.html

  • editing/EditingStyle.cpp: (WebCore::usesForbiddenSystemFontAsOnlyFontFamilyName): Added. (WebCore::EditingStyle::mergeStyleFromRulesForSerialization): Added the code to remove font-family property when needed.
  • platform/graphics/FontCache.h:
  • platform/graphics/cocoa/FontCacheCoreText.cpp: (WebCore::isSystemFont): Moved. (WebCore::FontCache::isSystemFontForbiddenForEditing): Added.
  • platform/graphics/freetype/FontCacheFreeType.cpp: (WebCore::FontCache::isSystemFontForbiddenForEditing): Added. Always returns false.
  • platform/graphics/win/FontCacheWin.cpp: (WebCore::FontCache::isSystemFontForbiddenForEditing): Ditto.

Tools:

Added a test to strip away system font names such as ".AppleSystemUIFont", ".SFUI-Regular", and ".SF UI Mono".

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WebKitCocoa/PasteHTML.mm:
  • TestWebKitAPI/Tests/WebKitCocoa/cocoa-writer-markup-with-system-fonts.html: Added.

LayoutTests:

Added a test for ClipboardData.getData returning the original markup and execCommand('insertHTML', ~)
not stripping away system font names.

  • editing/pasteboard/paste-cocoa-writer-markup-with-system-fonts-expected.txt: Added.
  • editing/pasteboard/paste-cocoa-writer-markup-with-system-fonts.html: Added.

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

8:54 PM Changeset in webkit [247965] by Alan Coon
  • 15 edits in branches/safari-608-branch/Source

Cherry-pick r247714. rdar://problem/53647616

[bmalloc] Each IsoPage gets 1MB VA because VMHeap::tryAllocateLargeChunk rounds up
https://bugs.webkit.org/show_bug.cgi?id=200024

Reviewed by Saam Barati.

Source/bmalloc:

When we allocate IsoHeap's page, we reused VMHeap::tryAllocateLargeChunk. However, this function is originally designed
to be used for Large allocation in bmalloc (e.g. allocating Chunk in bmalloc). As a result, this function rounds up the
requested size with 1MB (bmalloc::chunkSize). As a result, all IsoHeap's 16KB page gets 1MB VA while it just uses 16KB of
the allocated region. This leads to VA exhaustion since IsoHeap now uses 64x VA than we expected!

This patch fixes the above VA exhaustion issue by allocating a page by using tryVMAllocate. When allocating a page, we start
using a VM tag for IsoHeap. We discussed at e-mail and we decided reusing a VM tag previously assigned to CLoop Stack since
this is less profitable. Since this tag is not Malloc-related tag, Leaks tool can scan memory region conservatively without
registering allocated region into Zone, which was previously done in VMHeap and that's why we reused VMHeap for IsoHeap.

  • bmalloc/BVMTags.h:
  • bmalloc/IsoPage.cpp: (bmalloc::IsoPageBase::allocatePageMemory):
  • bmalloc/IsoTLS.cpp: (bmalloc::IsoTLS::ensureEntries):
  • bmalloc/VMAllocate.h: (bmalloc::vmAllocate):

Source/JavaScriptCore:

Discussed and we decided to use this VM tag for IsoHeap instead of CLoop stack.

  • interpreter/CLoopStack.cpp: (JSC::CLoopStack::CLoopStack):

Source/WebCore:

Changed how we interpret VM tags. Add IsoHeap VM tag support, and rename WebAssembly tag
to Gigacage tag.

  • page/ResourceUsageData.h:
  • page/ResourceUsageOverlay.h:
  • page/cocoa/ResourceUsageOverlayCocoa.mm: (WebCore::HistoricResourceUsageData::HistoricResourceUsageData):
  • page/cocoa/ResourceUsageThreadCocoa.mm: (WebCore::displayNameForVMTag): (WebCore::categoryForVMTag):

Source/WTF:

Start using a VM tag for IsoHeap instead of CLoop Stack.

  • wtf/OSAllocator.h:
  • wtf/VMTags.h:

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

8:54 PM Changeset in webkit [247964] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/JavaScriptCore

Cherry-pick r247713. rdar://problem/53648241

Turn off Wasm fast memory on iOS
https://bugs.webkit.org/show_bug.cgi?id=200016
<rdar://problem/53417726>

Reviewed by Yusuke Suzuki.

We turned them on when we disabled Gigacage on iOS. However, we re-enabled
Gigacage on iOS, but forgot to turn wasm fast memories back off.

  • runtime/Options.h:

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

8:54 PM Changeset in webkit [247963] by Alan Coon
  • 3 edits
    2 adds in branches/safari-608-branch

Cherry-pick r247712. rdar://problem/53647280

Fix WebView iframe rendering in macOS Catalina
https://bugs.webkit.org/show_bug.cgi?id=200022
rdar://problem/49102040

Reviewed by Darin Adler.
Source/WebKitLegacy/mac:

Adapt to internal NSView method renames in Catalina.

  • WebView/WebHTMLView.mm: (-[WebHTMLView _recursive:displayRectIgnoringOpacity:inContext:stopAtLayerBackedViews:_recursive:displayRectIgnoringOpacity:inContext:shouldChangeFontReferenceColor:stopAtLayerBackedViews:_recursive:displayRectIgnoringOpacity:inContext:shouldChangeFontReferenceColor:_recursive:displayRectIgnoringOpacity:inContext:topView:]): (-[WebHTMLView _recursive:displayRectIgnoringOpacity:inContext:shouldChangeFontReferenceColor:stopAtLayerBackedViews:_recursive:displayRectIgnoringOpacity:inContext:shouldChangeFontReferenceColor:_recursive:displayRectIgnoringOpacity:inContext:topView:]): Deleted.

LayoutTests:

New test for rendering of overlapping iframes, defects when we fail to setAsideSubviews
in WebView.

  • fast/frames/frames-not-double-painted-expected.html: Added.
  • fast/frames/frames-not-double-painted.html: Added.

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

8:54 PM Changeset in webkit [247962] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/bmalloc

Cherry-pick r247711. rdar://problem/53647462

Unreviewed, follow-up fix for tls->size() access
https://bugs.webkit.org/show_bug.cgi?id=200019

  • bmalloc/IsoTLS.cpp: (bmalloc::IsoTLS::ensureEntries): (bmalloc::IsoTLS::destructor):

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

8:54 PM Changeset in webkit [247961] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/bmalloc

Cherry-pick r247709. rdar://problem/53647462

[bmalloc] IsoTLS is not deallocated in TLS destructor
https://bugs.webkit.org/show_bug.cgi?id=200019

Reviewed by Mark Lam.

TLS destructor for IsoTLS needs to deallocate memory used for IsoTLS itself.
While we are correctly deallocating old IsoTLS when extending it to the new one,
we lack deallocation when the thread is destroyed. IsoTLS is per-thread, so we
should destroy IsoTLS when a thread finishes.

  • bmalloc/IsoTLS.cpp: (bmalloc::IsoTLS::ensureEntries): (bmalloc::IsoTLS::destructor):

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

8:54 PM Changeset in webkit [247960] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKitLegacy/mac

Cherry-pick r247708. rdar://problem/53648010

Enable CSSOMViewScrollingAPIEnabled in WebKit1
https://bugs.webkit.org/show_bug.cgi?id=200008
rdar://problem/53409062

Reviewed by Tim Horton.

Default WebKitCSSOMViewScrollingAPIEnabledPreferenceKey to YES, so that
CSSOMViewScrollingAPIEnabled is on for both WebKit1 and WebKit2.

DumpRenderTree already turns this preference on, so this change is not
detected by tests.

  • WebView/WebPreferences.mm: (+[WebPreferences initialize]):

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

8:54 PM Changeset in webkit [247959] by Alan Coon
  • 5 edits in branches/safari-608-branch

Cherry-pick r247703. rdar://problem/53647465

[JSC] Make DFG Local CSE and AI conservative for huge basic block
https://bugs.webkit.org/show_bug.cgi?id=199929
<rdar://problem/49309924>

Reviewed by Filip Pizlo.

In CNN page, the main thread hangs several seconds. On less-powerful devices (like iPhone7), it hangs for ~11 seconds. This is not an acceptable behavior.
The reason of this is that the DFG compiler takes too long time in the compilation for a particular function. It takes 8765 ms even in powerful x64 machine!
DFG compiler is concurrent one. However, when GC requires all the peripheral threads to be stopped, the main thread needs to wait for the DFG compiler's stop.
DFG compiler stops at GC safepoints, and they are inserted between DFG phases. So, if some of DFG phases take very long time, the main thread is blocked during that.
As a result, the main thread is blocked due to this pathological compilation.

By measuring the time taken in each DFG phase, we found that our AI and CSE phase have a problem having quadratic complexity for # of DFG nodes in a basic block.
In this patch, we add a threshold for # of DFG nodes in a basic block. If a basic block exceeds this threshold, we use conservative but O(1) algorithm for AI and Local CSE phase.
We did not add this threshold for Global CSE since FTL has another bytecode cost threshold which prevents us from compiling the large functions. But on the other hand,
DFG should compile them because DFG is intended to be a fast compiler even for a bit larger CodeBlock.

We first attempted to reduce the threshold for DFG compilation. We are using 100000 bytecode cost for DFG compilation and it is very large. However, we found that bytecode cost
is not the problem in CNN page. The problematic function has 67904 cost, and it takes 8765 ms in x64 machine. However, JetStream2/octane-zlib has 61949 function and it only takes
~400 ms. This difference comes from the # of DFG nodes in a basic block. The problematic function has 43297 DFG nodes in one basic block and it makes AI and Local CSE super time-consuming.
Rather than relying on the bytecode cost which a bit indirectly related to this pathological compile-time, we should look into # of DFG nodes in a basic block which is more directly
related to this problem. And we also found that 61949's Octane-zlib function is very critical for performance. This fact makes a bit hard to pick a right threshold: 67904 causes the problem,
and 61949 must be compiled. This is why this patch is introducing conservative analysis instead of adjusting the threshold for DFG.

This patch has two changes.

  1. DFG AI has structure transition tracking which has quadratic complexity

Structure transition tracking takes very long time since its complexity is O(N2) where N is # of DFG nodes in a basic block.
CNN has very pathological script and it shows 43297 DFG nodes. We should reduce the complexity of this algorithm.
For now, we just say "structures are clobbered" if # of DFG nodes in a basic block exceeds the threshold (20000).
We could improve the current algorithm from O(N
2) to O(2N) without being conservative, and I'm tracking this in [1].

  1. DFG Local CSE has quadratic complexity

Local CSE's clobbering iterates all the impure heap values to remove the clobbered one. Since # of impure heap values tend to be proportional to # of DFG nodes we visited,
each CSE for a basic block gets O(N2) complexity. To avoid this, we introduce HugeMap. This has the same interface to LargeMap and SmallMap in CSE, but its clobbering
implementation just clears the map completely. We can further make this O(N) without introducing conservative behavior by using epochs. For now, we do not see such a huge basic block in
JetStream2 and Speedometer2 so I'll track it in a separate bug[2].

This patch reduces the compilation time from ~11 seconds to ~200 ms.

[1]: https://bugs.webkit.org/show_bug.cgi?id=199959
[2]: https://bugs.webkit.org/show_bug.cgi?id=200014

  • dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransition): (JSC::DFG::AbstractInterpreter<AbstractStateType>::observeTransitions):
  • dfg/DFGCSEPhase.cpp:
  • runtime/Options.h:

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

8:54 PM Changeset in webkit [247958] by Alan Coon
  • 7 edits
    1 add in branches/safari-608-branch

Cherry-pick r247702. rdar://problem/53575409

[iOS] [WK1] UIWebView always jumps to the top left corner when scrolling to reveal the selection
https://bugs.webkit.org/show_bug.cgi?id=200013
<rdar://problem/52526901>

Reviewed by Simon Fraser.

Source/WebCore:

After <https://trac.webkit.org/r244141>, we no longer attempt to scroll to reveal the text selection in
UIWebView after changing the selection, due to how we use the legacy document view rect in legacy WebKit when
computing the visual viewport. This causes the viewRect in RenderLayer::scrollRectToVisible to be the same size
as the content size, which then causes us to always scroll to the origin when revealing the selection.

To make selection revealing work again in legacy WebKit, conditionally restore the old behavior of using the
unobscured content rect as the view rect, only in the case where scrolling is delegated and the platform widget
is present.

Test: WebKitLegacy.ScrollToRevealSelection

  • page/FrameView.cpp: (WebCore::FrameView::viewRectExpandedByContentInsets const): (WebCore::FrameView::visualViewportRectExpandedByContentInsets const): Deleted.

Additionally rename visualViewportRectExpandedByContentInsets to viewRectExpandedByContentInsets, to reflect the
fact that this may either be the visual viewport rect or unobscured content rect.

  • page/FrameView.h:
  • rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible):

Tools:

Add a new API test to verify that inserting text in UIWebView causes the document to scroll.

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WebKitLegacy/ios/ScrollToRevealSelection.mm: Added. (-[LegacyLoadingDelegate webViewDidFinishLoad:]): (-[LegacyLoadingDelegate waitForDidFinishLoad]):
  • TestWebKitAPI/ios/UIKitSPI.h:

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

8:54 PM Changeset in webkit [247957] by Alan Coon
  • 8 edits
    3 adds in branches/safari-608-branch

Cherry-pick r247698. rdar://problem/53647459

Make sure the player underlying volume is correctly set after creating a new player
https://bugs.webkit.org/show_bug.cgi?id=199974
<rdar://problem/52762559>

Reviewed by Eric Carlson.

Source/WebCore:

When creating a player before starting to play, the volume might not be correctly initialized.
Fix that by updating the volume like done for rate and muted state.
A future refactoring should probably move that code in MediaPlayer.

Add an internal API to query the volume value from the underlying player.

Test: http/tests/media/audio-volume-zero.html

  • html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::updateVolume): (WebCore::HTMLMediaElement::updatePlayState): (WebCore::HTMLMediaElement::effectiveVolume const): (WebCore::HTMLMediaElement::effectiveMuted const):
  • html/HTMLMediaElement.h:
  • testing/Internals.cpp: (WebCore::Internals::privatePlayerVolume):
  • testing/Internals.h:
  • testing/Internals.idl:
  • testing/Internals.mm: (WebCore::Internals::privatePlayerVolume):

LayoutTests:

  • http/tests/media/128kbps-44khz.mp3: Added.
  • http/tests/media/audio-volume-zero-expected.txt: Added.
  • http/tests/media/audio-volume-zero.html: Added.

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

8:54 PM Changeset in webkit [247956] by Alan Coon
  • 4 edits
    1 add in branches/safari-608-branch

Cherry-pick r247695. rdar://problem/53648210

REGRESSION(rUnknown): YouTube playback pauses when switching to a new tab
https://bugs.webkit.org/show_bug.cgi?id=199971
<rdar://problem/51951218>

Reviewed by Alex Christensen.

Source/WebKit:

When we get a message notifying us that the view has been removed from the window, we unconditionally
ask the fullscreen manager to exit fullscreen, which has the side effect (on iOS) of pausing the video
unconditionally. Only ask the fullscreen manager to exit fullscreen if there is actually a video in
fullscreen mode.

  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::viewDidLeaveWindow):

Tools:

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WebKitCocoa/NoPauseWhenSwitchingTabs.mm: Added. (TestWebKitAPI::TEST):

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

8:54 PM Changeset in webkit [247955] by Alan Coon
  • 5 edits in branches/safari-608-branch

Cherry-pick r247692. rdar://problem/53519917

Disable MediaRecorder for legacy WebKit
https://bugs.webkit.org/show_bug.cgi?id=200001
<rdar://problem/53400030>

Reviewed by Eric Carlson.

Source/WebKitLegacy/mac:

Disable MediaRecorder by default in legacy WebKit.
Add SPI to set/get this preference.

  • WebView/WebPreferences.mm: (+[WebPreferences initialize]): (-[WebPreferences _mediaRecorderEnabled]): (-[WebPreferences _setMediaRecorderEnabled:]):
  • WebView/WebPreferencesPrivate.h:

Tools:

Enable MediaRecorder for testing purposes.

  • DumpRenderTree/mac/DumpRenderTree.mm: (createWebViewAndOffscreenWindow):

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

8:54 PM Changeset in webkit [247954] by Alan Coon
  • 5 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247687. rdar://problem/53648060

[iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused
https://bugs.webkit.org/show_bug.cgi?id=199807
<rdar://problem/52760259>

Fix a bad merge of r247653. svn-apply was way too forgiving. The original patch touched
the non-existent function, -_didCommitLoadForMainFrame in WKContentViewInteraction.mm. Because
that didn't exist, svn-apply patched up -clearSelection.

  • UIProcess/ios/WKContentView.h:
  • UIProcess/ios/WKContentView.mm: (-[WKContentView _didCommitLoadForMainFrame]): Deleted; moved to WKContentViewInteraction.mm
  • UIProcess/ios/WKContentViewInteraction.h:
  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView clearSelection]): Remove code that should be in -_didCommitLoadForMainFrame. (-[WKContentView _didCommitLoadForMainFrame]): Moved from WKContentView.mm

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

8:54 PM Changeset in webkit [247953] by Alan Coon
  • 8 edits in branches/safari-608-branch

Cherry-pick r247679. rdar://problem/53648080

[iOS] [WebKit2] Add limited support for -isPosition:atBoundary:inDirection: in WKContentView
https://bugs.webkit.org/show_bug.cgi?id=199993
<rdar://problem/49523528>

Reviewed by Beth Dakin.

Source/WebKit:

Add support for -isPosition:atBoundary:inDirection:, only in the cases where the given position is the start or
and position and the given granularity is UITextGranularityParagraph.

Test: EditorStateTests.ParagraphBoundary

  • Shared/EditorState.cpp: (WebKit::EditorState::PostLayoutData::encode const): (WebKit::EditorState::PostLayoutData::decode):
  • Shared/EditorState.h:

Add a couple of bits to indicate whether the selection start or end positions are at paragraph boundaries.

  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView isPosition:atBoundary:inDirection:]):

Implement this to return selectionStartIsAtParagraphBoundary or selectionEndIsAtParagraphBoundary.

  • WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::platformEditorState const):

Tools:

Add a new API test to verify the behavior of -isPosition:atBoundary:inDirection:.

  • TestWebKitAPI/Tests/WebKitCocoa/EditorStateTests.mm: (TestWebKitAPI::TEST):
  • TestWebKitAPI/cocoa/TestWKWebView.h:

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

8:54 PM Changeset in webkit [247952] by Alan Coon
  • 10 edits in branches/safari-608-branch/Source

Cherry-pick r247667. rdar://problem/53647463

[Text autosizing] Do not nuke the style on dynamicViewportSizeUpdate
https://bugs.webkit.org/show_bug.cgi?id=199718
<rdar://problem/53344961>

Reviewed by Simon Fraser.

Source/WebCore:

When the page scale changes (e.g. as the result of shink to fit mode) we need to visit all the text content on the page and check whether they need to be boosted.
Currently we call setNeedsRecalcStyleInAllFrames() to accomplish it. Unfortunatelly setNeedsRecalcStyleInAllFrames destroys all the style information which means that the
subsequent styleResolve() needs to start from scratch.
This patch addresses this issue by directly adjusting the computed style information when text boosting is required and schedules layout accordingly. We also trigger this style adjusting
on a timer so that rapid dynamicViewportSizeUpdate() calls won't trigger redundant layouts.

  • css/StyleResolver.cpp: (WebCore::hasTextChild): (WebCore::StyleResolver::adjustRenderStyleForTextAutosizing): (WebCore::hasTextChildren): Deleted.
  • css/StyleResolver.h:
  • page/FrameView.h:
  • page/Page.cpp: (WebCore::Page::invalidateTextAutoSizeInAllFrames):
  • page/Page.h:

Source/WebKit:

  • WebProcess/WebPage/WebPage.cpp: (WebKit::m_textAutoSizingAdjustmentTimer): (WebKit::WebPage::close): (WebKit::WebPage::didCommitLoad): (WebKit::WebPage::textAutoSizingAdjustmentTimerFired): (WebKit::m_shrinkToFitContentTimer): Deleted.
  • WebProcess/WebPage/WebPage.h:
  • WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::dynamicViewportSizeUpdate): (WebKit::WebPage::resetIdempotentTextAutosizingIfNeeded): (WebKit::WebPage::resetTextAutosizing): (WebKit::WebPage::viewportConfigurationChanged):

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

8:54 PM Changeset in webkit [247951] by Alan Coon
  • 16 edits in branches/safari-608-branch/Source

Cherry-pick r247662. rdar://problem/53648208

Remote WebInspector should enable mock capture devices in UIProcess if doing it in WebProcess
https://bugs.webkit.org/show_bug.cgi?id=199924
<rdar://problem/50552067>

Reviewed by Devin Rousso.

Source/WebCore:

Add necessary API to set mock capture devices override.
In case of desynchronization between webprocess and uiprocess, make sure to return early
and fail capture instead of crashing.

  • inspector/InspectorClient.h: (WebCore::InspectorClient::setMockCaptureDevicesEnabled):
  • inspector/agents/InspectorPageAgent.cpp: (WebCore::InspectorPageAgent::disable): (WebCore::InspectorPageAgent::overrideSetting):
  • platform/mock/MockRealtimeMediaSourceCenter.cpp:

Source/WebKit:

Add IPC plumbery to pass inspector override value for mock capture devices.
Add an override in UserMediaPermissionRequestManagerProxy so that the value stays in sync with web inspector.
The override will be removed when web inspector goes away.

  • UIProcess/UserMediaPermissionRequestManagerProxy.cpp: (WebKit::UserMediaPermissionRequestManagerProxy::syncWithWebCorePrefs const):
  • UIProcess/UserMediaPermissionRequestManagerProxy.h: (WebKit::UserMediaPermissionRequestManagerProxy::setMockCaptureDevicesEnabledOverride):
  • UIProcess/WebInspectorProxy.cpp: (WebKit::WebInspectorProxy::setMockCaptureDevicesEnabled):
  • UIProcess/WebInspectorProxy.h:
  • UIProcess/WebInspectorProxy.messages.in:
  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::setMockCaptureDevicesEnabledOverride):
  • UIProcess/WebPageProxy.h:
  • WebProcess/WebCoreSupport/WebInspectorClient.cpp: (WebKit::WebInspectorClient::setMockCaptureDevicesEnabled):
  • WebProcess/WebCoreSupport/WebInspectorClient.h:
  • WebProcess/WebPage/WebInspector.cpp: (WebKit::WebInspector::setMockCaptureDevicesEnabled):
  • WebProcess/WebPage/WebInspector.h:

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

8:53 PM Changeset in webkit [247950] by Alan Coon
  • 3 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247657. rdar://problem/53648058

Provide correct names for UIContextMenuInteraction API replacements
https://bugs.webkit.org/show_bug.cgi?id=199966

Reviewed by Tim Horton.

We had some old incorrect names for replacements to SPI. While
here, I reordered and expanded the documentation for the new API.

  • UIProcess/API/Cocoa/WKUIDelegate.h:
  • UIProcess/API/Cocoa/WKUIDelegatePrivate.h:

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

8:53 PM Changeset in webkit [247949] by Alan Coon
  • 4 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247656. rdar://problem/53648229

[iOS WK2] Allow scrolling interaction on frames and oveflow scroll even when the main frame is rubber-banding
https://bugs.webkit.org/show_bug.cgi?id=199963
rdar://problem/52897797

Reviewed by Tim Horton.

Adopt UIKit SPI to allow for scrolling of inner UIScrollViews when the outer one is still rubber-banding.

  • Platform/spi/ios/UIKitSPI.h:
  • UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]):
  • UIProcess/RemoteLayerTree/ios/ScrollingTreeScrollingNodeDelegateIOS.mm: (WebKit::ScrollingTreeScrollingNodeDelegateIOS::commitStateAfterChildren):

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

8:53 PM Changeset in webkit [247948] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247653. rdar://problem/53648060

[iOS] REGRESSION (r241734): Autocorrection highlight should hide when field becomes defocused
https://bugs.webkit.org/show_bug.cgi?id=199807
<rdar://problem/52760259>

Reviewed by Wenson Hsieh.

Sometimes the correction highlight may not hide when defocusing an editable field.
This occurs only when a person pressed a key in a non-editable element beforehand.
We need to reset some state to force a re-computation of whether a keyboard is still
needed whenever an element is defocused (blurred in web paralance).

Following r241734 both editable and non-editable key events are handled using the same
code path. This is accomplished by having WKContentView's -_requiresKeyboardWhenFirstResponder
return YES to tell UIKit it needs a keyboard even when there is no editable element focused.
As a result UIKit retains all the keyboard state, including keeping the correction highlight
visible. Prior to r241734 WKContentView's -_requiresKeyboardWhenFirstResponder would not return
YES when a non-editable element was focused and hence UIKit would tear down the keyboard
and its state, including the correction highlight. In r245154, we made keyboard instantiate
for a focused non-editable element lazy as a performance optimization. Although r245154
kept the r241734 behavior (just made it lazy) it re-wrote the code in such a way that we
can utilize it as a hook to fix this bug. In particular, we now clear the bit about a
seen keydown in a non-editable element whenever we are defocusing an editable element
before we reload the input views, as part of hiding the keyboard. On the reload, UIKit
will call -_requiresKeyboardWhenFirstResponder, WebKit will respond with NO now that
a non-editable element is focused and hence UIKit will do what it did pre r241734: tear
down the keyboard.

  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _didCommitLoadForMainFrame]): Clear the bit about a seen keydown here so that we don't keep the keyboard around on a new page commit. This includes the case when the same page is reloaded. There is not much advantage to keeping the keyboard around across reloads and not doing so will reduce our memory footprint. (-[WKContentView _elementDidBlur]): Clear the same bit as well when defocusing an editable element. This will cause UIKit to tear down the keyboard on reload removing the correction highlight.

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

8:53 PM Changeset in webkit [247947] by Alan Coon
  • 5 edits
    2 adds in branches/safari-608-branch

Cherry-pick r247651. rdar://problem/53648007

[iOS] Entering 2FA code on idmsa.apple.com causes unexpected scrolling
https://bugs.webkit.org/show_bug.cgi?id=199949
<rdar://problem/49944428>

Reviewed by Tim Horton and Megan Gardner.

Source/WebKit:

Since at least iOS 11, -[UIScrollView _adjustForAutomaticKeyboardInfo:animated:lastAdjustment:] adjusts the
scroll view's content offset to account for updated keyboard bottom insets. In WebKit, we call this method
whenever keyboard geometry changes (based on system notifications, such as UIKeyboardWillHideNotification).

When switching between focused form fields, we hide the keyboard for the previous focused element prior to
showing the keyboard for the newly focused element. This means that we will actually dismiss the keyboard in the
process of changing the focused element, which posts keyboard geometry notifications, which causes us to scroll
WKScrollView.

On iOS 12, this would be immediately followed by re-presenting the keyboard for the new focused element, which
causes us to adjust the scroll view back to its original position right away; this means that the scrolling that
happens as a result of adjusting for the keyboard insets after dismissal doesn't result in any visible change.

However, on iOS 13, after r239441 and r244546, we now defer scrolling and zooming to reveal the focused element
until later; this means the scrolling that happens as a result of initially dismissing the keyboard now causes a
consistent jump in the scroll view's scroll position (whereas on iOS 12, this only happens rarely, and the jump
is also less noticeable).

To mitigate this, we detect the case where we're moving focus from one element to another; if we're about to
show a keyboard for the newly focused element, then we should avoid scrolling as a result of the impending
"keyboard will hide" notification.

Test: fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html

  • UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _keyboardChangedWithInfo:adjustScrollView:]): (-[WKWebView _keyboardWillHide:]):
  • UIProcess/ios/WKContentViewInteraction.h:
  • UIProcess/ios/WKContentViewInteraction.mm: (shouldShowKeyboardForElement):

Add a helper to determine whether we're focusing an element which presents a "keyboard" (i.e. a UIKit input
view, as opposed to modal select pickers, modal date pickers, or fields with inputmode="none", for which we
don't show an input view).

(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):
(-[WKContentView shouldIgnoreKeyboardWillHideNotification]):

LayoutTests:

Add a new layout test to verify that moving focus between horizontally adjacent form controls doesn't induce
vertical scrolling.

  • fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields-expected.txt: Added.
  • fast/forms/ios/no-scrolling-when-moving-focus-between-adjacent-fields.html: Added.

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

8:53 PM Changeset in webkit [247946] by Alan Coon
  • 3 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247649. rdar://problem/53647611

IndexedDB: error in starting version change transaction may be neglected
https://bugs.webkit.org/show_bug.cgi?id=199818
<rdar://problem/52925738>

Reviewed by Brady Eidson.

For version change transaction, IDBServer didn't wait the result of beginTransaction on the background thread
before giving the IDBClient the result of open request. In this case, beginTransaction may fail to update the
DatabaseVersion in database file or set m_originalDatabaseInfoBeforeVersionChange, but the transaction was
marked as started. When we later set m_databaseInfo with m_originalDatabaseInfoBeforeVersionChange,
m_databaseInfo could become nullptr.

To write a test for this, we will need to simulate an SQLite error. I manually tested this by crafting the
SQLiteStatement in beginTransaction, making it an invalid statement, and verified that error event, instead of
ungradeneeded event is dispatched to the IDBRequest.

  • Modules/indexeddb/server/UniqueIDBDatabase.cpp: (WebCore::IDBServer::UniqueIDBDatabase::startVersionChangeTransaction): (WebCore::IDBServer::UniqueIDBDatabase::performStartVersionChangeTransaction): (WebCore::IDBServer::UniqueIDBDatabase::didPerformStartVersionChangeTransaction): (WebCore::IDBServer::UniqueIDBDatabase::immediateCloseForUserDelete): (WebCore::IDBServer::UniqueIDBDatabase::beginTransactionInBackingStore): Deleted.
  • Modules/indexeddb/server/UniqueIDBDatabase.h:

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

8:53 PM Changeset in webkit [247945] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r247635. rdar://problem/53647467

Fix warning when importing WebKit in Swift
https://bugs.webkit.org/show_bug.cgi?id=199914
<rdar://problem/52854930>

Patch by Alex Christensen <achristensen@webkit.org> on 2019-07-18
Reviewed by Wenson Hsieh.

  • UIProcess/API/Cocoa/NSAttributedString.h: Declare NSAttributedString and update a swift name. This fix was proposed by Argyrios Kyrtzidis.

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

8:53 PM Changeset in webkit [247944] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247627. rdar://problem/53648213

Enable simulated mouse events quirk for soundcloud.com
https://bugs.webkit.org/show_bug.cgi?id=199908
<rdar://problem/52915981>

Patch by Antoine Quint <Antoine Quint> on 2019-07-18
Reviewed by Brent Fulgham.

Scrubbing on soundcloud.com relies on mouse events alone when displaying on iPad with the desktop UA string.
Opting into the simulated mouse events quirk makes scrubbing work and we also ensure that page scrolling is
disabled as a result of scrubbing by returning true in shouldDispatchedSimulatedMouseEventsAssumeDefaultPrevented().

Also making a drive-by fix in shouldDispatchedSimulatedMouseEventsAssumeDefaultPrevented() to use a reference
instead of a pointer when downcasting a null-checked pointer.

  • page/Quirks.cpp: (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): (WebCore::Quirks::shouldDispatchedSimulatedMouseEventsAssumeDefaultPrevented const):

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

8:53 PM Changeset in webkit [247943] by Alan Coon
  • 3 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247621. rdar://problem/53648017

Ensure Quirks::shouldDispatchSimulatedMouseEvents() works for all Google Maps and Amazon domains
https://bugs.webkit.org/show_bug.cgi?id=199904
<rdar://problem/53250104>

Reviewed by Dean Jackson.

Use topPrivatelyControlledDomain() to determine whether the URL is a Google or Amazon domain so as to apply
Google Maps and Amazon quirks to all the various domain names used.

  • page/Quirks.cpp: (WebCore::Quirks::isAmazon const): (WebCore::Quirks::isGoogleMaps const): (WebCore::Quirks::shouldDispatchSimulatedMouseEvents const): (WebCore::Quirks::simulatedMouseEventTypeForTarget const):
  • page/Quirks.h:

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

8:53 PM Changeset in webkit [247942] by Alan Coon
  • 2 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r247620. rdar://problem/53519929

Crash under WebPage::boundaryEventOccurred
https://bugs.webkit.org/show_bug.cgi?id=199907

Reviewed by Chris Fleizach.

Add null pointer checks.

No new tests, since I have not been able to reproduce this in a test.

  • Modules/speech/SpeechSynthesis.cpp: (WebCore::SpeechSynthesis::didStartSpeaking): (WebCore::SpeechSynthesis::didFinishSpeaking): (WebCore::SpeechSynthesis::didPauseSpeaking): (WebCore::SpeechSynthesis::didResumeSpeaking): (WebCore::SpeechSynthesis::speakingErrorOccurred): (WebCore::SpeechSynthesis::boundaryEventOccurred):

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

8:44 PM Changeset in webkit [247941] by Wenson Hsieh
  • 11 edits
    2 adds in trunk

Add layout test coverage for <https://webkit.org/b/200215>
https://bugs.webkit.org/show_bug.cgi?id=200245
<rdar://problem/52976965>

Reviewed by Tim Horton.

Tools:

Add new testing infrastructure. See below for more details.

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

(WTR::UIScriptController::setWillCreateNewPageCallback):
(WTR::UIScriptController::willCreateNewPageCallback const):

Add platform-agnostic UIScriptController callback hooks to notify a test when a new page is being created. The
new test in this patch uses this opportunity to remove and reinsert the web view into the window's hierarchy.

  • TestRunnerShared/UIScriptContext/UIScriptController.h:

(WTR::UIScriptController::becomeFirstResponder):

Add and implement a Cocoa platform hook to make the web view first responder.

  • WebKitTestRunner/TestController.cpp:

(WTR::TestController::createOtherPage):

  • WebKitTestRunner/TestInvocation.cpp:

(WTR::TestInvocation::willCreateNewPage):

  • WebKitTestRunner/TestInvocation.h:
  • WebKitTestRunner/cocoa/UIScriptControllerCocoa.h:
  • WebKitTestRunner/cocoa/UIScriptControllerCocoa.mm:

(WTR::UIScriptControllerCocoa::becomeFirstResponder):

LayoutTests:

Add a new layout test to exercise a scenario where the web view is removed from the view hierarchy, added back
into the view hierarchy, and then made first responder all under the scope of a synchronous autocorrection
context request. See <https://trac.webkit.org/changeset/247914> for more details.

The test here involves two parts: first, we attempt to interact with an input field which, when focused, will
try to open a new window, which then triggers code in the UI process that reinserts the web view in the view
hierarchy. Before r247345, this would result in a crash.

The second part involves tapping an input field on the page. Without the fix in r247914, this would result in a
permanent hang in the UI process, due to the keyboard task queue being unable to dequeue and handle any further
tasks.

  • fast/forms/ios/remove-and-add-view-during-focus-expected.txt: Added.
  • fast/forms/ios/remove-and-add-view-during-focus.html: Added.
7:44 PM Changeset in webkit [247940] by Alan Coon
  • 7 edits in tags/Safari-608.1.40.1/Source

Versioning.

7:28 PM Changeset in webkit [247939] by Alan Coon
  • 1 copy in tags/Safari-608.1.40.1

New tag.

6:53 PM Changeset in webkit [247938] by Fujii Hironori
  • 10 edits in trunk/Tools

[Win][MiniBrowser] Add 'reload' menu item and 'reload' toolbar button
https://bugs.webkit.org/show_bug.cgi?id=200217

Reviewed by Alex Christensen.

  • MiniBrowser/win/BrowserWindow.h:
  • MiniBrowser/win/MainWindow.cpp:

(MainWindow::init):
(MainWindow::resizeSubViews):
(MainWindow::WndProc):

  • MiniBrowser/win/MainWindow.h: Added m_hReloadButtonWnd.
  • MiniBrowser/win/MiniBrowserLib.rc:
  • MiniBrowser/win/MiniBrowserLibResource.h: Added IDM_RELOAD.
  • MiniBrowser/win/WebKitBrowserWindow.cpp:

(WebKitBrowserWindow::reload):

  • MiniBrowser/win/WebKitBrowserWindow.h: Added reload() interface.
  • MiniBrowser/win/WebKitLegacyBrowserWindow.cpp:

(WebKitLegacyBrowserWindow::reload):

  • MiniBrowser/win/WebKitLegacyBrowserWindow.h:
6:51 PM Changeset in webkit [247937] by Alan Coon
  • 1 copy in tags/Safari-608.1.40

Tag Safari-608.1.40.

6:50 PM Changeset in webkit [247936] by Wenson Hsieh
  • 3 edits
    2 moves
    2 adds in trunk

YouTube search field shows RTL text outside its border on iPadOS
https://bugs.webkit.org/show_bug.cgi?id=200253
<rdar://problem/53680603>

Reviewed by Beth Dakin.

Source/WebKit:

Limits code added in r238939 to respect the current keyboard's writing mode to only editable web views. This
behavior was only intended for Mail, and isn't generally compatible with web content.

While the call to -setInitialDirection is correctly gated on an web view editability check, it appears that
other changes in iOS 13 now cause -setBaseWritingDirection:forRange: to be invoked directly from keyboards code.
This means that -setBaseWritingDirection:forRange: should additionally be guarded with the same check.

  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView setBaseWritingDirection:forRange:]):

LayoutTests:

  • editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page-expected.txt: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus-expected.txt.
  • editing/input/ios/rtl-keyboard-input-on-focus-in-editable-page.html: Renamed from LayoutTests/editing/input/ios/rtl-keyboard-input-on-focus.html.

Rename an existing test, rtl-keyboard-input-on-focus.html, to rtl-keyboard-input-on-focus-in-editable-page.html
to emphasize the fact that it requires an editable web view.

  • editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page-expected.txt: Added.
  • editing/input/ios/rtl-keyboard-input-on-focus-in-non-editable-page.html: Added.

Add a new layout test to ensure that we don't automatically apply an RTL attribute when focusing fields in a
non-editable web view.

6:46 PM Changeset in webkit [247935] by Fujii Hironori
  • 4 edits in trunk/Tools

[Win][MiniBrowser][WK2] Automatically supplement "file://" or "http://" for an input URL as well as WK1 browser window
https://bugs.webkit.org/show_bug.cgi?id=200218

Reviewed by Alex Christensen.

Moved the scheme supplementing logic from
WebKitLegacyBrowserWindow::loadURL to MainWindow::loadURL.

  • MiniBrowser/win/MainWindow.cpp:

(MainWindow::loadURL):
(MainWindow::onURLBarEnter):

  • MiniBrowser/win/MainWindow.h:
  • MiniBrowser/win/WebKitLegacyBrowserWindow.cpp:

(WebKitLegacyBrowserWindow::loadURL):

6:24 PM Changeset in webkit [247934] by eric.carlson@apple.com
  • 3 edits in trunk/Source/WebCore

MediaSource.isTypeSupported claims FLAC-in-MP4 support on iOS and macOS, but plays silence
https://bugs.webkit.org/show_bug.cgi?id=198583
<rdar://problem/51487853>

Reviewed by Maciej Stachowiak.

  • platform/graphics/avfoundation/objc/AVStreamDataParserMIMETypeCache.h:

(WebCore::AVStreamDataParserMIMETypeCache::canDecodeType): Use anParseExtendedMIMEType:
when it is available.

5:21 PM Changeset in webkit [247933] by sihui_liu@apple.com
  • 2 edits in trunk/Source/WebKit

Try fixing crash at com.apple.WebKit.Networking: NetworkProcess::setSharedHTTPCookieStorage
https://bugs.webkit.org/show_bug.cgi?id=200189
<rdar://problem/41325767>

Reviewed by Chris Dumez.

The crash indicates that sharedCookieStorage is accessed before being set in network process.
sharedCookieStorage is set during the processing of InitializeNetworkProcess message, and access to
sharedCookieStorage is supposed to happen after that. Therefore, it is likely some message is received and
handled before InitializeNetworkProcess.

One possible explanation is WebKit APIs get called on different threads. Because of the race in checking and
setting m_networkProcess, some message is sent between network process gets launched (m_networkProcess is set)
and InitializeNetworkProcess message is sent. To mitigate this issue, we make sure m_networkProcess is set only
in the main runloop and only after InitializeNetworkProcess is sent.

  • UIProcess/WebProcessPool.cpp:

(WebKit::WebProcessPool::ensureNetworkProcess):

5:20 PM Changeset in webkit [247932] by Chris Dumez
  • 5 edits in trunk/Source/WebKit

Fix non-thread safe use of WeakPtr under sendSecItemRequest()
https://bugs.webkit.org/show_bug.cgi?id=200249

Reviewed by Alex Christensen.

The function was calling globalNetworkProcess() from a background thread. This is not safe because
globalNetworkProcess() deferences a WeakPtr<NetworkProcess> internally and the NetworkProcess object
gets destroyed on the main thread.

  • Shared/mac/SecItemShim.cpp:

(WebKit::sendSecItemRequest):

5:17 PM Changeset in webkit [247931] by Alan Bujtas
  • 6 edits in trunk/Source/WebCore

[LFC][TFC] <table> initiates a principal block container box called table wrapper box.
https://bugs.webkit.org/show_bug.cgi?id=200198
<rdar://problem/53623803>

Reviewed by Antti Koivisto.

The table wrapper box contains the table box itself and any caption boxes.

  • layout/layouttree/LayoutBox.cpp:

(WebCore::Layout::Box::isBlockContainerBox const):

  • layout/layouttree/LayoutBox.h:

(WebCore::Layout::Box::isTableCaption const):
(WebCore::Layout::Box::isTableRow const):
(WebCore::Layout::Box::isTableCell const):

  • layout/layouttree/LayoutContainer.h:
  • layout/layouttree/LayoutTreeBuilder.cpp:

(WebCore::Layout::appendChild):
(WebCore::Layout::TreeBuilder::createLayoutBox):
(WebCore::Layout::TreeBuilder::createTableStructure):
(WebCore::Layout::TreeBuilder::createSubTree):
(WebCore::Layout::outputLayoutBox):

  • layout/layouttree/LayoutTreeBuilder.h:
5:06 PM Changeset in webkit [247930] by Justin Fan
  • 4 edits in trunk/Source/WebCore

[WebGPU] Replace Vectors with HashSets for tracking resources used by GPUCommandBuffer
https://bugs.webkit.org/show_bug.cgi?id=200200

Reviewed by Myles C. Maxfield.

Resources bound to a command buffer or bind group only need be tracked once rather than once per sub-view.
This patch cuts GPUQueue.submit validation from 2-12 ms down to ~0 when drawing 12000 triangles in Animometer.

Covered by existing tests; no behavior change expected.

  • Modules/webgpu/WHLSL/Metal/WHLSLTypeNamer.cpp: Removed unused variable.
  • platform/graphics/gpu/GPUBindGroup.h:

(WebCore::GPUBindGroup::boundBuffers const):
(WebCore::GPUBindGroup::boundTextures const):

  • platform/graphics/gpu/GPUCommandBuffer.h:

(WebCore::GPUCommandBuffer::usedBuffers const):
(WebCore::GPUCommandBuffer::usedTextures const):
(WebCore::GPUCommandBuffer::useBuffer):
(WebCore::GPUCommandBuffer::useTexture):

  • platform/graphics/gpu/cocoa/GPUBindGroupMetal.mm:

(WebCore::GPUBindGroup::tryCreate):
(WebCore::GPUBindGroup::GPUBindGroup):

4:23 PM Changeset in webkit [247929] by aakash_jain@apple.com
  • 2 edits in trunk/Tools

Disable Flaky API Test TestWebKitAPI.WKWebView.LocalStorageProcessSuspends
https://bugs.webkit.org/show_bug.cgi?id=200254

Unreviewed infrastructure fix.

  • TestWebKitAPI/Tests/WebKitCocoa/LocalStoragePersistence.mm: Disabled the test.
4:06 PM Changeset in webkit [247928] by Devin Rousso
  • 4 edits in trunk/Source/WebInspectorUI

Web Inspector: add -webkit-* keywords for *-height CSS properties
https://bugs.webkit.org/show_bug.cgi?id=200240

Reviewed by Joseph Pecoraro.

  • UserInterface/Models/CSSKeywordCompletions.js:
  • UserInterface/Views/Main.css:

(.message-text-view):

  • UserInterface/Views/Toolbar.css:

(.toolbar .control-section):
(.toolbar .item-section):
Replace -webkit-min-content with min-content.

4:04 PM Changeset in webkit [247927] by Alan Bujtas
  • 3 edits in trunk/Source/WebCore

[LFC][TFC] Introduce Box::establishesTableFormattingContext
https://bugs.webkit.org/show_bug.cgi?id=200060

Reviewed by Antti Koivisto.

https://www.w3.org/TR/CSS22/tables.html

The table generates a principal block container box called the table wrapper box that contains the table box itself and any caption boxes.
The table box is a block-level box that contains the table's internal table boxes.
The table wrapper box is block-level for 'display: table', and inline-level; for 'display: inline-table'. The table wrapper box establishes a block
formatting context, and the table box establishes a table formatting context."

  • layout/layouttree/LayoutBox.cpp:

(WebCore::Layout::Box::establishesFormattingContext const):
(WebCore::Layout::Box::establishesTableFormattingContext const):
(WebCore::Layout::Box::isBlockLevelBox const):
(WebCore::Layout::Box::isInlineLevelBox const):
(WebCore::Layout::Box::isBlockContainerBox const):

  • layout/layouttree/LayoutBox.h:

(WebCore::Layout::Box::isTableWrapperBox const):
(WebCore::Layout::Box::isTableBox const):

3:48 PM Changeset in webkit [247926] by Alan Bujtas
  • 13 edits in trunk/Source

[ContentChangeObserver] didFinishContentChangeObserving should include the type of content change.
https://bugs.webkit.org/show_bug.cgi?id=200247
<rdar://problem/53681149>

Reviewed by Simon Fraser.

Source/WebCore:

Now we don't have to query the content change observer for the type of the change in the callback.

  • loader/EmptyClients.h:
  • page/ChromeClient.h:
  • page/ios/ContentChangeObserver.cpp:

(WebCore::ContentChangeObserver::adjustObservedState):

  • page/ios/EventHandlerIOS.mm:

(WebCore::EventHandler::mouseMoved):

Source/WebKit:

  • WebProcess/WebCoreSupport/WebChromeClient.h:
  • WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm:

(WebKit::WebChromeClient::didFinishContentChangeObserving):

  • WebProcess/WebPage/WebPage.h:
  • WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::didFinishContentChangeObserving):

Source/WebKitLegacy/ios:

  • WebCoreSupport/WebChromeClientIOS.h:
  • WebCoreSupport/WebChromeClientIOS.mm:

(WebChromeClientIOS::didFinishContentChangeObserving):

3:26 PM Changeset in webkit [247925] by ysuzuki@apple.com
  • 9 edits in trunk

[JSC] Increment bytecode age only when SlotVisitor is first-visit
https://bugs.webkit.org/show_bug.cgi?id=200196

Reviewed by Robin Morisset.

JSTests:

  • stress/reparsing-unlinked-codeblock.js:

Source/JavaScriptCore:

WriteBarrier can cause multiple visits for the same UnlinkedCodeBlock. But this does not mean that we are having multiple cycles of GC.
We should increment the age of the UnlinkedCodeBlock only when the SlotVisitor is saying that this is the first visit.

In practice,this almost never happens. Multiple visits can happen only when the marked UnlinkedCodeBlock gets a write-barrier. But, mutation
of UnlinkedCodeBlock is rare or none after it is initialized. I ran all the JSTests and I cannot find any tests that get re-visiting of UnlinkedCodeBlock.
This patch extends JSTests/stress/reparsing-unlinked-codeblock.js to ensure that UnlinkedCodeBlockJettisoning feature is working after this change.

  • bytecode/UnlinkedCodeBlock.cpp:

(JSC::UnlinkedCodeBlock::visitChildren):

  • heap/SlotVisitor.h:

(JSC::SlotVisitor::isFirstVisit const):

  • parser/Parser.cpp:
  • parser/Parser.h:

(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):

  • runtime/Options.h:
  • tools/JSDollarVM.cpp:

(JSC::functionParseCount):
(JSC::JSDollarVM::finishCreation):

2:57 PM Changeset in webkit [247924] by rniwa@webkit.org
  • 9 edits
    2 adds in trunk

The maximum subframe count check should not be skipped for empty URLs.
https://bugs.webkit.org/show_bug.cgi?id=200032

Patch by Sergei Glazunov <glazunov@google.com> on 2019-07-29
Reviewed by Ryosuke Niwa.

Source/WebCore:

Move the check closer to the actual frame creation code in loadSubframe.

Test: fast/dom/connected-subframe-counter-overflow.html

  • dom/Document.cpp:

(WebCore::Document::prepareForDestruction): Assert that all child frames have been detached.

  • html/HTMLFrameElementBase.cpp:

(WebCore::HTMLFrameElementBase::canLoad const):
(WebCore::HTMLFrameElementBase::canLoadURL const):

  • html/HTMLFrameOwnerElement.cpp:

(WebCore::HTMLFrameOwnerElement::canAddSubframe const): Deleted.

  • html/HTMLFrameOwnerElement.h:
  • html/HTMLPlugInImageElement.cpp:

(WebCore::HTMLPlugInImageElement::canLoadURL const):

  • loader/SubframeLoader.cpp:

(WebCore::SubframeLoader::loadSubframe):

LayoutTests:

  • fast/dom/connected-subframe-counter-overflow-expected.txt: Added.
  • fast/dom/connected-subframe-counter-overflow.html: Added.
  • fast/frames/lots-of-iframes-expected.txt:
2:43 PM Changeset in webkit [247923] by youenn@apple.com
  • 4 edits in trunk

REGRESSION: WebSockets no longer work in Service Workers
https://bugs.webkit.org/show_bug.cgi?id=199906
<rdar://problem/53516732>

Reviewed by Geoffrey Garen.

Source/WebKit:

Use WebSocketProvider so that network calls are done in the network process.

  • WebProcess/Storage/WebSWContextManagerConnection.cpp:

(WebKit::WebSWContextManagerConnection::installServiceWorker):

LayoutTests:

Fix test and make sure messages are exchanged for the test to succeed.

  • http/tests/workers/service/resources/serviceworker-websocket-worker.js:

(async.doTest):

2:32 PM Changeset in webkit [247922] by Alan Bujtas
  • 13 edits in trunk/Source

[ContentChangeObserver] ChromeClient::observedContentChange() name is misleading
https://bugs.webkit.org/show_bug.cgi?id=200238
<rdar://problem/53677038>

Reviewed by Simon Fraser.

Source/WebCore:

This function indicates that we've finished observing content changes.

  • loader/EmptyClients.h:
  • page/ChromeClient.h:
  • page/ios/ContentChangeObserver.cpp:

(WebCore::ContentChangeObserver::adjustObservedState):

  • page/ios/EventHandlerIOS.mm:

(WebCore::EventHandler::mouseMoved):

Source/WebKit:

  • WebProcess/WebCoreSupport/WebChromeClient.h:
  • WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm:

(WebKit::WebChromeClient::didFinishContentChangeObserving):
(WebKit::WebChromeClient::observedContentChange): Deleted.

  • WebProcess/WebPage/WebPage.h:
  • WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::didFinishContentChangeObserving):
(WebKit::WebPage::completePendingSyntheticClickForContentChangeObserver): Deleted.

Source/WebKitLegacy/ios:

  • WebCoreSupport/WebChromeClientIOS.h:
  • WebCoreSupport/WebChromeClientIOS.mm:

(WebChromeClientIOS::didFinishContentChangeObserving):
(WebChromeClientIOS::observedContentChange): Deleted.

2:21 PM Changeset in webkit [247921] by rniwa@webkit.org
  • 17 edits in trunk/Source/WebKit

ShareableBitmap::createGraphicsContext() should return nullptr when CGBitmapContextCreateWithData returns nil
https://bugs.webkit.org/show_bug.cgi?id=200185

Reviewed by Simon Fraser.

We should not be creating GraphicsContext with nil CGContextRef in ShareableBitmap::createGraphicsContext()
as such a GraphicsContext is only used for specific purposes.

This patch adds an early return to ShareableBitmap::createGraphicsContext() when CGBitmapContextCreateWithData
returns nil CGContextRef.

  • PluginProcess/PluginControllerProxy.cpp:

(WebKit::PluginControllerProxy::paint):

  • Shared/API/c/cg/WKImageCG.cpp:

(WKImageCreateFromCGImage):

  • Shared/ContextMenuContextData.cpp:

(WebKit::ContextMenuContextData::ContextMenuContextData):

  • Shared/RemoteLayerTree/RemoteLayerBackingStore.mm:

(WebKit::RemoteLayerBackingStore::display):

  • Shared/WebCoreArgumentCoders.cpp:

(IPC::encodeImage):

  • Shared/cg/ShareableBitmapCG.cpp:

(WebKit::ShareableBitmap::createGraphicsContext):
(WebKit::ShareableBitmap::makeCGImageCopy):

  • WebProcess/InjectedBundle/DOM/InjectedBundleNodeHandle.cpp:

(WebKit::imageForRect):

  • WebProcess/InjectedBundle/DOM/InjectedBundleRangeHandle.cpp:

(WebKit::InjectedBundleRangeHandle::renderedImage):

  • WebProcess/InjectedBundle/InjectedBundleHitTestResult.cpp:

(WebKit::InjectedBundleHitTestResult::image const):

  • WebProcess/Plugins/Netscape/NetscapePlugin.cpp:

(WebKit::NetscapePlugin::snapshot):

  • WebProcess/Plugins/PDF/PDFPlugin.mm:

(WebKit::PDFPlugin::snapshot):

  • WebProcess/Plugins/PluginProxy.cpp:

(WebKit::PluginProxy::paint):
(WebKit::PluginProxy::update):

  • WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:

(WebKit::convertCGImageToBitmap):

  • WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:

(WebKit::DrawingAreaCoordinatedGraphics::display):

  • WebProcess/WebPage/WebFrame.cpp:

(WebKit::WebFrame::createSelectionSnapshot const):

  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::snapshotAtSize):
(WebKit::WebPage::snapshotNode):
(WebKit::WebPage::drawRectToImage):

2:19 PM Changeset in webkit [247920] by dino@apple.com
  • 2 edits in trunk/Source/WebKit

Contextual menu does not present when holding an embedded photo but works with link and attachments
https://bugs.webkit.org/show_bug.cgi?id=200239
<rdar://problem/53318733>

Reviewed by Tim Horton.

If the user long-pressed on an image, and the client implemented the new API but did
not provide a configuration, we were not falling back to the default behaviour of
giving a menu allowing the user to copy/share/save the image.

  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView continueContextMenuInteraction:]): If we get through the delegates,
and the element is an image, return the default configuration.

1:30 PM Changeset in webkit [247919] by Ryan Haddad
  • 3 edits in trunk/LayoutTests

Unreviewed test gardening, update expectations for rdar://problem/48616298.

  • platform/ios-wk2/TestExpectations:

The fast/viewport/ios directory is marked as passing in this file, which was overriding the entries in the 'ios' file.

  • platform/ios/TestExpectations:
1:15 PM Changeset in webkit [247918] by Chris Dumez
  • 2 edits in trunk/Source/WebKit

Remove unnecessary null check under WebResourceLoadStatisticsStore::hasStorageAccess()
https://bugs.webkit.org/show_bug.cgi?id=200229

Reviewed by Alex Christensen.

Remove unnecessary null check under WebResourceLoadStatisticsStore::hasStorageAccess().
There is already a null check with an early return a few lines above.

  • NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp:

(WebKit::WebResourceLoadStatisticsStore::hasStorageAccess):

1:12 PM Changeset in webkit [247917] by weinig@apple.com
  • 9 edits in trunk/Source/WebCore

StringBuilder::append(makeString(...)) is inefficient
https://bugs.webkit.org/show_bug.cgi?id=200034

Reviewed by Saam Barati.

Replace uses of StringBuilder::append(makeString(...)) with StringBuilder::flexiblAppend(...).
Where possible, also merged consecutive calls to StringBuilder::append(...) into a single call
to StringBuilder::flexiblAppend(...) to avoid unnecessary additional overflow checks and resizes.
Also where possible, replaced StringBuilder with makeString() if no branching was used during
construction.

A lot more can be done to improve the efficiency of StringBuilder use in the WHLSL code including:

  • Using StringView more prevelently, especially when passing a substring to the StringBuilder.
  • Passing existing StringBuilders to functions for them to use rather than returning a String and then appending that to another StringBuilder.
  • Using custom StringTypeAdapters for generated names, rather than storing them as Strings.
  • Modules/webgpu/WHLSL/Metal/WHLSLEntryPointScaffolding.cpp:

(WebCore::WHLSL::Metal::EntryPointScaffolding::resourceHelperTypes):
(WebCore::WHLSL::Metal::EntryPointScaffolding::resourceSignature):
(WebCore::WHLSL::Metal::EntryPointScaffolding::builtInsSignature):
(WebCore::WHLSL::Metal::EntryPointScaffolding::mangledInputPath):
(WebCore::WHLSL::Metal::EntryPointScaffolding::mangledOutputPath):
(WebCore::WHLSL::Metal::EntryPointScaffolding::unpackResourcesAndNamedBuiltIns):
(WebCore::WHLSL::Metal::VertexEntryPointScaffolding::helperTypes):
(WebCore::WHLSL::Metal::VertexEntryPointScaffolding::signature):
(WebCore::WHLSL::Metal::VertexEntryPointScaffolding::unpack):
(WebCore::WHLSL::Metal::VertexEntryPointScaffolding::pack):
(WebCore::WHLSL::Metal::FragmentEntryPointScaffolding::helperTypes):
(WebCore::WHLSL::Metal::FragmentEntryPointScaffolding::signature):
(WebCore::WHLSL::Metal::FragmentEntryPointScaffolding::unpack):
(WebCore::WHLSL::Metal::FragmentEntryPointScaffolding::pack):
(WebCore::WHLSL::Metal::ComputeEntryPointScaffolding::signature):

  • Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:

(WebCore::WHLSL::Metal::FunctionDeclarationWriter::visit):
(WebCore::WHLSL::Metal::FunctionDefinitionWriter::FunctionDefinitionWriter):
(WebCore::WHLSL::Metal::FunctionDefinitionWriter::visit):
(WebCore::WHLSL::Metal::FunctionDefinitionWriter::emitLoop):

  • Modules/webgpu/WHLSL/Metal/WHLSLMetalCodeGenerator.cpp:

(WebCore::WHLSL::Metal::generateMetalCodeShared):

  • Modules/webgpu/WHLSL/Metal/WHLSLNativeFunctionWriter.cpp:

(WebCore::WHLSL::Metal::writeNativeFunction):

  • Modules/webgpu/WHLSL/Metal/WHLSLTypeNamer.cpp:

(WebCore::WHLSL::Metal::MetalTypeDeclarationWriter::visit):
(WebCore::WHLSL::Metal::TypeNamer::emitUnnamedTypeDefinition):
(WebCore::WHLSL::Metal::TypeNamer::emitNamedTypeDefinition):
(WebCore::WHLSL::Metal::TypeNamer::metalTypes):

  • Modules/webgpu/WHLSL/WHLSLParser.cpp:

(WebCore::WHLSL::Types::appendNameTo):

  • rendering/RenderLayerCompositor.cpp:

(WebCore::RenderLayerCompositor::logLayerInfo):

  • testing/Internals.cpp:

(WebCore::Internals::ongoingLoadsDescriptions const):

12:56 PM Changeset in webkit [247916] by commit-queue@webkit.org
  • 3 edits in trunk/LayoutTests

REGRESSION (r247891): Layout Test accessibility/ios-simulator/video-elements-ios.html is failing
https://bugs.webkit.org/show_bug.cgi?id=200231
<rdar://problem/53666599>

Patch by Andres Gonzalez <Andres Gonzalez> on 2019-07-29
Reviewed by Chris Fleizach.

We now expose <video> elements when they have controls.

  • accessibility/ios-simulator/video-elements-ios-expected.txt:
  • accessibility/ios-simulator/video-elements-ios.html:
12:20 PM Changeset in webkit [247915] by Megan Gardner
  • 2 edits in trunk/Source/WebCore

Force Reveal to always lookup from menu
https://bugs.webkit.org/show_bug.cgi?id=200186
<rdar://problem/52967940>

Reviewed by Tim Horton.

We currently only have the 'lookup' menu item, so we should always force the 'lookup' action from it.

Reveal is not currently testable.

  • editing/cocoa/DictionaryLookup.mm:

(WebCore::showPopupOrCreateAnimationController):

12:12 PM Changeset in webkit [247914] by Wenson Hsieh
  • 2 edits in trunk/Source/WebKit

UI process occasionally hangs in -[UIKeyboardTaskQueue lockWhenReadyForMainThread]
https://bugs.webkit.org/show_bug.cgi?id=200215
<rdar://problem/52976965>

Reviewed by Tim Horton.

To implement autocorrection on iOS, UIKit sometimes needs to request contextual information from WebKit. This is
handled as a sync IPC message in WebKit, since UIKit would otherwise proceed to block the main thread after
sending the request, preventing WebKit from handling any IPC responses in the UI process (potentially resulting
in deadlock if any other sync IPC messages were to arrive in the UI process during this time).

The synchronous nature of this autocorrection request means that if any sync IPC message were to be
simultaneously dispatched in the opposite direction (i.e. web to UI process), we need to immediately handle the
incoming sync message in the UI process (otherwise, we'd end up deadlocking for 1 second until the
autocorrection context request hits a 1-second IPC timeout).

One such synchronous message from the web process to the UI process is WebPageProxy::CreateNewPage, triggered as
a result of synchronously opening a new window. Due to Safari changes in iOS 13 (<rdar://problem/51755088>),
this message now calls into code which then causes UIKit to call *back into* -[WKContentView
requestAutocorrectionContextWithCompletionHandler:] for the newly opened web view, under the scope of the call
to -requestAutocorrectionContextWithCompletionHandler: in the original web view.

This caused a crash, which was tracked in <rdar://problem/52590170>. There was an attempt to fix this in r247345
by invoking the existing handler well before storing the new one; while this avoided the crash, it didn't solve
the root problem, which was that keyboard task queues would get into a bad state after this scenario; this would
manifest in a UI process hang under -[UIKeyboardTaskQueue lockWhenReadyForMainThread] during the next user
gesture, which is tracked by this bug (<rdar://problem/52976965>).

As it turns out, the keyboard task queue gets into a bad state because it is architected in such a way that
tasks added to the queue under the scope of parent task must be finished executing before their parents;
otherwise, the call to -[UIKeyboardTaskExecutionContext returnExecutionToParentWithInfo:] never happens when
handling the child task. This has the effect of causing the keyboard task queue to end up with a
UIKeyboardTaskExecutionContext that can never return execution to its parent context, such that if the task
queue is then told to wait until any future task is finished executing, it will hang forever, waiting for these
stuck tasks to finish executing (which never happens, because they're all waiting to return execution to their
parents which are already done executing!)

To fix this hang and avoid ever getting into this bad state, we need to invoke the autocorrection request
handlers in this order:

(1) Receive outer autocorrection context request.
(2) Receive inner autocorrection context request.
(3) Invoke inner autocorrection context request completion handler.
(4) Invoke outer autocorrection context request completion handler.

...instead of swapping (3) and (4), like we do currently.

  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView resignFirstResponderForWebView]):

Remove the hack added in r247345 to try and avoid reentrant autocorrection context requests; we don't need this
anymore, since we should now be able to handle these reentrant requests in the way UIKit expects.

(-[WKContentView requestAutocorrectionContextWithCompletionHandler:]):

Add an early return in the case where the request is synchronous and there's already a pending autocorrection
context to ensure that the completion handler for the nested request is invoked before the outer request is
finished.

11:54 AM Changeset in webkit [247913] by Justin Michaud
  • 2 edits in trunk/JSTests

[X86] Emit BT instruction for shift + mask in B3
https://bugs.webkit.org/show_bug.cgi?id=199891

Reviewed by Robin Morisset.

Lower the number of iterations to fix debug timeouts.

  • microbenchmarks/bit-test-load.js:

(i):

11:37 AM Changeset in webkit [247912] by Simon Fraser
  • 5 edits
    2 adds in trunk

REGRESSION (r246899): Subtitles show twice when controls show/hide on hulu.com
https://bugs.webkit.org/show_bug.cgi?id=200187
rdar://problem/53511121

Reviewed by Zalan Bujtas.

Source/WebCore:

When a layer that painted into shared backing moved, we'd fail to repaint its old position
because the RenderLayer's repaint rects are cleared via BackingSharingState::updateBeforeDescendantTraversal().

Recomputing repaint rects is expensive, so we only want to do it when necessary, which is for
layers that start and stop sharing (going into and out of compositing already recomputes them).
So add logic to RenderLayerBacking::setBackingSharingLayers() that recomputes repaint rects
on layers that will no longer use shared backing, and those that are newly using shared
backing.

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

  • rendering/RenderLayer.cpp:

(WebCore::RenderLayer::setBackingProviderLayer):

  • rendering/RenderLayerBacking.cpp:

(WebCore::RenderLayerBacking::setBackingSharingLayers):

  • rendering/RenderLayerCompositor.cpp:

(WebCore::RenderLayerCompositor::BackingSharingState::appendSharingLayer):
(WebCore::RenderLayerCompositor::updateBacking):

LayoutTests:

  • compositing/shared-backing/backing-sharing-repaint-expected.html: Added.
  • compositing/shared-backing/backing-sharing-repaint.html: Added.
11:35 AM Changeset in webkit [247911] by Alan Coon
  • 2 edits in branches/safari-608.1-branch/Source/WebKit

Cherry-pick r247700. rdar://problem/53456070

WebKit SPI fix for [ClickyOrb] Audio continues playing after dismissing a video preview in Safari
https://bugs.webkit.org/show_bug.cgi?id=200011
<rdar://problem/53409457>

Reviewed by Tim Horton.

Don't check for the SPI @selector(_webView:contextMenuDidEndForElement:)
on the WKUIDelegate so that clients that got caught implementing the
SPI before moving to the real API can still clean-up state. In other words,
don't force a client that only implements that method to move completely
to the new API.

  • UIProcess/ios/WKContentViewInteraction.mm: (needsDeprecatedPreviewAPI):

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

11:35 AM Changeset in webkit [247910] by Alan Coon
  • 3 edits
    2 adds in branches/safari-608.1-branch

Cherry-pick r247880. rdar://problem/53647904

Do not fire readystatechange events at documents about to get replaced by javascript URLs.
<rdar://problem/51665406> and https://bugs.webkit.org/show_bug.cgi?id=198786

Reviewed by Ryosuke Niwa.

Source/WebCore:

Test: http/tests/dom/ready-state-on-javascript-replace.html

We were firing too many readystatechange events, more than other browsers.
Our behavior on this test with this patch now matches Chrome.

(There was even an ancient FIXME alluding to this referencing a spec issue, and that issues has long been resolvedv)

  • loader/FrameLoader.cpp: (WebCore::FrameLoader::stopLoading):

LayoutTests:

  • http/tests/dom/ready-state-on-javascript-replace-expected.txt: Added.
  • http/tests/dom/ready-state-on-javascript-replace.html: Added.

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

11:31 AM Changeset in webkit [247909] by Simon Fraser
  • 3 edits
    2 adds in trunk

The touch-action property was ignored on replaced elements (canvas, img etc)
https://bugs.webkit.org/show_bug.cgi?id=200205
rdar://problem/53331224

Reviewed by Antti Koivisto.

Source/WebCore:

The event region painting code didn't handle replaced elements correctly,
causing touch-action to get ignored for <canvas>, <img> etc. Fix by handling
region painting in RenderReplaced.

This still doesn't fix <iframe> but I'm not sure what the correct behavior is there
(webkit.org/b/200204).

Test: pointerevents/ios/touch-action-region-replaced-elements.html

  • rendering/RenderReplaced.cpp:

(WebCore::RenderReplaced::paint):
(WebCore::RenderReplaced::shouldPaint):

LayoutTests:

  • pointerevents/ios/touch-action-region-replaced-elements-expected.txt: Added.
  • pointerevents/ios/touch-action-region-replaced-elements.html: Added.
11:28 AM Changeset in webkit [247908] by youenn@apple.com
  • 2 edits in trunk/Source/WebKit

NetworkProcess clear and fetch of cache entries might move the callback aggregator more than once
https://bugs.webkit.org/show_bug.cgi?id=200228

Reviewed by Alex Christensen.

copyRef the callback aggregator instead of moving it.

  • NetworkProcess/NetworkProcess.cpp:

(WebKit::NetworkProcess::fetchWebsiteData):
(WebKit::NetworkProcess::deleteWebsiteDataForOrigins):

10:59 AM Changeset in webkit [247907] by Alan Coon
  • 7 edits in branches/safari-608.1-branch/Source

Versioning.

10:15 AM Changeset in webkit [247906] by timothy_horton@apple.com
  • 2 edits in trunk/LayoutTests

REGRESSION (r247898): Multiple Layout Tests in http/tests/contentdispositionattachmentsandbox/* are timing out on iOS
<rdar://problem/53664817>

  • http/tests/contentdispositionattachmentsandbox/resources/referer-header-stripped.js:

(onload):
iOS has eventSender, so this reorganizing didn't work (well, it worked for macOS...).
Instead, check which platform we're on and use touch vs. mouse events by
platform instead of by available API.

9:51 AM WebKitGTK/2.24.x edited by Michael Catanzaro
(diff)
9:42 AM Changeset in webkit [247905] by Chris Dumez
  • 2 edits in trunk/Source/WebKit

Possible use-after-move under NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated()
https://bugs.webkit.org/show_bug.cgi?id=200225

Reviewed by Brent Fulgham.

The code was WTFMove()-ing the method parameter inside of a loop, which means that it could
move it several times. Instead of copying the parameters, I opted into sending the statistics
only to the network session that matches this WebProcess connection.

  • NetworkProcess/NetworkConnectionToWebProcess.cpp:

(WebKit::NetworkConnectionToWebProcess::resourceLoadStatisticsUpdated):

7:40 AM Changeset in webkit [247904] by commit-queue@webkit.org
  • 3 edits in trunk/Tools

[Canvas Timeline] Compact canvas timeline
https://bugs.webkit.org/show_bug.cgi?id=200177

Patch by Zhifei Fang <zhifei_fang@apple.com> on 2019-07-29
Reviewed by Jonathan Bedard.

  • resultsdbpy/resultsdbpy/view/static/library/js/components/BaseComponents.js:
  • resultsdbpy/resultsdbpy/view/static/library/js/components/TimelineComponents.js:

(Timeline.CanvasSeriesComponent):

7:33 AM Changeset in webkit [247903] by Philippe Normand
  • 2 edits in trunk/Source/WebCore

REGRESSION(r243058): [GStreamer] WebKitWebSrc's internal queue can exhaust the WebProcess memory
https://bugs.webkit.org/show_bug.cgi?id=199998

Reviewed by Xabier Rodriguez-Calvar.

With the webkitwebsrc rewrite the element lost its ability to tell
the resource loader when to pause and resume downloading because
we don't use appsrc and its enough-data/need-data signals anymore.
So new heuristics are introduced with this patch. Downloading of
resources bigger than 2MiB might pause when the internal adapter
has enough data (2% of the full resource) and resume when the
adapter size goes below 20% of those 2%.

No new tests, the media element spec doesn't clearly mandate how
the resource loading should behave when the element is paused or
how aggressively the resource should be downloaded during
playback.

This patch was functionally tested with a 1.3GiB resource loaded
over the local network, the resource was downloaded in ~30MiB
chunks, stopping and resuming every 20 seconds, approximately.

  • platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:

(webkit_web_src_class_init):
(webKitWebSrcCreate):
(CachedResourceStreamingClient::responseReceived):
(CachedResourceStreamingClient::dataReceived):

2:11 AM Changeset in webkit [247902] by Carlos Garcia Campos
  • 4 edits in trunk/Source/WebCore

WebSockets: workers never use the platform WebSockets path
https://bugs.webkit.org/show_bug.cgi?id=200161

Reviewed by Michael Catanzaro.

A WebCore::WebSocketChannel is created unconditionally in WorkerThreadableWebSocketChannel::Peer.

  • Modules/websockets/ThreadableWebSocketChannel.cpp:

(WebCore::ThreadableWebSocketChannel::create): New create method that receives a Document& and creates the
WebSocket channel checking the runtime enabled features to decide.

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

(WebCore::WorkerThreadableWebSocketChannel::Peer::Peer): Use ThreadableWebSocketChannel::create().

2:07 AM Changeset in webkit [247901] by Carlos Garcia Campos
  • 4 edits in trunk

Multiple context menu actions broken for YouTube videos
https://bugs.webkit.org/show_bug.cgi?id=199999

Reviewed by Eric Carlson.

Source/WebCore:

Do not include CopyMediaLinkItem and OpenMediaInNewWindowItem to the context menu when media URL is not
downloadable or the request can't be handled.

  • page/ContextMenuController.cpp:

(WebCore::ContextMenuController::populate):

Tools:

Add a test case to check copy link address, open in new window and download options are not included in the
context menu for non-downloadable media.

  • TestWebKitAPI/Tests/WebKitGtk/TestContextMenu.cpp:

(writeNextChunk):
(serverCallback):
(testContextMenuLiveStream):
(beforeAll):
(afterAll):

Jul 28, 2019:

9:31 PM Changeset in webkit [247900] by commit-queue@webkit.org
  • 16 edits in trunk/Source

Unreviewed, rolling out r247886.
https://bugs.webkit.org/show_bug.cgi?id=200214

"Causes PLT5 regression on some machines" (Requested by mlam|a
on #webkit).

Reverted changeset:

"Add crash diagnostics for debugging unexpected zapped cells."
https://bugs.webkit.org/show_bug.cgi?id=200149
https://trac.webkit.org/changeset/247886

7:27 PM Changeset in webkit [247899] by timothy_horton@apple.com
  • 2 edits in trunk/Source/WebCore

Fix the release build

  • Modules/webgpu/WHLSL/Metal/WHLSLTypeNamer.cpp:

(WebCore::WHLSL::Metal::TypeNamer::insert):

7:10 PM Changeset in webkit [247898] by timothy_horton@apple.com
  • 15 edits
    7 adds
    3 deletes in trunk

Reorganize UIScriptController into platform-specific subclasses
https://bugs.webkit.org/show_bug.cgi?id=200027

Reviewed by Simon Fraser.

Instead of a mishmash of #ifdefs and extraneous empty functions,
reorganize UIScriptController so that we have a base class
with functions that assert if called (to make it harder to
accidentally write a test that depends on unimplemented
functionality), and override them in platform specific subclasses
as functionality is added.

  • DumpRenderTree/DumpRenderTree.xcodeproj/project.pbxproj:
  • DumpRenderTree/ios/UIScriptControllerIOS.h: Added.
  • DumpRenderTree/ios/UIScriptControllerIOS.mm:
  • DumpRenderTree/mac/UIScriptControllerMac.h: Added.
  • DumpRenderTree/mac/UIScriptControllerMac.mm:
  • TestRunnerShared/UIScriptContext/UIScriptController.cpp:
  • TestRunnerShared/UIScriptContext/UIScriptController.h:
  • WebKitTestRunner/WebKitTestRunner.xcodeproj/project.pbxproj:
  • WebKitTestRunner/cocoa/UIScriptControllerCocoa.h: Added.
  • WebKitTestRunner/cocoa/UIScriptControllerCocoa.mm: Added.
  • WebKitTestRunner/gtk/UIScriptControllerGtk.cpp:
  • WebKitTestRunner/gtk/UIScriptControllerGtk.h: Added.
  • WebKitTestRunner/ios/UIScriptControllerIOS.h: Added.
  • WebKitTestRunner/ios/UIScriptControllerIOS.mm:
  • WebKitTestRunner/mac/UIScriptControllerMac.h: Added.
  • WebKitTestRunner/mac/UIScriptControllerMac.mm:
  • http/tests/contentdispositionattachmentsandbox/resources/referer-header-stripped.js:

(onload):
This test both uses event sender to click, and UIScriptController to "tap".
Since singleTapAtPoint is unimplemented on macOS, it really just ended
up doing nothing, but now it asserts. Only click or tap, but not both.

  • platform/mac/TestExpectations:
  • platform/win/TestExpectations:

Skip some tests for unimplemented or unsupported features.

  • platform/mac/fast/events/autoscroll-when-input-is-offscreen-expected.txt: Removed.
  • platform/mac/fast/events/autoscroll-with-software-keyboard-expected.txt: Removed.

Remove unneeded test results.

  • swipe/resources/swipe-test.js:

(playEventStream):
playBackEventStream is unimplemented on iOS. Also, it's not necessary
for simulated swipe to send events at all on iOS, so just bail, which
is equivalent to what used to happen.

7:07 PM Changeset in webkit [247897] by Fujii Hironori
  • 2 edits in trunk/Source/WebKitLegacy/win

[Win][WK1] Can't change Web Inspector frontend height in high DPI
https://bugs.webkit.org/show_bug.cgi?id=200153

Reviewed by Don Olmstead.

  • WebCoreSupport/WebInspectorClient.cpp:

(WebInspectorFrontendClient::setAttachedWindowHeight):
Applied deviceScaleFactor to the argument height.

7:03 PM Changeset in webkit [247896] by Fujii Hironori
  • 13 edits
    2 deletes in trunk/Tools

[Win][MiniBrowser] Remove PageLoadTestClient
https://bugs.webkit.org/show_bug.cgi?id=200155

Reviewed by Brent Fulgham.

It is not used nowadays.

  • MiniBrowser/win/CMakeLists.txt:
  • MiniBrowser/win/Common.cpp:

(parseCommandLine):

  • MiniBrowser/win/Common.h:
  • MiniBrowser/win/MainWindow.cpp:

(MainWindow::init):

  • MiniBrowser/win/MainWindow.h:
  • MiniBrowser/win/MiniBrowserWebHost.cpp:

(MiniBrowserWebHost::updateAddressBar):
(MiniBrowserWebHost::didFinishLoadForFrame):
(MiniBrowserWebHost::didStartProvisionalLoadForFrame):
(MiniBrowserWebHost::didFailLoadWithError):
(MiniBrowserWebHost::didHandleOnloadEventsForFrame):
(MiniBrowserWebHost::didFirstLayoutInFrame):

  • MiniBrowser/win/PageLoadTestClient.cpp: Removed.
  • MiniBrowser/win/PageLoadTestClient.h: Removed.
  • MiniBrowser/win/ResourceLoadDelegate.cpp:

(ResourceLoadDelegate::identifierForInitialRequest):
(ResourceLoadDelegate::willSendRequest):
(ResourceLoadDelegate::didFinishLoadingFromDataSource):
(ResourceLoadDelegate::didFailLoadingWithError):

  • MiniBrowser/win/WebKitBrowserWindow.cpp:

(WebKitBrowserWindow::create):
(WebKitBrowserWindow::createNewPage):

  • MiniBrowser/win/WebKitBrowserWindow.h:
  • MiniBrowser/win/WebKitLegacyBrowserWindow.cpp:

(WebKitLegacyBrowserWindow::create):
(WebKitLegacyBrowserWindow::WebKitLegacyBrowserWindow):
(WebKitLegacyBrowserWindow::exitProgram): Deleted.

  • MiniBrowser/win/WebKitLegacyBrowserWindow.h:

(WebKitLegacyBrowserWindow::pageLoadTestClient): Deleted.

  • MiniBrowser/win/WinMain.cpp:

(wWinMain):

2:28 PM Changeset in webkit [247895] by ap@apple.com
  • 2 edits in trunk/Source/ThirdParty

Fix static analyzer build
https://bugs.webkit.org/show_bug.cgi?id=200201

Reviewed by Anders Carlsson.

  • Makefile: Add an analyze target, as this makefile is now used for full builds,

including static analyzer ones.

2:23 PM Changeset in webkit [247894] by Simon Fraser
  • 2 edits in trunk/Source/WebCore

[iOS] Touch regions overlay needs to show touch-action:none
https://bugs.webkit.org/show_bug.cgi?id=200203

Reviewed by Wenson Hsieh.

When I added touch-action overlay painting, I didn't realize that touch-action:none
was an important value to display. But it is, so fix that.

  • rendering/RenderLayerBacking.cpp:

(WebCore::patternForTouchAction):

Jul 27, 2019:

6:31 PM Changeset in webkit [247893] by sbarati@apple.com
  • 7 edits in trunk/Source/WebCore

[WHLSL] Remove UnnamedType copy/move constructors and mark classes as final
https://bugs.webkit.org/show_bug.cgi?id=200188

Reviewed by Myles C. Maxfield.

Since they are ref counted, you should make taking a ref to them
instead of moving or copying them. This patch encodes that by deleting
the relevant copy/move constructors and assignment operators.

  • Modules/webgpu/WHLSL/AST/WHLSLArrayReferenceType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLArrayType.h:

(WebCore::WHLSL::AST::ArrayType::ArrayType): Deleted.
(WebCore::WHLSL::AST::ArrayType::create): Deleted.
(WebCore::WHLSL::AST::ArrayType::type const): Deleted.
(WebCore::WHLSL::AST::ArrayType::type): Deleted.
(WebCore::WHLSL::AST::ArrayType::numElements const): Deleted.

  • Modules/webgpu/WHLSL/AST/WHLSLPointerType.h:

(WebCore::WHLSL::AST::PointerType::PointerType): Deleted.
(WebCore::WHLSL::AST::PointerType::create): Deleted.

  • Modules/webgpu/WHLSL/AST/WHLSLReferenceType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLTypeReference.h:

(WebCore::WHLSL::AST::TypeReference::TypeReference): Deleted.
(WebCore::WHLSL::AST::TypeReference::create): Deleted.
(WebCore::WHLSL::AST::TypeReference::name): Deleted.
(WebCore::WHLSL::AST::TypeReference::typeArguments): Deleted.
(WebCore::WHLSL::AST::TypeReference::maybeResolvedType const): Deleted.
(WebCore::WHLSL::AST::TypeReference::resolvedType const): Deleted.
(WebCore::WHLSL::AST::TypeReference::setResolvedType): Deleted.

  • Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.h:
5:47 PM Changeset in webkit [247892] by Justin Fan
  • 17 edits in trunk/Source/WebCore

[WebGPU] Update GPUComputePipeline errors to match GPURenderPipeline implementation
https://bugs.webkit.org/show_bug.cgi?id=200097

Reviewed by Myles C. Maxfield.

Remove passing around a functionName in GPUComputePipeline creation in favor of setting it on the GPUErrorScopes.
Also, WebGPU objects no longer create new Ref<>s unless object creation succeeds.

No new tests. Covered by existing tests.

  • Modules/webgpu/WebGPUDevice.cpp:

(WebCore::WebGPUDevice::createBuffer const):
(WebCore::WebGPUDevice::createBufferMapped const):
(WebCore::WebGPUDevice::createComputePipeline const):

  • platform/graphics/gpu/GPUBuffer.h:
  • platform/graphics/gpu/GPUComputePipeline.h:
  • platform/graphics/gpu/GPUDevice.cpp:

(WebCore::GPUDevice::tryCreateBuffer):
(WebCore::GPUDevice::tryCreateComputePipeline const):

  • platform/graphics/gpu/GPUDevice.h:
  • platform/graphics/gpu/GPUErrorScopes.cpp:

(WebCore::GPUErrorScopes::generatePrefixedError): Only validaton errors have messages right now.

  • platform/graphics/gpu/GPUErrorScopes.h:
  • platform/graphics/gpu/cocoa/GPUBufferMetal.mm:

(WebCore::GPUBuffer::validateBufferUsage):
(WebCore::GPUBuffer::tryCreate):
(WebCore::GPUBuffer::GPUBuffer):

  • platform/graphics/gpu/cocoa/GPUComputePipelineMetal.mm:

(WebCore::trySetMetalFunctions):
(WebCore::trySetFunctions):
(WebCore::convertComputePipelineDescriptor):
(WebCore::tryCreateMTLComputePipelineState):
(WebCore::GPUComputePipeline::tryCreate):
(WebCore::GPUComputePipeline::GPUComputePipeline):

  • platform/graphics/gpu/cocoa/GPURenderPipelineMetal.mm:

(WebCore::trySetMetalFunctions):
(WebCore::trySetFunctions):

These classes were made RefCounted in a previous patch; remove their move ctors to fix build.

  • Modules/webgpu/WHLSL/AST/WHLSLArrayReferenceType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLArrayType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLPointerType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLReferenceType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLTypeReference.h:
  • Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.h:
5:42 PM Changeset in webkit [247891] by commit-queue@webkit.org
  • 4 edits
    4 adds in trunk

Expose the aria-label attribute for <video> elements.
https://bugs.webkit.org/show_bug.cgi?id=200169
<rdar://problem/51754558>

Patch by Andres Gonzalez <Andres Gonzalez> on 2019-07-27
Reviewed by Chris Fleizach.

Source/WebCore:

Tests: accessibility/ios-simulator/media-with-aria-label.html

accessibility/media-with-aria-label.html

We now expose the <video> element to accessibility clients as long as auto-play is not enabled.

  • accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:

(-[WebAccessibilityObjectWrapper accessibilityIsWebInteractiveVideo]):

LayoutTests:

  • accessibility/ios-simulator/media-with-aria-label-expected.txt: Added.
  • accessibility/ios-simulator/media-with-aria-label.html: Added.
  • accessibility/media-with-aria-label-expected.txt: Added.
  • accessibility/media-with-aria-label.html: Added.
  • platform/win/TestExpectations:
6:41 AM Changeset in webkit [247890] by Chris Dumez
  • 2 edits in trunk/Source/WebKit

Allow more syscalls in the WebContent process' sandbox profile
https://bugs.webkit.org/show_bug.cgi?id=200182
<rdar://problem/53594973>

Reviewed by Geoffrey Garen.

I reviewed all crash traces attached to the radar and found the following
syscalls that we not yet allowed by the WebContent process's sandbox
profile.

  • WebProcess/com.apple.WebProcess.sb.in:
12:08 AM Changeset in webkit [247889] by Justin Michaud
  • 9 edits
    3 adds in trunk

[X86] Emit BT instruction for shift + mask in B3
https://bugs.webkit.org/show_bug.cgi?id=199891

Reviewed by Keith Miller.

JSTests:

  • microbenchmarks/bit-test-constant.js: Added.

(let.glob.0.doTest):

  • microbenchmarks/bit-test-load.js: Added.

(let.glob.0.let.arr.new.Int32Array.8.doTest):
(i):

  • microbenchmarks/bit-test-nonconstant.js: Added.

(let.glob.0.doTest):

Source/JavaScriptCore:

  • Add a new BranchTestBit air opcode, matching the intel bt instruction
  • Select this instruction for the following patterns: if (a & (1<<b)) if ((a>>b)&1) if ((~a>>b)&1) if (~a & (1<<b))
  • 15% perf progression on the nonconstant microbenchmark, neutral otherwise.
  • Note: we cannot fuse loads when we have bitBase=Load, bitOffset=Tmp, since the X86 instruction has different behaviour in this mode. It will read past the current dword/qword instead of wrapping around.
  • assembler/MacroAssemblerX86Common.h:

(JSC::MacroAssemblerX86Common::branchTestBit32):

  • assembler/MacroAssemblerX86_64.h:

(JSC::MacroAssemblerX86_64::branchTestBit64):

  • assembler/X86Assembler.h:

(JSC::X86Assembler::bt_ir):
(JSC::X86Assembler::bt_im):
(JSC::X86Assembler::btw_ir):
(JSC::X86Assembler::btw_im):

  • assembler/testmasm.cpp:

(JSC::int64Operands):
(JSC::testBranchTestBit32RegReg):
(JSC::testBranchTestBit32RegImm):
(JSC::testBranchTestBit32AddrImm):
(JSC::testBranchTestBit64RegReg):
(JSC::testBranchTestBit64RegImm):
(JSC::testBranchTestBit64AddrImm):
(JSC::run):

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

(JSC::B3::testBranchBitTest32TmpImm):
(JSC::B3::testBranchBitTest32AddrImm):
(JSC::B3::testBranchBitTest32TmpTmp):
(JSC::B3::testBranchBitTest64TmpTmp):
(JSC::B3::testBranchBitTest64AddrTmp):
(JSC::B3::run):

Jul 26, 2019:

9:55 PM Changeset in webkit [247888] by ysuzuki@apple.com
  • 8 edits
    1 add in trunk

[JSC] Potential GC fix for JSPropertyNameEnumerator
https://bugs.webkit.org/show_bug.cgi?id=200151

Reviewed by Mark Lam.

JSTests:

  • stress/for-in-stress.js: Added.

(keys):

Source/JavaScriptCore:

We have been seeing some JSPropertyNameEnumerator::visitChildren crashes for a long time. The crash frequency itself is not high, but it has existed for a long time.
The crash happens when visiting m_propertyNames. It is also possible that this crash is caused by random corruption somewhere, but JSPropertyNameEnumerator
has some tricky (and potentially dangerous) implementations anyway.

  1. JSPropertyNameEnumerator have Vector<WriteBarrier<JSString>> and it is extended in finishCreation with a lock. We should use Auxiliary memory for this use case. And we should set this memory in the constructor so that we do not extend it in finishCreation, and we do not need a lock.
  2. JSPropertyNameEnumerator gets StructureID before allocating JSPropertyNameEnumerator. This is potentially dangerous because the conservative scan cannot find the Structure* since we could only have StructureID. Since allocation code happens after StructureID is retrieved, it is possible that the allocation causes GC and Structure* is collected.

In this patch, we align JSPropertyNameEnumerator implementation to the modern one to avoid using Vector<WriteBarrier<JSString>>. And we can make JSPropertyNameEnumerator
a non-destructible cell. Since JSCell's destructor is one of the cause of various issues, we should avoid it if we can.

No behavior change. This patch adds a test stressing JSPropertyNameEnumerator.

  • dfg/DFGOperations.cpp:
  • runtime/CommonSlowPaths.cpp:

(JSC::SLOW_PATH_DECL):

  • runtime/JSPropertyNameEnumerator.cpp:

(JSC::JSPropertyNameEnumerator::create):
(JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
(JSC::JSPropertyNameEnumerator::finishCreation):
(JSC::JSPropertyNameEnumerator::visitChildren):
(JSC::JSPropertyNameEnumerator::destroy): Deleted.

  • runtime/JSPropertyNameEnumerator.h:
  • runtime/VM.cpp:

(JSC::VM::emptyPropertyNameEnumeratorSlow):

  • runtime/VM.h:

(JSC::VM::emptyPropertyNameEnumerator):

7:18 PM Changeset in webkit [247887] by sbarati@apple.com
  • 2 edits in trunk/Source/WebCore

Unreviewed. Remove invalid assertion after r247878.
We were essentially asserting all UnnamedType* were
unique. But my patch made this no longer the case by
design to make things faster.

  • Modules/webgpu/WHLSL/Metal/WHLSLTypeNamer.cpp:

(WebCore::WHLSL::Metal::TypeNamer::insert):

5:43 PM Changeset in webkit [247886] by mark.lam@apple.com
  • 16 edits in trunk/Source

Add crash diagnostics for debugging unexpected zapped cells.
https://bugs.webkit.org/show_bug.cgi?id=200149
<rdar://problem/53570112>

Reviewed by Yusuke Suzuki, Saam Barati, and Michael Saboff.

Source/JavaScriptCore:

Add a check for zapped cells in SlotVisitor::appendToMarkStack() and
SlotVisitor::visitChildren(). If a zapped cell is detected, we will crash with
some diagnostic info.

To facilitate this, we've made the following changes:

  1. Changed FreeCell to preserve the 1st 8 bytes. This is fine to do because all cells are at least 16 bytes long.
  2. Changed HeapCell::zap() to only zap the structureID. Leave the rest of the cell header info intact (including the cell JSType).
  3. Changed HeapCell::zap() to record the reason for zapping the cell. We stash the reason immediately after the first 8 bytes. This is the same location as FreeCell::scrambledNext. However, since a cell is not expected to be zapped and on the free list at the same time, it is also fine to do this.
  4. Added a few utility functions to MarkedBlock for checking if a cell points into the block.
  5. Added VMInspector and JSDollarVM utilities to dump in-use subspace hashes.
  6. Added some comments to document the hashes of known subspaces.
  • heap/FreeList.h:

(JSC::FreeCell::offsetOfScrambledNext):

  • heap/HeapCell.h:

(JSC::HeapCell::zap):
(JSC::HeapCell::isZapped const):

  • heap/MarkedBlock.cpp:

(JSC::MarkedBlock::Handle::stopAllocating):

  • heap/MarkedBlock.h:

(JSC::MarkedBlock::Handle::start const):
(JSC::MarkedBlock::Handle::end const):
(JSC::MarkedBlock::Handle::contains const):

  • heap/MarkedBlockInlines.h:

(JSC::MarkedBlock::Handle::specializedSweep):

  • heap/MarkedSpace.h:

(JSC::MarkedSpace::forEachSubspace):

  • heap/SlotVisitor.cpp:

(JSC::SlotVisitor::appendToMarkStack):
(JSC::SlotVisitor::visitChildren):
(JSC::SlotVisitor::reportZappedCellAndCrash):

  • heap/SlotVisitor.h:
  • jit/AssemblyHelpers.cpp:

(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):

  • runtime/VM.cpp:

(JSC::VM::VM):

  • tools/JSDollarVM.cpp:

(JSC::functionDumpSubspaceHashes):
(JSC::JSDollarVM::finishCreation):

  • tools/VMInspector.cpp:

(JSC::VMInspector::dumpSubspaceHashes):

  • tools/VMInspector.h:

Source/WebCore:

No new tests because this is a feature for debugging crashes. It has been tested
manually by modifying the code to force a crash at the point of interest.

Added some comments to document the hashes of known subspaces.

  • bindings/js/WebCoreJSClientData.cpp:

(WebCore::JSVMClientData::JSVMClientData):

5:03 PM Changeset in webkit [247885] by jiewen_tan@apple.com
  • 6 edits in trunk

NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting
https://bugs.webkit.org/show_bug.cgi?id=200150
<rdar://problem/53280170>

Reviewed by Brent Fulgham.

Source/WebKit:

NavigationSOAuthorizationSession should check the active URL of the responding page after waking up from waiting
as the page might have already changed the location.

  • UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.h:
  • UIProcess/Cocoa/SOAuthorization/NavigationSOAuthorizationSession.mm:

(WebKit::NavigationSOAuthorizationSession::shouldStartInternal):
(WebKit::NavigationSOAuthorizationSession::webViewDidMoveToWindow):
(WebKit::NavigationSOAuthorizationSession::pageActiveURLDidChangeDuringWaiting const):

  • UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm:

(WebKit::SubFrameSOAuthorizationSession::abortInternal):

Tools:

  • TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm:

(TestWebKitAPI::TEST):

4:58 PM Changeset in webkit [247884] by Jonathan Bedard
  • 2 edits in trunk/Tools

Follow-up fix: results.webkit.org: Suite results shouldn't be the landing page
https://bugs.webkit.org/show_bug.cgi?id=200090

Unreviewed follow-up fix.

  • resultsdbpy/resultsdbpy/view/view_routes.py:

(ViewRoutes.init): Keep /search endpoint for existing links

4:48 PM Changeset in webkit [247883] by Konstantin Tokarev
  • 2 edits in trunk/Source/WebKitLegacy/win

[Win] Remove unused methods from WebPluginInfoProvider
https://bugs.webkit.org/show_bug.cgi?id=200178

Reviewed by Brent Fulgham.

These methods are guarded with PLATFORM(MAC) and have no definitions.
Also remove unused friend declaration.

  • WebCoreSupport/WebPluginInfoProvider.h:
4:39 PM Changeset in webkit [247882] by Alan Coon
  • 1 copy in tags/Safari-608.1.39

Tag Safari-608.1.39.

4:38 PM Changeset in webkit [247881] by rniwa@webkit.org
  • 3 edits
    6 adds in trunk

Moving right by word boundary right before an object element followed by a br element hangs
https://bugs.webkit.org/show_bug.cgi?id=200144

Reviewed by Simon Fraser.

Source/WebCore:

The bug was caused by an infinite loop inside wordBreakIteratorForMinOffsetBoundary when it's trying to
find the previous word boundary at the beginning of a word after the object element and the br element.
In this case, previousBox is at the br element after the object element in the preceding line, and
logicallyPreviousBox ends up returning the same inline box (that of the br element), causing a hang.

Here's how. In logicallyPreviousBox, previousRootInlineBoxCandidatePosition returns a legacy position
immediately after the object element. The root inline box for this position (previousRoot) is the one
that contains the object element and the br element. However, when previousTextOrLineBreakBox is called
on this root inline box, "box" argument of the function is set to nullptr, and as a result, the function
finds and returns the same inline box of the br element that was passed to logicallyPreviousBox.

Fixed the bug by passing the starting inline box to previousRootInlineBoxCandidatePosition when its
root inline box is the previous root inline box (previousRoot). Also applied the same fix to
logicallyNextBox even though we don't have a reproduction for that case for now (RTL test case is
unaffected by nextRootInlineBoxCandidatePosition).

Tests: editing/selection/move-by-word-visually-across-object-element-1.html

editing/selection/move-by-word-visually-across-object-element-2.html
editing/selection/move-by-word-visually-across-object-element-3.html

  • editing/VisibleUnits.cpp:

(WebCore::logicallyPreviousBox): Fixed the bug.
(WebCore::logicallyNextBox): Ditto.

LayoutTests:

Added regression tests. The second test case involes non-word characters "%)" which are skipped like whitespaces
for the purposes of moving right or left by word granularity. The third test case involves RTL text.

  • editing/selection/move-by-word-visually-across-object-element-1-expected.txt: Added.
  • editing/selection/move-by-word-visually-across-object-element-1.html: Added.
  • editing/selection/move-by-word-visually-across-object-element-2-expected.txt: Added.
  • editing/selection/move-by-word-visually-across-object-element-2.html: Added.
  • editing/selection/move-by-word-visually-across-object-element-3-expected.txt: Added.
  • editing/selection/move-by-word-visually-across-object-element-3.html: Added.
3:53 PM Changeset in webkit [247880] by beidson@apple.com
  • 3 edits
    2 adds in trunk

Do not fire readystatechange events at documents about to get replaced by javascript URLs.
<rdar://problem/51665406> and https://bugs.webkit.org/show_bug.cgi?id=198786

Reviewed by Ryosuke Niwa.

Source/WebCore:

Test: http/tests/dom/ready-state-on-javascript-replace.html

We were firing too many readystatechange events, more than other browsers.
Our behavior on this test with this patch now matches Chrome.

(There was even an ancient FIXME alluding to this referencing a spec issue, and that issues has long been resolvedv)

  • loader/FrameLoader.cpp:

(WebCore::FrameLoader::stopLoading):

LayoutTests:

  • http/tests/dom/ready-state-on-javascript-replace-expected.txt: Added.
  • http/tests/dom/ready-state-on-javascript-replace.html: Added.
2:27 PM Changeset in webkit [247879] by Alan Bujtas
  • 2 edits in trunk/Source/WebCore

[iPadOS] wix.com cannot select a template to edit or view
https://bugs.webkit.org/show_bug.cgi?id=200174
<rdar://problem/53281296>

Reviewed by Simon Fraser.

Opt out of simulated mouse event sending for template selection on wix.com.
When wix.com receives a simulated mouse event during the touch events, it calls preventDefault() which prevents us from running the hover heuristics -> no click.

  • page/Quirks.cpp:

(WebCore::Quirks::shouldDispatchSimulatedMouseEvents const):

2:26 PM Changeset in webkit [247878] by sbarati@apple.com
  • 47 edits in trunk/Source/WebCore

[WHLSL] UnnamedType should be reference counted
https://bugs.webkit.org/show_bug.cgi?id=200098

Reviewed by Dean Jackson.

This patch makes UnnamedType reference counted. The motivation for doing this
is I measured how many times we were cloning UnnamedTypes, and I found we were
doing it ~433,000 times in some of Justin's demos. This is hugely wasteful,
given that an UnnamedType is immutable in the sense that once the type is
resolved, it will never change. So instead of repeatedly cloning the same
type, and having Expression point to a UniqueRef of UnnamedType, we should
instead make UnnamedType reference counted, and have expressions point to a
potentially shared UnnamedType.

Doing this is hugely beneficial to WHLSL compile times. On Justin's demos,
these are the results I'm getting:

hello-triangle: neutral
hello-cube: 55% faster
compute-blur: 35% faster
textured-cube: 49% faster

  • Modules/webgpu/WHLSL/AST/WHLSLArrayReferenceType.h:

(WebCore::WHLSL::AST::ArrayReferenceType::ArrayReferenceType):
(WebCore::WHLSL::AST::ArrayReferenceType::create):

  • Modules/webgpu/WHLSL/AST/WHLSLArrayType.h:

(WebCore::WHLSL::AST::ArrayType::ArrayType):
(WebCore::WHLSL::AST::ArrayType::create):

  • Modules/webgpu/WHLSL/AST/WHLSLEnumerationDefinition.h:

(WebCore::WHLSL::AST::EnumerationDefinition::EnumerationDefinition):

  • Modules/webgpu/WHLSL/AST/WHLSLExpression.h:

(WebCore::WHLSL::AST::Expression::setType):
(WebCore::WHLSL::AST::Expression::copyTypeTo const):

  • Modules/webgpu/WHLSL/AST/WHLSLFloatLiteral.h:

(WebCore::WHLSL::AST::FloatLiteral::clone const):

  • Modules/webgpu/WHLSL/AST/WHLSLFloatLiteralType.cpp:

(WebCore::WHLSL::AST::FloatLiteralType::FloatLiteralType):
(WebCore::WHLSL::AST::FloatLiteralType::clone const):

  • Modules/webgpu/WHLSL/AST/WHLSLFloatLiteralType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLFunctionDeclaration.h:

(WebCore::WHLSL::AST::FunctionDeclaration::FunctionDeclaration):

  • Modules/webgpu/WHLSL/AST/WHLSLIntegerLiteral.h:

(WebCore::WHLSL::AST::IntegerLiteral::clone const):

  • Modules/webgpu/WHLSL/AST/WHLSLIntegerLiteralType.cpp:

(WebCore::WHLSL::AST::IntegerLiteralType::IntegerLiteralType):
(WebCore::WHLSL::AST::IntegerLiteralType::clone const):

  • Modules/webgpu/WHLSL/AST/WHLSLIntegerLiteralType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLNullLiteral.h:

(WebCore::WHLSL::AST::NullLiteral::clone const):

  • Modules/webgpu/WHLSL/AST/WHLSLPointerType.h:

(WebCore::WHLSL::AST::PointerType::PointerType):
(WebCore::WHLSL::AST::PointerType::create):

  • Modules/webgpu/WHLSL/AST/WHLSLReadModifyWriteExpression.h:

(WebCore::WHLSL::AST::ReadModifyWriteExpression::ReadModifyWriteExpression):

  • Modules/webgpu/WHLSL/AST/WHLSLReferenceType.h:

(WebCore::WHLSL::AST::ReferenceType::ReferenceType):

  • Modules/webgpu/WHLSL/AST/WHLSLResolvableType.h:

(WebCore::WHLSL::AST::ResolvableType::resolve):

  • Modules/webgpu/WHLSL/AST/WHLSLStructureElement.h:

(WebCore::WHLSL::AST::StructureElement::StructureElement):

  • Modules/webgpu/WHLSL/AST/WHLSLTypeArgument.cpp:

(WebCore::WHLSL::AST::clone):

  • Modules/webgpu/WHLSL/AST/WHLSLTypeArgument.h:
  • Modules/webgpu/WHLSL/AST/WHLSLTypeDefinition.h:

(WebCore::WHLSL::AST::TypeDefinition::TypeDefinition):

  • Modules/webgpu/WHLSL/AST/WHLSLTypeReference.cpp:

(WebCore::WHLSL::AST::TypeReference::wrap):

  • Modules/webgpu/WHLSL/AST/WHLSLTypeReference.h:

(WebCore::WHLSL::AST::TypeReference::create):
(WebCore::WHLSL::AST::TypeReference::cloneTypeReference const): Deleted.

  • Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLUnsignedIntegerLiteral.h:

(WebCore::WHLSL::AST::UnsignedIntegerLiteral::clone const):

  • Modules/webgpu/WHLSL/AST/WHLSLUnsignedIntegerLiteralType.cpp:

(WebCore::WHLSL::AST::UnsignedIntegerLiteralType::UnsignedIntegerLiteralType):
(WebCore::WHLSL::AST::UnsignedIntegerLiteralType::clone const):

  • Modules/webgpu/WHLSL/AST/WHLSLUnsignedIntegerLiteralType.h:
  • Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h:
  • Modules/webgpu/WHLSL/Metal/WHLSLNativeFunctionWriter.cpp:

(WebCore::WHLSL::Metal::vectorInnerType):

  • Modules/webgpu/WHLSL/Metal/WHLSLNativeTypeWriter.cpp:

(WebCore::WHLSL::Metal::writeNativeType):

  • Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp:

(WebCore::WHLSL::AutoInitialize::visit):

  • Modules/webgpu/WHLSL/WHLSLCheckDuplicateFunctions.cpp:

(WebCore::WHLSL::DuplicateFunctionKey::hash const):

  • Modules/webgpu/WHLSL/WHLSLChecker.cpp:

(WebCore::WHLSL::resolveWithOperatorAnderIndexer):
(WebCore::WHLSL::resolveWithOperatorLength):
(WebCore::WHLSL::resolveWithReferenceComparator):
(WebCore::WHLSL::resolveByInstantiation):
(WebCore::WHLSL::checkOperatorOverload):
(WebCore::WHLSL::Checker::assignTypes):
(WebCore::WHLSL::matchAndCommit):
(WebCore::WHLSL::commit):
(WebCore::WHLSL::Checker::assignConcreteType):
(WebCore::WHLSL::Checker::assignType):
(WebCore::WHLSL::Checker::forwardType):
(WebCore::WHLSL::Checker::visit):
(WebCore::WHLSL::getUnnamedType):
(WebCore::WHLSL::argumentTypeForAndOverload):
(WebCore::WHLSL::Checker::finishVisiting):
(WebCore::WHLSL::Checker::isBoolType):

  • Modules/webgpu/WHLSL/WHLSLInferTypes.cpp:

(WebCore::WHLSL::matchAndCommit):
(WebCore::WHLSL::commit):
(WebCore::WHLSL::inferTypesForTypeArguments):
(WebCore::WHLSL::inferTypesForCallImpl):

  • Modules/webgpu/WHLSL/WHLSLInferTypes.h:
  • Modules/webgpu/WHLSL/WHLSLIntrinsics.cpp:

(WebCore::WHLSL::Intrinsics::addVector):
(WebCore::WHLSL::Intrinsics::addMatrix):
(WebCore::WHLSL::Intrinsics::addTexture):

  • Modules/webgpu/WHLSL/WHLSLParser.cpp:

(WebCore::WHLSL::Parser::parseTypeArgument):
(WebCore::WHLSL::Parser::parseType):
(WebCore::WHLSL::Parser::parseEnumerationDefinition):
(WebCore::WHLSL::Parser::parseVariableDeclaration):
(WebCore::WHLSL::Parser::parseVariableDeclarations):

  • Modules/webgpu/WHLSL/WHLSLParser.h:
  • Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp:

(WebCore::WHLSL::PreserveLifetimes::PreserveLifetimes):
(WebCore::WHLSL::PreserveLifetimes::makeStructVariableReference):
(WebCore::WHLSL::PreserveLifetimes::assignVariableIntoStruct):
(WebCore::WHLSL::preserveVariableLifetimes):

  • Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp:

(WebCore::WHLSL::wrapAnderCallArgument):
(WebCore::WHLSL::anderCallArgument):
(WebCore::WHLSL::setterCall):
(WebCore::WHLSL::getterCall):
(WebCore::WHLSL::modify):
(WebCore::WHLSL::PropertyResolver::visit):
(WebCore::WHLSL::PropertyResolver::simplifyRightValue):
(WebCore::WHLSL::LeftValueSimplifier::finishVisiting):

  • Modules/webgpu/WHLSL/WHLSLResolveOverloadImpl.cpp:

(WebCore::WHLSL::conversionCost):

  • Modules/webgpu/WHLSL/WHLSLResolvingType.h:

(WebCore::WHLSL::ResolvingType::ResolvingType):
(WebCore::WHLSL::ResolvingType::getUnnamedType):
(WebCore::WHLSL::ResolvingType::visit):

  • Modules/webgpu/WHLSL/WHLSLSynthesizeArrayOperatorLength.cpp:

(WebCore::WHLSL::synthesizeArrayOperatorLength):

  • Modules/webgpu/WHLSL/WHLSLSynthesizeConstructors.cpp:

(WebCore::WHLSL::synthesizeConstructors):

  • Modules/webgpu/WHLSL/WHLSLSynthesizeEnumerationFunctions.cpp:

(WebCore::WHLSL::synthesizeEnumerationFunctions):

  • Modules/webgpu/WHLSL/WHLSLSynthesizeStructureAccessors.cpp:

(WebCore::WHLSL::synthesizeStructureAccessors):

  • Modules/webgpu/WHLSL/WHLSLVisitor.cpp:

(WebCore::WHLSL::Visitor::visit):

2:23 PM Changeset in webkit [247877] by Jonathan Bedard
  • 4 edits in trunk/Tools

results.webkit.org: Add switch to filter results by expectation
https://bugs.webkit.org/show_bug.cgi?id=200134

Rubber-stamped by Aakash Jain.

Users of the results database should be able to easily differentiate tests which are expected
to fail verse tests which are unexpectedly failing.

  • resultsdbpy/resultsdbpy/view/static/js/timeline.js:

(Timeline.render): Respect the willFilterExpected variable.
(LegendLabel): Generates html for label in the legend.
(Legend): Add switch for filter results.

  • resultsdbpy/resultsdbpy/view/templates/search.html: GIve Legend callback to re-render timelines.
  • resultsdbpy/resultsdbpy/view/templates/suite_results.html:
2:08 PM Changeset in webkit [247876] by Chris Dumez
  • 2 edits in trunk/Source/WebKit

Crashes under XPCServiceMain() / mach_msg_trap() due to sandboxing
https://bugs.webkit.org/show_bug.cgi?id=200173
<rdar://problem/53594973>

Reviewed by Per Arne Vollan.

Allow a few more syscalls as they appear to be needed by mach_msg_trap().

  • WebProcess/com.apple.WebProcess.sb.in:
1:52 PM Changeset in webkit [247875] by dbates@webkit.org
  • 2 edits in trunk/Source/WebKit

[iOS] REGRESSION: Keyboard dismisses and reappears when typing 2FA pin on appleid.apple.com
https://bugs.webkit.org/show_bug.cgi?id=200171
<rdar://problem/50245251>

Reviewed by Wenson Hsieh.

Take out an InputViewUpdateDeferrer token (if we don't already have one) to temporarily defer
tearing down the input view (keyboard) before bluring the previously focused element as part
of switching between focused elements. This avoid a noticeable flash caused by UIKit animating
out and animating in the keyboard should the newly focused element require the keyboard. We
only take out the InputViewUpdateDeferrer until we fall off the end of _elementDidFocus: (or
bail early). Once we fall of the end UIKit will update input view UI.

  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView _elementDidFocus:userIsInteracting:blurPreviousNode:activityStateChanges:userObject:]):

1:46 PM Changeset in webkit [247874] by commit-queue@webkit.org
  • 3 edits in trunk/Source/WebCore

[curl] Heap corruption in ~CurlResponse
https://bugs.webkit.org/show_bug.cgi?id=198320

Patch by Takashi Komori <Takashi.Komori@sony.com> on 2019-07-26
Reviewed by Fujii Hironori.

Stop sharing object which was reffered by two threads to fix crash bug.

No tests needed, no functionality changes.

  • platform/network/curl/CurlRequest.cpp:

(WebCore::CurlRequest::start):
(WebCore::CurlRequest::invokeDidReceiveResponseForFile):

  • platform/network/curl/CurlRequest.h:
1:34 PM Changeset in webkit [247873] by youenn@apple.com
  • 4 edits in trunk/Source/WebCore

slides.google.com: opening speaker notes while presenting causes a fatal error in the web app on iPad
https://bugs.webkit.org/show_bug.cgi?id=199933
<rdar://problem/53034345>

Reviewed by Darin Adler.

docs.google.com might sometimes try to window.open an about URL that not about:blank or about:srcdoc.
In that case, WebKit is opening a window but is considering that the window is cross origin with its opener.
This breaks docs.google.com as they want to access the website.
Add a site-specific hack so as to treat all about URLs being opened through window.open as about:blank.

Manually tested on docs.google.com website.

  • page/DOMWindow.cpp:

(WebCore::DOMWindow::createWindow):
(WebCore::DOMWindow::open):

  • page/Quirks.cpp:

(WebCore::Quirks::needsYouTubeOverflowScrollQuirk const):
(WebCore::Quirks::shouldOpenAsAboutBlank const):

  • page/Quirks.h:
12:34 PM Changeset in webkit [247872] by Chris Dumez
  • 2 edits in trunk/Source/WebKit

Avoid WebContent process SIGKILL when using kevent()
https://bugs.webkit.org/show_bug.cgi?id=200170
<rdar://problem/51559921>

Reviewed by Per Arne Vollan.

Avoid WebContent process SIGKILL when using kevent() by updated its sandboxing profile.

  • WebProcess/com.apple.WebProcess.sb.in:
12:22 PM Changeset in webkit [247871] by aakash_jain@apple.com
  • 4 edits in trunk/Tools

[ews-build] Use update-webkit script in Style EWS
https://bugs.webkit.org/show_bug.cgi?id=193196

Reviewed by Jonathan Bedard.

  • BuildSlaveSupport/ews-build/factories.py:

(StyleFactory): Updated to use CheckOutSource step as well.

  • BuildSlaveSupport/ews-build/steps.py: Added build-step to UpdateWorkingDirectory.
  • BuildSlaveSupport/ews-build/steps_unittest.py: Added unit-tests.
12:19 PM Changeset in webkit [247870] by Jonathan Bedard
  • 3 edits in trunk/Tools

results.webkit.org: Support buildbot 0.8 CI links
https://bugs.webkit.org/show_bug.cgi?id=200146

Reviewed by Aakash Jain.

  • resultsdbpy/resultsdbpy/model/ci_context.py:

(BuildbotEightURLFactory): Buildbot 0.8 link factory.
(BuildbotEightURLFactory.init):
(BuildbotEightURLFactory.url):

  • resultsdbpy/resultsdbpy/model/ci_context_unittest.py:

(URLFactoryTest.test_old_builder_url):
(URLFactoryTest):
(URLFactoryTest.test_old_worker_url):

12:17 PM Changeset in webkit [247869] by Jonathan Bedard
  • 4 edits in trunk/Tools

results.webkit.org: Suite results shouldn't be the landing page
https://bugs.webkit.org/show_bug.cgi?id=200090

Reviewed by Aakash Jain.

  • resultsdbpy/resultsdbpy/view/templates/suite_results.html: Remove search bar.
  • resultsdbpy/resultsdbpy/view/view_routes.py:

(ViewRoutes.init): Make search the landing page instead of suite results.

  • resultsdbpy/resultsdbpy/view/view_routes_unittest.py:

(WebSiteUnittest.test_main):

11:27 AM Changeset in webkit [247868] by Chris Dumez
  • 17 edits
    2 moves in trunk

[iOS] WebPage::TouchEventSync() & WebPage::GetPositionInformation() sync IPC causes UIProcess hangs
https://bugs.webkit.org/show_bug.cgi?id=200138
<rdar://problem/52698157>

Reviewed by Geoffrey Garen.

Source/WebKit:

Revert most of r247822 and use an alternative approach to address hangs. In this patch, the proposal
is to add a SendSyncOption::ForceDispatchWhenDestinationIsWaitingForUnboundedSyncReply flag on the
WebPage::TouchEventSync() & WebPage::GetPositionInformation() sendSync() calls in the UIProcess.
Those will cause this IPCs to get dispatched right away in the WebContent process, even if the
WebContent process is itself currently stuck on unbounded (i.e. potentially slow) synchronous IPC
(JS alerts / prompts & sync XHR). Because re-entering WebCore on sync IPC is generally unsafe, this
patch also updates the WebPage::getPositionInformation() & WebPage::touchEventSync() to return early
(i.e. cancelled) if they get called while the WebContent process is stuck on a slow sendSync.

This approach should address the UIProcess hangs caused by the WebPage::TouchEventSync() and
WebPage::GetPositionInformation() sync IPC messages when the WebContent process is busy on a slow XHR
or a JS prompt / alert. It should be safe because we do not re-enter WebCore. The only drawback is that
those IPCs will be cancelled (early return with default value) when the WebContent process is busy.
However, I am being told that this is likely acceptable in practice.

  • Platform/IPC/Connection.cpp:

(IPC::Connection::SyncMessageState::processIncomingMessage):
(IPC::Connection::sendMessage):
(IPC::Connection::sendSyncMessage):
(IPC::Connection::dispatchMessage):

  • Platform/IPC/Connection.h:

(IPC::UnboundedSynchronousIPCScope::UnboundedSynchronousIPCScope):
(IPC::UnboundedSynchronousIPCScope::~UnboundedSynchronousIPCScope):
(IPC::UnboundedSynchronousIPCScope::hasOngoingUnboundedSyncIPC):

  • Platform/IPC/Decoder.cpp:

(IPC::Decoder::shouldDispatchMessageWhenWaitingForSyncReply const):

  • Platform/IPC/Decoder.h:
  • Platform/IPC/Encoder.cpp:

(IPC::Encoder::shouldDispatchMessageWhenWaitingForSyncReply const):
(IPC::Encoder::setShouldDispatchMessageWhenWaitingForSyncReply):
(IPC::Encoder::wrapForTesting):

  • Platform/IPC/Encoder.h:
  • Platform/IPC/MessageFlags.h:
  • UIProcess/Network/NetworkProcessProxy.cpp:

(WebKit::NetworkProcessProxy::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):

  • UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::handleTouchEventSynchronously):

  • UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView ensurePositionInformationIsUpToDate:]):

  • WebProcess/Network/WebLoaderStrategy.cpp:

(WebKit::WebLoaderStrategy::loadResourceSynchronously):

  • WebProcess/WebCoreSupport/WebChromeClient.cpp:

(WebKit::WebChromeClient::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):
(WebKit::WebChromeClient::runJavaScriptAlert):
(WebKit::WebChromeClient::runJavaScriptConfirm):
(WebKit::WebChromeClient::runJavaScriptPrompt):

  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::layerVolatilityTimerFired):
(WebKit::WebPage::markLayersVolatile):
(WebKit::WebPage::cancelMarkLayersVolatile):
(WebKit::WebPage::touchEventSync):
(WebKit::WebPage::didCompletePageTransition):
(WebKit::WebPage::updatePreferences):
(WebKit::WebPage::testProcessIncomingSyncMessagesWhenWaitingForSyncReply):

  • WebProcess/WebPage/WebPage.h:

(WebKit::WebPage::sendSyncWithDelayedReply):

  • WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::getPositionInformation):

LayoutTests:

Update existing layout test accordingly.

  • fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply-expected.txt: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply-expected.txt.
  • fast/misc/{testProcessIncomingSyncMessagesWhenWaitingForUnboundedReply.html: Renamed from LayoutTests/fast/misc/testProcessIncomingSyncMessagesWhenWaitingForSyncReply.html.
11:25 AM Changeset in webkit [247867] by commit-queue@webkit.org
  • 3 edits in trunk/Source/WebInspectorUI

Web Inspector: AXI: Audit: Typo of "some" as "somee"
https://bugs.webkit.org/show_bug.cgi?id=200166

Patch by Greg Doolittle <gr3g@apple.com> on 2019-07-26
Reviewed by Devin Rousso.

  • Localizations/en.lproj/localizedStrings.js:
  • UserInterface/Controllers/AuditManager.js:

(WI.AuditManager.prototype._addDefaultTests):
(WI.AuditManager):

11:22 AM Changeset in webkit [247866] by Alan Bujtas
  • 22 edits in trunk

Unable to tap/double tap to open files/folders in Google Drive in Safari
https://bugs.webkit.org/show_bug.cgi?id=200096
<rdar://problem/52748552>

Reviewed by Wenson Hsieh.

Source/WebKit:

This patch reverts to the original double-tap-for-double-click implementation (see r244775 and r246347 for more information).

  • Shared/WebPageCreationParameters.cpp:

(WebKit::WebPageCreationParameters::encode const):
(WebKit::WebPageCreationParameters::decode):

  • Shared/WebPageCreationParameters.h:
  • UIProcess/PageClient.h:
  • UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::creationParameters):

  • UIProcess/WebPageProxy.h:
  • UIProcess/ios/PageClientImplIOS.h:
  • UIProcess/ios/PageClientImplIOS.mm:

(WebKit::PageClientImpl::doubleTapForDoubleClickDelay): Deleted.
(WebKit::PageClientImpl::doubleTapForDoubleClickRadius): Deleted.

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

(-[WKContentView setupInteraction]):
(-[WKContentView cleanupInteraction]):
(-[WKContentView _removeDefaultGestureRecognizers]):
(-[WKContentView _addDefaultGestureRecognizers]):
(-[WKContentView gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer:]): Do not recognize the single and double gestures the same time.
(-[WKContentView gestureRecognizerShouldBegin:]):
(-[WKContentView _doubleTapRecognizedForDoubleClick:]):
(-[WKContentView _didStartProvisionalLoadForMainFrame]):
(-[WKContentView _ensureNonBlockingDoubleTapGestureRecognizer]): Deleted.
(-[WKContentView _doubleTapForDoubleClickDelay]): Deleted.
(-[WKContentView _doubleTapForDoubleClickRadius]): Deleted.

  • UIProcess/ios/WebPageProxyIOS.mm:

(WebKit::WebPageProxy::handleDoubleTapForDoubleClickAtPoint):

  • WebProcess/WebPage/WebPage.cpp:
  • WebProcess/WebPage/WebPage.h:
  • WebProcess/WebPage/WebPage.messages.in:
  • WebProcess/WebPage/ios/WebPageIOS.mm:

(WebKit::WebPage::handleDoubleTapForDoubleClickAtPoint):
(WebKit::WebPage::commitPotentialTap):
(WebKit::WebPage::handlePotentialDoubleTapForDoubleClickAtPoint): Deleted.

LayoutTests:

  1. Rebaseline (progression).
  2. Payment request tests activate elements by tapping on them at a high speed, triggering double clicks instead. Let's slow them down a bit.
  • fast/events/touch/ios/double-tap-for-double-click3-expected.txt:
  • http/tests/adClickAttribution/anchor-tag-attributes-validation.html:
  • http/tests/resources/payment-request.js:

(activateThen):

  • resources/ui-helper.js:

(window.UIHelper.activateElementAtHumanSpeed.return.new.Promise):
(window.UIHelper.activateElementAtHumanSpeed):

  • tests-options.json:
10:58 AM Changeset in webkit [247865] by Dewei Zhu
  • 2 edits in trunk/Websites/perf.webkit.org

Fix a bug that cannot update builder password on builders administrative page.
https://bugs.webkit.org/show_bug.cgi?id=200154

Reviewed by Ryosuke Niwa.

'builders' administrative page should be able to update password for a builder.

  • public/admin/builders.php: Should be able to update builder password.
10:18 AM Changeset in webkit [247864] by commit-queue@webkit.org
  • 3 edits in trunk/Source/WebKit

AX: web process should load correct bundle path for MACCATALYST
https://bugs.webkit.org/show_bug.cgi?id=200122

Patch by Eric Liang <ericliang@apple.com> on 2019-07-26
Reviewed by Brent Fulgham.

Added the path to accessibility bundle for Mac Catalyst.
Added sandbox profile to read accessibility settings.

  • WebProcess/cocoa/WebProcessCocoa.mm:

(WebKit::registerWithAccessibility):

  • WebProcess/com.apple.WebProcess.sb.in:
9:08 AM Changeset in webkit [247863] by Jonathan Bedard
  • 2 edits in trunk/Tools

Follow-up fix: results.webkit.org: Color should be the worst result, count should include all results
https://bugs.webkit.org/show_bug.cgi?id=200127

Unreviewed follow-up fix.

  • resultsdbpy/resultsdbpy/view/static/js/timeline.js:

(Dot.toString): Use self instead of this in render callback.

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

REGRESSION(r246496): [GTK] Tapping the web view scrolls up a bit
https://bugs.webkit.org/show_bug.cgi?id=200084

Patch by Alexander Mikhaylenko <exalm7659@gmail.com> on 2019-07-26
Reviewed by Carlos Garcia Campos.

gdk_event_get_scroll_direction() returns false, but also sets direction to GDK_SCROLL_UP if
the direction was GDK_SCROLL_SMOOTH. Relying on zero deltas in this case is not correct, because
they can also be zero with GDK_SCROLL_SMOOTH. In this case, set the direction manually to avoid
that.

See https://gitlab.gnome.org/GNOME/gtk/issues/2048

Source/WebCore:

  • platform/gtk/PlatformWheelEventGtk.cpp:

(WebCore::PlatformWheelEvent::PlatformWheelEvent):

Source/WebKit:

  • Shared/gtk/WebEventFactory.cpp:

(WebKit::WebEventFactory::createWebWheelEvent):

1:52 AM Changeset in webkit [247861] by commit-queue@webkit.org
  • 2 edits in trunk/Source/WebKit

[WPE] Support disk cache dumping like GTK
https://bugs.webkit.org/show_bug.cgi?id=200157

Patch by Loïc Yhuel <loic.yhuel@softathome.com> on 2019-07-26
Reviewed by Carlos Garcia Campos.

Creating or touching "dump" would create the dump.json.

  • NetworkProcess/cache/NetworkCache.cpp:

(WebKit::NetworkCache::Cache::Cache):

12:29 AM Changeset in webkit [247860] by commit-queue@webkit.org
  • 16 edits
    4 adds in trunk

Make storing cross-origin top-level prefetches in HTTP cache optional
https://bugs.webkit.org/show_bug.cgi?id=199499

Patch by Rob Buis <rbuis@igalia.com> on 2019-07-26
Reviewed by Youenn Fablet.

Source/WebCore:

Add Internals API for adding an event listener to prefetch load.

Test: http/wpt/prefetch/link-prefetch-skip-disk-cache.html

  • bindings/js/JSEventListener.h:
  • dom/EventTarget.h:

(WebCore::EventTarget::addEventListener):

  • dom/Node.h:
  • html/HTMLLinkElement.h:
  • testing/Internals.cpp:

(WebCore::Internals::addPrefetchLoadEventListener):

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

Source/WebKit:

Currently when we navigate we check if there is a cross-origin top-level
prefetch we can use for the navigation. The current solution uses the
HTTP cache as a way to store the prefetch and to immediately use it for
the navigation load. However this solution fails in case the prefetch is
not cacheable.

Instead of this, simulate a HTTP Cache entry to process the load and
afterwards try to store the navigation load into the HTTP cache, where
normal store decisions will be applied.

Test: http/wpt/prefetch/link-prefetch-skip-disk-cache.html

  • NetworkProcess/NetworkResourceLoader.cpp:

(WebKit::NetworkResourceLoader::retrieveCacheEntry):
(WebKit::NetworkResourceLoader::retrieveCacheEntryInternal):

  • NetworkProcess/NetworkResourceLoader.h:

LayoutTests:

Remove unneeded Cache-Control headers and verify that Cache-Control
effects whether the navigation gets stored in the disk cache or not.

  • http/tests/cache/resources/prefetched-main-resource-iframe.php:
  • http/tests/cache/resources/prefetched-main-resource.php:
  • http/wpt/prefetch/link-prefetch-skip-disk-cache-expected.txt: Added.
  • http/wpt/prefetch/link-prefetch-skip-disk-cache.html: Added.
  • http/wpt/prefetch/resources/main-resource-skip-disk-cache.py: Added.

(main):

  • http/wpt/prefetch/resources/navigate-skip-disk-cache.html: Added.
  • platform/mac-wk1/TestExpectations:
  • platform/win/TestExpectations:
12:24 AM Changeset in webkit [247859] by bshafiei@apple.com
  • 11 edits in branches/safari-608.1-branch/Source

Cherry-pick r247755. rdar://problem/53575424

AX: CrashTracer: com.apple.WebKit.WebContent at WebKit: WebKit::WebSpeechSynthesisClient::speak
https://bugs.webkit.org/show_bug.cgi?id=199988

Reviewed by Per Arne Vollan.

Source/WebCore:

Implement the reset state to cancel current speech jobs.

  • Modules/speech/SpeechSynthesis.cpp: (WebCore::SpeechSynthesis::startSpeakingImmediately): (WebCore::SpeechSynthesis::cancel):
  • platform/PlatformSpeechSynthesizer.h:
  • platform/ios/PlatformSpeechSynthesizerIOS.mm: (WebCore::PlatformSpeechSynthesizer::resetState):
  • platform/mac/PlatformSpeechSynthesizerMac.mm: (WebCore::PlatformSpeechSynthesizer::resetState):

Source/WebKit:

Improvements to WebSpeechSynthesis to avoid crashing and improve correctness.

  • Reset and cancel speech jobs on page close or reload (otherwise the synthesizer keeps talking after your page is gone)
  • Have a separate speech finish callback mechanism, use the start speaking callback when the synthesizer tells us.
  • Move an assert on utterance state to only apply when we use the in process synthesizer.
  • UIProcess/Cocoa/WebPageProxyCocoa.mm: (WebKit::WebPageProxy::didStartSpeaking):
  • UIProcess/WebPageProxy.cpp: (WebKit::WebPageProxy::reload): (WebKit::WebPageProxy::resetState): (WebKit::WebPageProxy::resetSpeechSynthesizer): (WebKit::WebPageProxy::speechSynthesisSetFinishedCallback): (WebKit::WebPageProxy::speechSynthesisSpeak):
  • UIProcess/WebPageProxy.h:
  • UIProcess/WebPageProxy.messages.in:
  • WebProcess/WebCoreSupport/WebSpeechSynthesisClient.cpp: (WebKit::WebSpeechSynthesisClient::speak):

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

12:24 AM Changeset in webkit [247858] by bshafiei@apple.com
  • 2 edits in branches/safari-608.1-branch/Source/WebCore

Cherry-pick r247734. rdar://problem/53575398

Fix crashes in ScrollingStateNode::insertChild()
https://bugs.webkit.org/show_bug.cgi?id=200023
rdar://problem/53265378

Reviewed by Darin Adler.

Crash data suggest that ScrollingStateNode::insertChild() can be passed an index that
is larger than the size of the vector, causing crashes.

Fix defensively by falling back to append() if the passed index is equal to or larger
than the size of the children vector.

  • page/scrolling/ScrollingStateNode.cpp: (WebCore::ScrollingStateNode::insertChild):

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

12:24 AM Changeset in webkit [247857] by bshafiei@apple.com
  • 7 edits
    1 add in branches/safari-608.1-branch

Cherry-pick r247702. rdar://problem/53575418

[iOS] [WK1] UIWebView always jumps to the top left corner when scrolling to reveal the selection
https://bugs.webkit.org/show_bug.cgi?id=200013
<rdar://problem/52526901>

Reviewed by Simon Fraser.

Source/WebCore:

After <https://trac.webkit.org/r244141>, we no longer attempt to scroll to reveal the text selection in
UIWebView after changing the selection, due to how we use the legacy document view rect in legacy WebKit when
computing the visual viewport. This causes the viewRect in RenderLayer::scrollRectToVisible to be the same size
as the content size, which then causes us to always scroll to the origin when revealing the selection.

To make selection revealing work again in legacy WebKit, conditionally restore the old behavior of using the
unobscured content rect as the view rect, only in the case where scrolling is delegated and the platform widget
is present.

Test: WebKitLegacy.ScrollToRevealSelection

  • page/FrameView.cpp: (WebCore::FrameView::viewRectExpandedByContentInsets const): (WebCore::FrameView::visualViewportRectExpandedByContentInsets const): Deleted.

Additionally rename visualViewportRectExpandedByContentInsets to viewRectExpandedByContentInsets, to reflect the
fact that this may either be the visual viewport rect or unobscured content rect.

  • page/FrameView.h:
  • rendering/RenderLayer.cpp: (WebCore::RenderLayer::scrollRectToVisible):

Tools:

Add a new API test to verify that inserting text in UIWebView causes the document to scroll.

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WebKitLegacy/ios/ScrollToRevealSelection.mm: Added. (-[LegacyLoadingDelegate webViewDidFinishLoad:]): (-[LegacyLoadingDelegate waitForDidFinishLoad]):
  • TestWebKitAPI/ios/UIKitSPI.h:

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

Note: See TracTimeline for information about the timeline view.