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

Timeline



Oct 20, 2019:

6:55 PM Changeset in webkit [251358] by Brent Fulgham
  • 4 edits
    1 copy in trunk/Source/WebKit

Improve serialization logic
​https://bugs.webkit.org/show_bug.cgi?id=203039
<rdar://problem/55631691>

Reviewed by Alex Christensen.

Check that the SecItemRequestData only contains relevant types for
CFNetwork uses.

  • Platform/spi/Cocoa/SecItemSPI.h: Added.
  • Shared/mac/SecItemRequestData.cpp:

(WebKit::arrayContainsInvalidType): Added.
(WebKit::dictionaryContainsInvalidType): Added.
(WebKit::validTypeIDs): Added.
(WebKit::isValidType): Added.
(WebKit::SecItemRequestData::decode): Check types during decode.

  • Shared/mac/SecItemRequestData.h:
  • WebKit.xcodeproj/project.pbxproj:
6:44 PM Changeset in webkit [251357] by Chris Dumez
  • 2 edits in trunk/Source/WebCore

Unreviewed, drop debug logging that was inadvertently committed with r251327.

  • history/BackForwardCache.cpp:
5:44 PM Changeset in webkit [251356] by bshafiei@apple.com
  • 3 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r251188. rdar://problem/56340816

WebAudioSourceProviderAVFObjC::provideInput should set its WebAudioBufferList parameters correctly
​https://bugs.webkit.org/show_bug.cgi?id=202930
<rdar://problem/56006776>

Reviewed by Eric Carlson.

Source/WebCore:

There is a time where the bus channel number and audio source channel numbers may be different.
In case the bus channel number is less than the audio source channel number, initialization of
the WebAudioBufferList might not be fully done.
In that case, output silence and return early.
Reduce the number of frames to process based on the number of frames the output audio bus plans to process.

Partially covered by new API test (this a race so we cannot reproduce the crash easily).

  • Modules/webaudio/MediaStreamAudioSourceNode.cpp: (WebCore::MediaStreamAudioSourceNode::process): Make sure to process the number of frames the output bus expect.
  • platform/mediastream/mac/WebAudioSourceProviderAVFObjC.mm: (WebCore::WebAudioSourceProviderAVFObjC::provideInput):

Tools:

Add a test that has an audio track that goes from 1 to 2 channels while being piped to a WebAudio pipeline.

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WebKit/GetUserMedia.mm: (-[GUMMessageHandler userContentController:didReceiveScriptMessage:]): (TestWebKitAPI::TEST):
  • TestWebKitAPI/Tests/WebKit/getUserMedia-webaudio.html: Added.

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

5:44 PM Changeset in webkit [251355] by bshafiei@apple.com
  • 2 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r250773. rdar://problem/56271900

WebPageProxy::updatePlayingMediaDidChange should protect from a null m_userMediaPermissionRequestManager
​https://bugs.webkit.org/show_bug.cgi?id=202628
<rdar://problem/55935091>

Reviewed by Eric Carlson.

On process swap on navigation or process crash, m_userMediaPermissionRequestManager is made null.
At the same time, the media state is set back to not playing.
Future calls of updatePlayingMediaDidChange should not have any capture state change until getUserMedia/getDisplayMedia
is called, which would create m_userMediaPermissionRequestManager.
But this assumption is not always true given that the media state is computed as process-wide in MediaStreamTrack::captureState on iOS.
The above behavior is fixed as part of ​https://bugs.webkit.org/show_bug.cgi?id=202627.
Since the call to updatePlayingMediaDidChange is triggered straight from IPC, it should not be trusted and a null check should be added.

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

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

5:44 PM Changeset in webkit [251354] by bshafiei@apple.com
  • 5 edits
    1 add in branches/safari-608-branch

Cherry-pick r249538. rdar://problem/56426429

LazyClassStructure::setConstructor should not store the constructor to the global object
​https://bugs.webkit.org/show_bug.cgi?id=201484
<rdar://problem/50400451>

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/web-assembly-constructors-should-not-override-global-object-property.js: Added.

Source/JavaScriptCore:

LazyClassStructure::setConstructor sets the constructor as a property of the global object.
This became a problem when it started being used for WebAssembly constructors, such as Module
and Instance, since they are properties of the WebAssembly object, not the global object. That
resulted in properties of the global object replaced whenever a lazy WebAssembly constructor
was first accessed. e.g.

globalThis.Module = x;
WebAssembly.Module;
globalThis.Module === WebAssembly.Module;

  • runtime/LazyClassStructure.cpp: (JSC::LazyClassStructure::Initializer::setConstructor):
  • runtime/LazyClassStructure.h:
  • runtime/Lookup.h: (JSC::reifyStaticProperty):

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

4:40 PM Changeset in webkit [251353] by bshafiei@apple.com
  • 37 edits
    2 adds in branches/safari-608-branch

Apply patch. rdar://problem/56427498

4:24 PM Changeset in webkit [251352] by bshafiei@apple.com
  • 1 edit in branches/safari-608-branch/Source/WebKit/UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.h

Apply patch. rdar://problem/55954224

10:33 AM Changeset in webkit [251351] by bshafiei@apple.com
  • 1 edit in branches/safari-608-branch/Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp

Unreviewed build fix. rdar://problem/55927251

10:33 AM Changeset in webkit [251350] by bshafiei@apple.com
  • 16 edits
    2 copies
    1 move
    3 adds in branches/safari-608-branch

Cherry-pick r250589. rdar://problem/55927251

Storage Access API: document.hasStorageAccess() should return true when the cookie policy allows access
​https://bugs.webkit.org/show_bug.cgi?id=202435
<rdar://problem/55718526>

Reviewed by Brent Fulgham.

Source/WebCore:

WebKit's Storage Access API implementation has so far only looked at whether ITP is
blocking cookie access or not. However, the default cookie policy is still in
effect underneath ITP. document.hasStorageAccess() should return true if the
third-party:
a) is not classified by ITP, and
b) has cookies which implies it can use cookies as third-party according to the
default cookie policy.

Tests: http/tests/storageAccess/has-storage-access-false-by-default-ephemeral.html

http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-ephemeral.html
http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies.html

  • platform/network/NetworkStorageSession.h:
  • platform/network/cocoa/NetworkStorageSessionCocoa.mm: (WebCore::NetworkStorageSession::hasCookies const):
  • platform/network/curl/NetworkStorageSessionCurl.cpp: (WebCore::NetworkStorageSession::hasCookies const):

Not yet implemented. Always says false.

  • platform/network/soup/NetworkStorageSessionSoup.cpp: (WebCore::NetworkStorageSession::hasCookies const):

Not yet implemented. Always says false.

Source/WebKit:

WebKit's Storage Access API implementation has so far only looked at whether ITP is
blocking cookie access or not. However, the default cookie policy is still in
effect underneath ITP. document.hasStorageAccess() should return true if the
third-party:
a) is not classified by ITP, and
b) has cookies which implies it can use cookies as third-party according to the
default cookie policy.

  • NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp: (WebKit::ResourceLoadStatisticsMemoryStore::hasStorageAccess):
  • NetworkProcess/Classifier/WebResourceLoadStatisticsStore.cpp: (WebKit::WebResourceLoadStatisticsStore::hasCookies):
  • NetworkProcess/Classifier/WebResourceLoadStatisticsStore.h:
  • NetworkProcess/NetworkConnectionToWebProcess.cpp: (WebKit::NetworkConnectionToWebProcess::hasStorageAccess):
  • NetworkProcess/NetworkProcess.cpp: (WebKit::NetworkProcess::registrableDomainsWithWebsiteData):

Tools:

This change makes sure topPrivatelyControlledDomain() correctly handles domains
with leading dots, as often used in cookie domains.

  • TestWebKitAPI/Tests/WebCore/PublicSuffix.cpp: (TestWebKitAPI::TEST_F):

LayoutTests:

WebKit's Storage Access API implementation has so far only looked at whether ITP is
blocking cookie access or not. However, the default cookie policy is still in
effect underneath ITP. document.hasStorageAccess() should return true if the
third-party:
a) is not classified by ITP, and
b) has cookies which implies it can use cookies as third-party according to the
default cookie policy.

  • http/tests/storageAccess/has-storage-access-false-by-default-ephemeral-expected.txt: Added.
  • http/tests/storageAccess/has-storage-access-false-by-default-ephemeral.html: Copied from LayoutTests/http/tests/storageAccess/has-storage-access-true-if-feature-off.html.
  • http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-ephemeral-expected.txt: Added.
  • http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-ephemeral.html: Copied from LayoutTests/http/tests/storageAccess/has-storage-access-true-if-feature-off.html.
  • http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies-expected.txt: Added.
  • http/tests/storageAccess/has-storage-access-true-if-third-party-has-cookies.html: Renamed from LayoutTests/http/tests/storageAccess/has-storage-access-true-if-feature-off.html.
  • platform/ios/TestExpectations:
  • platform/mac-wk2/TestExpectations:

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

10:33 AM Changeset in webkit [251349] by bshafiei@apple.com
  • 8 edits
    2 copies
    2 adds in branches/safari-608-branch

Cherry-pick r251086. rdar://problem/56237429

[Cocoa] REGRESSION (r245672): Contenteditable with optical sizing freezes Safari
​https://bugs.webkit.org/show_bug.cgi?id=202262

Reviewed by Tim Horton.

Source/WebKit:

r250640 didn't go far enough. We need to apply the same fix everywhere [NSFontDescriptor fontDescriptorWithFontAttributes:] is called.

  • Shared/Cocoa/ArgumentCodersCocoa.mm: (IPC::decodeFontInternal):
  • Shared/Cocoa/CoreTextHelpers.h: Added.
  • Shared/Cocoa/CoreTextHelpers.mm: Added. (fontDescriptorWithFontAttributes):
  • SourcesCocoa.txt:
  • UIProcess/Cocoa/WebViewImpl.mm: (WebKit::WebViewImpl::updateFontManagerIfNeeded):
  • UIProcess/mac/WebPopupMenuProxyMac.mm: (WebKit::WebPopupMenuProxyMac::showPopupMenu):
  • WebKit.xcodeproj/project.pbxproj:

LayoutTests:

  • fast/forms/contenteditable-font-optical-size-expected.txt: Added.
  • fast/forms/contenteditable-font-optical-size.html: Added.

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

10:33 AM Changeset in webkit [251348] by bshafiei@apple.com
  • 12 edits in branches/safari-608-branch

Cherry-pick r250887. rdar://problem/56061121

Partially undo r250811
​https://bugs.webkit.org/show_bug.cgi?id=202715
<rdar://problem/56084287>

Reviewed by Chris Dumez.

Source/WebCore:

This patch changes the SerializedScriptValue to always wrap CryptoKey objects again.
CryptoKey objects could belong to an array or another object. In those cases, IDBObjectStore
cannot set the flag for the embedded Cryptokey objects. Neither can postMessage to unset
the flag. Therefore, there is no way to separate the serialization process into two and
this patch restores the old behaviour. However, the hardening part of r250811 is kept
and therefore the crash should still be prevented.

No new test, updated existing test

  • Modules/indexeddb/IDBObjectStore.cpp: (WebCore::IDBObjectStore::putOrAdd): (WebCore::JSC::setIsWrappingRequiredForCryptoKey): Deleted.
  • bindings/js/SerializedScriptValue.cpp: (WebCore::CloneSerializer::dumpIfTerminal): (WebCore::CloneDeserializer::readTerminal):
  • crypto/CryptoKey.h: (WebCore::CryptoKey::allows const): (WebCore::CryptoKey::isWrappingRequired const): Deleted. (WebCore::CryptoKey::setIsWrappingRequired): Deleted. (): Deleted.
  • dom/ScriptExecutionContext.h:

Tools:

  • TestWebKitAPI/Tests/WebKit/navigation-client-default-crypto.html: Modified to crash if SerializedScriptValue doesn't wrap CryptoKey objects.

LayoutTests:

Some rebaselines.

  • crypto/workers/subtle/ec-postMessage-worker-expected.txt:
  • crypto/workers/subtle/hrsa-postMessage-worker-expected.txt:
  • crypto/workers/subtle/rsa-postMessage-worker-expected.txt:

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

10:33 AM Changeset in webkit [251347] by bshafiei@apple.com
  • 3 edits in branches/safari-608-branch/LayoutTests

Cherry-pick r250844. rdar://problem/56061121

Unreviewed, test gardening

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

10:33 AM Changeset in webkit [251346] by bshafiei@apple.com
  • 3 edits
    2 adds in branches/safari-608-branch

Cherry-pick r250929. rdar://problem/56280990

RunResolver::rangeForRendererWithOffsets should check for range end
​https://bugs.webkit.org/show_bug.cgi?id=202761
<rdar://problem/55917924>

Reviewed by Antti Koivisto.

Source/WebCore:

This patch ensures that when rangeForRenderer comes back with a collapsed run (empty range), rangeForRendererWithOffsets returns an empty range as well.

Test: fast/text/simple-line-layout-range-check-end.html

  • rendering/SimpleLineLayoutResolver.cpp: (WebCore::SimpleLineLayout::RunResolver::rangeForRendererWithOffsets const):

LayoutTests:

  • fast/text/simple-line-layout-range-check-end-expected.txt: Added.
  • fast/text/simple-line-layout-range-check-end.html: Added.

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

10:33 AM Changeset in webkit [251345] by bshafiei@apple.com
  • 5 edits in branches/safari-608-branch

Cherry-pick r250833. rdar://problem/56280706

Apply patch. rdar://problem/55920073

git-svn-id: ​https://svn.webkit.org/repository/webkit/branches/safari-608.3.10.1-branch@250833 268f45cc-cd09-0410-ab3c-d52691b4dbfc

10:33 AM Changeset in webkit [251344] by bshafiei@apple.com
  • 23 edits
    3 adds in branches/safari-608-branch

Cherry-pick r250811. rdar://problem/56061121

Only wrapping CryptoKeys for IDB during serialization
​https://bugs.webkit.org/show_bug.cgi?id=202500
<rdar://problem/52445927>

Reviewed by Chris Dumez.

Source/WebCore:

Wrapping CryptoKeys during IDB serialization is a legacy request from Netflix when WebKit was an
early adopter. It is not necessary for other kinds of serialization. However, given existing keys
stored in users' idb are wrapped, the wrapping/unwrapping mechanism cannot be easily discarded.
Therefore, this patch restricts the wrapping/unwrapping mechanism to idb only.

To do so, a isWrappingRequired flag is added to CryptoKey such that whenever idb sees a CryptoKey,
it can set it. SerializedScriptValue will then only wrap a CryptoKey when this flag is set. Otherwise,
a new tag UnwrappedCryptoKeyTag is used to store unwrapped CryptoKeys in order to keep the old CryptoKeyTag
binaries intact. For deserialization, each type will be deserialized differently.

Besides the above, this patch also hardens WorkerGlobalScope::wrapCryptoKey/unwrapCryptoKey for
any potential racy issues. CryptoBooleanContainer is introduced to capture boolean in the lambda.
workerGlobalScope is replaced with workerMessagingProxy. Now, every variables captured in the lambdas
should be either a copy or a thread safe ref of the original object.

Test: crypto/workers/subtle/aes-indexeddb.html

  • Modules/indexeddb/IDBObjectStore.cpp: (WebCore::JSC::setIsWrappingRequiredForCryptoKey): (WebCore::IDBObjectStore::putOrAdd):
  • bindings/js/SerializedScriptValue.cpp: (WebCore::CloneSerializer::dumpIfTerminal): (WebCore::CloneDeserializer::readTerminal):
  • crypto/CryptoKey.h: (WebCore::CryptoKey::isWrappingRequired const): (WebCore::CryptoKey::setIsWrappingRequired):
  • dom/ScriptExecutionContext.h:
  • workers/WorkerGlobalScope.cpp: (WebCore::CryptoBooleanContainer::create): (WebCore::CryptoBooleanContainer::boolean const): (WebCore::CryptoBooleanContainer::setBoolean): (WebCore::WorkerGlobalScope::wrapCryptoKey): (WebCore::WorkerGlobalScope::unwrapCryptoKey):
  • workers/WorkerGlobalScope.h:
  • workers/WorkerLoaderProxy.h: (WebCore::WorkerLoaderProxy::isWorkerMessagingProxy const):
  • workers/WorkerMessagingProxy.h: (isType):

Tools:

Modifies IndexedDB.StructuredCloneBackwardCompatibility test to include CryptoKeys.

  • TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibility.mm: (-[StructuredCloneBackwardCompatibilityNavigationDelegate _webCryptoMasterKeyForWebView:]): (TEST):
  • TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibility.sqlite3:
  • TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibility.sqlite3-shm:
  • TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibility.sqlite3-wal:
  • TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibilityRead.html:
  • TestWebKitAPI/Tests/WebKitCocoa/IndexedDBStructuredCloneBackwardCompatibilityWrite.html:

LayoutTests:

Adds a new test aes-indexeddb.html to do idb in workers and makes
other tests more deterministic.

  • crypto/workers/subtle/aes-indexeddb-expected.txt: Added.
  • crypto/workers/subtle/aes-indexeddb.html: Added.
  • crypto/workers/subtle/ec-postMessage-worker-expected.txt:
  • crypto/workers/subtle/ec-postMessage-worker.html:
  • crypto/workers/subtle/hrsa-postMessage-worker-expected.txt:
  • crypto/workers/subtle/hrsa-postMessage-worker.html:
  • crypto/workers/subtle/resources/aes-indexeddb.js: Added.
  • crypto/workers/subtle/rsa-postMessage-worker-expected.txt:
  • crypto/workers/subtle/rsa-postMessage-worker.html:

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

10:33 AM Changeset in webkit [251343] by bshafiei@apple.com
  • 11 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r250780. rdar://problem/56061126

Provide options for DTTZ to happen in more situations
​https://bugs.webkit.org/show_bug.cgi?id=202634
<rdar://problem/55732762>

Reviewed by Antoine Quint.

Add two options that can be enabled to trigger double tap zooming
in more places.

Firstly, an option to keep listening for a double-tap-to-zoom if the
first tap found a click handler on the body or document element. The
tap will still be dispatched. This is probably the most common case
for disabling a DTTZ.

Secondly, an option to always keep listening for a double-tap-to-zoom,
even if there was a clickable (non-root) element under the first tap.

  • Shared/WebPreferences.yaml: Add ZoomOnDoubleTapWhenRoot and AlwaysZoomOnDoubleTap.
  • UIProcess/PageClient.h: The message from the WebProcess now tells the UIProcess if the tapped element was a root-level (document or body).
  • UIProcess/WebPageProxy.h:
  • UIProcess/WebPageProxy.messages.in:
  • UIProcess/ios/PageClientImplIOS.h:
  • UIProcess/ios/PageClientImplIOS.mm: (WebKit::PageClientImpl::handleSmartMagnificationInformationForPotentialTap):
  • UIProcess/ios/WKContentViewInteraction.h:
  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _endPotentialTapAndEnableDoubleTapGesturesIfNecessary]): (-[WKContentView _handleSmartMagnificationInformationForPotentialTap:renderRect:fitEntireRect:viewportMinimumScale:viewportMaximumScale:nodeIsRootLevel:]): Handle the two new options.
  • UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::handleSmartMagnificationInformationForPotentialTap):
  • WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::potentialTapAtPosition): Check if the tap was on a root-level element.

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

10:33 AM Changeset in webkit [251342] by bshafiei@apple.com
  • 6 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r250755. rdar://problem/56061126

Use a better name than allowFastClicksEverywhere
​https://bugs.webkit.org/show_bug.cgi?id=202607
<rdar://problem/55997133>

Reviewed by Tim Horton.

This preference name is quite confusing. Change it to
PreferFasterClickOverDoubleTap.

  • Shared/WebPreferences.yaml:
  • Shared/WebPreferencesDefaultValues.h:
  • UIProcess/WebPageProxy.h: (WebKit::WebPageProxy::preferFasterClickOverDoubleTap const): (WebKit::WebPageProxy::allowsFastClicksEverywhere const): Deleted.
  • UIProcess/ios/WKContentViewInteraction.mm: (-[WKContentView _handleSmartMagnificationInformationForPotentialTap:renderRect:fitEntireRect:viewportMinimumScale:viewportMaximumScale:]):
  • UIProcess/ios/WebPageProxyIOS.mm: (WebKit::WebPageProxy::effectiveContentModeAfterAdjustingPolicies):

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

10:33 AM Changeset in webkit [251341] by bshafiei@apple.com
  • 3 edits in branches/safari-608-branch/Source/WebKit

Cherry-pick r250751. rdar://problem/56280731

Unreviewed, build fix after r250729

  • UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm:
  • UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h:

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

10:33 AM Changeset in webkit [251340] by bshafiei@apple.com
  • 24 edits
    6 copies
    2 adds in branches/safari-608-branch

Cherry-pick r250729. rdar://problem/56280731

[WebAuthn] Implement _WKWebAuthenticationPanel SPI
​https://bugs.webkit.org/show_bug.cgi?id=202559
<rdar://problem/55932094>

Reviewed by Brent Fulgham.

Source/WebKit:

This patch implements _WKWebAuthenticationPanel SPI. Here is the structure:
1) API::WebAuthenticationPanel is the APIObject of _WKWebAuthenticationPanel. It is owned by AuthenticatorManager.
The lifetime of _WKWebAuthenticationPanel on the other hand is managed by clients. This binding is the surface
where clients could interact with WebKit's WebAuthentication implementation.
2) API::WebAuthenticationPanelClient is a base class representing _WKWebAuthenticationPanelDelegate. Its subclass
WebKit::WebAuthenticationPanelClient implements bridges to _WKWebAuthenticationPanelDelegate methods. It is owned by
API::WebAuthenticationPanel. A weak pointer of WebKit::WebAuthenticationPanelClient is kept in _WKWebAuthenticationPanel
to get the _WKWebAuthenticationPanelDelegate set by clients or nil otherwise. This binding is the surface where WebKit
interacts with clients.
3) WebAuthenticationPanelFlags is the mirror of enums within _WKWebAuthenticationPanel.

Implementation wise, this patch implements:
1) -[WKUIDelegatePrivate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:], this is bridged from
the regular UIDelegate route. Noted, WKFrameInfo is nil for now, a follow up on Bug 202563 will take care of it. This
will be called from AuthenticatorManager::runPanel() which gates the start of discovery on the callback. For clients
that don't implement the delegate, the callback will always be called with _WKWebAuthenticationPanelResultUnavailable
to allow WebKit run on non-UI mode. A specific C API hack is added to always return _WKWebAuthenticationPanelResultPresented
in WebKitTestRunner for layout tests.
2) -[_WKWebAuthenticationPanelDelegate panel:updateWebAuthenticationPanel:] will be implemented in Bug 200932.
3) -[_WKWebAuthenticationPanelDelegate panel:dismissWebAuthenticationPanelWithResult:], this is bridged from
API::WebAuthenticationPanel/API::WebAuthenticationPanelClient. This will be called whenever AuthenticatorManager::m_pendingCompletionHandler
is invoked. Depending on the respond, _WKWebAuthenticationResult will be returned accordingly. To facilitate that,
invokePendingCompletionHandler is crafted to bundle those two operations.
4) -[_WKWebAuthenticationPanel cancel] will be implemented in Bug 191523.

Besides the above, this patch also silents the NFC action sheet.

  • Platform/spi/Cocoa/NearFieldSPI.h:
  • Shared/API/APIObject.h:
  • Shared/Cocoa/APIObject.mm: (API::Object::newObject):
  • Sources.txt:
  • SourcesCocoa.txt:
  • UIProcess/API/APIUIClient.h: (API::UIClient::runWebAuthenticationPanel):
  • UIProcess/API/APIWebAuthenticationPanel.cpp: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm. (API::WebAuthenticationPanel::create): (API::WebAuthenticationPanel::WebAuthenticationPanel): (API::WebAuthenticationPanel::setClient):
  • UIProcess/API/APIWebAuthenticationPanel.h: Copied from Source/WebKit/UIProcess/WebAuthentication/WebAuthenticationRequestData.h.
  • UIProcess/API/APIWebAuthenticationPanelClient.h: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h. (API::WebAuthenticationPanelClient::dismissPanel const):
  • UIProcess/API/C/WKPage.cpp: (WKPageSetPageUIClient):
  • UIProcess/API/C/WKPageUIClient.h:
  • UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm: (-[_WKWebAuthenticationPanel dealloc]): (-[_WKWebAuthenticationPanel relyingPartyID]): (-[_WKWebAuthenticationPanel delegate]): (-[_WKWebAuthenticationPanel setDelegate:]): (-[_WKWebAuthenticationPanel _apiObject]): (-[_WKWebAuthenticationPanel _initWithRelayingPartyID:]): Deleted.
  • UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h:
  • UIProcess/Cocoa/UIDelegate.h:
  • UIProcess/Cocoa/UIDelegate.mm: (WebKit::UIDelegate::setDelegate): (WebKit::webAuthenticationPanelResult): (WebKit::UIDelegate::UIClient::runWebAuthenticationPanel):
  • UIProcess/WebAuthentication/AuthenticatorManager.cpp: (WebKit::WebCore::isFeatureEnabled): (WebKit::WebCore::getRpId): (WebKit::AuthenticatorManager::handleRequest): (WebKit::AuthenticatorManager::respondReceived): (WebKit::AuthenticatorManager::startDiscovery): (WebKit::AuthenticatorManager::initTimeOutTimer): (WebKit::AuthenticatorManager::timeOutTimerFired): (WebKit::AuthenticatorManager::runPanel): (WebKit::AuthenticatorManager::startRequest): (WebKit::AuthenticatorManager::invokePendingCompletionHandler): (WebKit::AuthenticatorManagerInternal::collectTransports): Deleted. (WebKit::AuthenticatorManagerInternal::processGoogleLegacyAppIdSupportExtension): Deleted.
  • UIProcess/WebAuthentication/AuthenticatorManager.h: (WebKit::AuthenticatorManager::pendingCompletionHandler): Deleted.
  • UIProcess/WebAuthentication/Cocoa/NfcConnection.mm: (WebKit::NfcConnection::NfcConnection):
  • UIProcess/WebAuthentication/Cocoa/NfcService.mm: (WebKit::NfcService::platformStartDiscovery):
  • UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.h: Copied from Source/WebKit/UIProcess/WebAuthentication/WebAuthenticationRequestData.h.
  • UIProcess/WebAuthentication/Cocoa/WebAuthenticationPanelClient.mm: Copied from Source/WebKit/UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp. (WebKit::WebAuthenticationPanelClient::WebAuthenticationPanelClient): (WebKit::wkWebAuthenticationResult): (WebKit::WebAuthenticationPanelClient::dismissPanel const):
  • UIProcess/WebAuthentication/Mock/MockAuthenticatorManager.cpp: (WebKit::MockAuthenticatorManager::respondReceivedInternal):
  • UIProcess/WebAuthentication/WebAuthenticationPanelFlags.h: Copied from Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanelInternal.h.
  • UIProcess/WebAuthentication/WebAuthenticationRequestData.h:
  • UIProcess/WebAuthentication/WebAuthenticatorCoordinatorProxy.cpp: (WebKit::WebAuthenticatorCoordinatorProxy::makeCredential): (WebKit::WebAuthenticatorCoordinatorProxy::getAssertion):
  • WebKit.xcodeproj/project.pbxproj:

Tools:

This patch adds a very limited test case to _WKWebAuthenticationPanel.
Bug 202560 and Bug 202565 will follow up to write more tests.

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WebKitCocoa/_WKWebAuthenticationPanel.mm: Added. (-[TestWebAuthenticationPanelDelegate panel:dismissWebAuthenticationPanelWithResult:]): (-[TestWebAuthenticationPanelUIDelegate webView:runWebAuthenticationPanel:initiatedByFrame:completionHandler:]): (TestWebKitAPI::TEST):
  • TestWebKitAPI/Tests/WebKitCocoa/web-authentication-get-assertion.html: Added.
  • WebKitTestRunner/TestController.cpp: (WTR::runWebAuthenticationPanel): (WTR::TestController::createWebViewWithOptions):

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

10:32 AM Changeset in webkit [251339] by bshafiei@apple.com
  • 2 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r250716. rdar://problem/56280993

AppleTV named as XSS-payloads trigger when AirPlay is used
​https://bugs.webkit.org/show_bug.cgi?id=202534
<rdar://55931262>

Reviewed by Eric Carlson.

Ensure we escape an AirPlay's device name before inserting its name into the DOM.

  • Modules/modern-media-controls/media/placard-support.js: (PlacardSupport.prototype._updateAirPlayPlacard): (PlacardSupport): (escapeHTML):

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

10:32 AM Changeset in webkit [251338] by bshafiei@apple.com
  • 5 edits in branches/safari-608-branch/Source/WebCore

Cherry-pick r250694. rdar://problem/56061131

[iOS] WebContent process can be interrupted during suspension; loses "Now Playing" status

​https://bugs.webkit.org/show_bug.cgi?id=202537
<rdar://problem/55952707>

Reviewed by Eric Carlson.

Always deactivate the AVAudioSession when the last playing PlatformAudioSession ends playback and the application is in the background.

  • platform/audio/PlatformMediaSessionManager.cpp: (WebCore::PlatformMediaSessionManager::removeSession): (WebCore::PlatformMediaSessionManager::processWillSuspend): (WebCore::PlatformMediaSessionManager::maybeDeactivateAudioSession):
  • platform/audio/PlatformMediaSessionManager.h: (WebCore::PlatformMediaSessionManager::isApplicationInBackground const):
  • platform/audio/ios/MediaSessionManagerIOS.h:
  • platform/audio/ios/MediaSessionManagerIOS.mm: (WebCore::MediaSessionManageriOS::sessionWillEndPlayback):

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

10:32 AM Changeset in webkit [251337] by bshafiei@apple.com
  • 5 edits in branches/safari-608-branch/Source

Cherry-pick r250642. rdar://problem/56280704

[iOS] When hit testing for a context menu interaction, do not consider whether the element is contenteditable
​https://bugs.webkit.org/show_bug.cgi?id=202498
<rdar://problem/54723131>

Reviewed by Tim Horton.

Source/WebCore:

When the user selects a context menu action, WebKit performs a hit test in order to find the
acted-on element on the page. This is separate from the hit test performed to generate the
context menu's targeted preview. Since an arbitrary amount of time can elapse between
preview generation and action selection, this second hit-tests might return a different
element.

One case where we know a different element can be returned is in apps that dynamically
enable and disable editing. If editing is disabled when the first hit test occurs but is
enabled when the second one occurs, different elements will be returned due to
Frame::qualifyingNodeAtViewportLocation preferring to return the root editable element when
the approximate node is contenteditable.

While the appropriate long-term fix is to only hit-test once and use that element for both
preview generation and action selection, this patch implements a short-term fix to address
the specific problem in rdar://problem/54723131 by disabling the contenteditable behavior
described above for context menu interaction hit testing.

The long-term fix is tracked by <​https://webkit.org/b/202499>.

  • page/Frame.h:
  • page/ios/FrameIOS.mm: (WebCore::Frame::qualifyingNodeAtViewportLocation): (WebCore::Frame::approximateNodeAtViewportLocationLegacy): (WebCore::ancestorRespondingToClickEventsNodeQualifier): (WebCore::Frame::nodeRespondingToClickEvents): (WebCore::Frame::nodeRespondingToDoubleClickEvent): (WebCore::Frame::nodeRespondingToInteraction): (WebCore::Frame::nodeRespondingToScrollWheelEvents):

Source/WebKit:

  • WebProcess/WebPage/ios/WebPageIOS.mm: (WebKit::WebPage::startInteractionWithElementAtPosition): Changed to call WebCore::Frame::nodeRespondingToInteraction.

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

10:32 AM Changeset in webkit [251336] by bshafiei@apple.com
  • 2 edits in branches/safari-608-branch/Source/JavaScriptCore

Cherry-pick r250629. rdar://problem/56280996

FTL OSR exit shouldn't bother updating get_by_id array profiles that have changed modes
​https://bugs.webkit.org/show_bug.cgi?id=202493

Reviewed by Saam Barati.

I added this optimization for DFG but forgot to do it for the FTL
at the same time. This patch rectifies that.

  • ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub):

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

10:32 AM Changeset in webkit [251335] by bshafiei@apple.com
  • 4 edits
    2 adds in branches/safari-608-branch

Cherry-pick r250585. rdar://problem/56280995

ObjectAllocationSinkingPhase shouldn't insert hints for allocations which are no longer valid
​https://bugs.webkit.org/show_bug.cgi?id=199361
<rdar://problem/52454940>

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/allocation-sinking-hints-are-valid-ssa-2.js: Added. (main.fn): (main.executor): (main):
  • stress/allocation-sinking-hints-are-valid-ssa.js: Added. (main.fn): (main.executor): (main):

Source/JavaScriptCore:

In a prior fix to the object allocation sinking phase, I added code where we
made sure to insert PutHints over Phis for fields of an object at control flow
merge points. However, that code didn't consider that the base of the PutHint
may no longer be a valid heap location. This could cause us to emit invalid
SSA code by referring to a node which does not dominate the PutHint location.
This patch fixes the bug to only emit the PutHints when valid.

This patch also makes it so that DFGValidate actually validates that the graph
is in valid SSA form. E.g, any use of a node N must be dominated by N.

  • dfg/DFGObjectAllocationSinkingPhase.cpp:
  • dfg/DFGValidate.cpp:

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

10:32 AM Changeset in webkit [251334] by bshafiei@apple.com
  • 6 edits
    2 adds in branches/safari-608-branch

Cherry-pick r250431. rdar://problem/55927251

Storage Access API: document.hasStorageAccess() should return false by default
​https://bugs.webkit.org/show_bug.cgi?id=202281
<rdar://problem/55718526>

Reviewed by Alex Christensen.

document.hasStorageAccess() should return false by default so that it only
returns true if the context has asked for and been granted storage access.

Source/WebKit:

  • NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp: (WebKit::ResourceLoadStatisticsDatabaseStore::hasStorageAccess):
  • NetworkProcess/Classifier/ResourceLoadStatisticsMemoryStore.cpp: (WebKit::ResourceLoadStatisticsMemoryStore::hasStorageAccess):

LayoutTests:

  • http/tests/storageAccess/has-storage-access-false-by-default-expected.txt: Added.
  • http/tests/storageAccess/has-storage-access-false-by-default.html: Added.
  • platform/ios/TestExpectations:

The new test is marked as [ Pass ].

  • platform/mac-wk2/TestExpectations:

The new test is marked as [ Pass ].

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

10:32 AM Changeset in webkit [251333] by bshafiei@apple.com
  • 8 edits in branches/safari-608-branch

Cherry-pick r250416. rdar://problem/55954224

SubFrameSOAuthorizationSession should ensure messages are posted in the right order to the parent frame
​https://bugs.webkit.org/show_bug.cgi?id=202061
<rdar://problem/55485666>

Reviewed by Youenn Fablet.

Source/WebKit:

This patch ensures messages that signal the process of SOAuthorization interception are posted in
the right order to the parent frame. Before this patch, there are chances that SOAuthorizationDidCancel
could be posted to the parent before SOAuthorizationDidStart. There are few causes that lead to
this race condition:
1) SubFrameSOAuthorizationSession::beforeStart posts SOAuthorizationDidStart in the next runloop. So
extension could have the chance to invoke SubFrameSOAuthorizationSession::fallBackToWebPathInternal
before SOAuthorizationDidStart is posted.
2) Even if the order is right in the UI process, it is not guaranteed that Web process will strictly
follow the order as the loading process is async.

To fix the issue:
1) SubFrameSOAuthorizationSession::beforeStart now posts SOAuthorizationDidStart in the same runloop.
2) Observer is introduced in FrameLoadState such that SubFrameSOAuthorizationSession could know if
the loading is finished. With this new capacity, SubFrameSOAuthorizationSession can ensure it only
posts next message when the previous message has been posted.

Implementation wise, a deque to queue requests is provided to maintain order.
1) When new request is added to the deque, SubFrameSOAuthorizationSession will only load the request
if it is the only element in the deque. Otherwise, it does nothing.
2) When SubFrameSOAuthorizationSession receives didFinishLoad, it pops the head of the queue and loads
the next request in the queue if any.
The above design should guarantee all requests are loaded in sequence.

  • UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.h:
  • UIProcess/Cocoa/SOAuthorization/SubFrameSOAuthorizationSession.mm: (WebKit::SubFrameSOAuthorizationSession::SubFrameSOAuthorizationSession): (WebKit::SubFrameSOAuthorizationSession::~SubFrameSOAuthorizationSession): (WebKit::SubFrameSOAuthorizationSession::fallBackToWebPathInternal): (WebKit::SubFrameSOAuthorizationSession::completeInternal): (WebKit::SubFrameSOAuthorizationSession::beforeStart): (WebKit::SubFrameSOAuthorizationSession::didFinishLoad): (WebKit::SubFrameSOAuthorizationSession::appendRequestToLoad): (WebKit::SubFrameSOAuthorizationSession::loadRequestToFrame): (WebKit::SubFrameSOAuthorizationSession::loadDataToFrame): Deleted. (WebKit::SubFrameSOAuthorizationSession::postDidCancelMessageToParent): Deleted.
  • UIProcess/FrameLoadState.cpp: (WebKit::FrameLoadState::addObserver): (WebKit::FrameLoadState::removeObserver): (WebKit::FrameLoadState::didFinishLoad):
  • UIProcess/FrameLoadState.h:

Tools:

Adds tests that check the order of messages posted by SubFrameSOAuthorizationSession.

  • TestWebKitAPI/Tests/WebKitCocoa/TestSOAuthorization.mm: (-[TestSOAuthorizationScriptMessageHandler userContentController:didReceiveScriptMessage:]): (resetState): (TestWebKitAPI::TEST):

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

10:32 AM Changeset in webkit [251332] by bshafiei@apple.com
  • 3 edits
    1 add in branches/safari-608-branch

Cherry-pick r249959. rdar://problem/56280989

CheckArray on DirectArguments/ScopedArguments does not filter out slow put array storage
​https://bugs.webkit.org/show_bug.cgi?id=201853
<rdar://problem/53805461>

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/direct-arguments-check-array-filter-type.js: Added. (foo):

Source/JavaScriptCore:

We were claiming CheckArray for ScopedArguments/DirectArguments was filtering
out SlowPutArrayStorage. It does no such thing. We just check that the object
is either ScopedArguments/DirectArguments.

  • dfg/DFGArrayMode.h: (JSC::DFG::ArrayMode::arrayModesThatPassFiltering const): (JSC::DFG::ArrayMode::arrayModesWithIndexingShapes const): (JSC::DFG::ArrayMode::arrayModesWithIndexingShape const): Deleted.

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

10:32 AM Changeset in webkit [251331] by bshafiei@apple.com
  • 15 edits
    3 adds in branches/safari-608-branch

Cherry-pick r249517. rdar://problem/56000099

Mail appears to be double inverting code copied from Notes, Xcode, or Terminal.
​https://bugs.webkit.org/show_bug.cgi?id=201368
rdar://problem/40529867

Reviewed by Ryosuke Niwa.

Source/WebCore:

Dark mode content that is pasted should have the inline styles inverse color
transformed by the color filter to match the color filtered document contents.

Layout Test: editing/pasteboard/paste-dark-mode-color-filtered.html
API Tests: PasteHTML.TransformColorsOfDarkContent, PasteHTML.DoesNotTransformColorsOfLightContent,

PasteRTFD.TransformColorsOfDarkContent, PasteRTFD.DoesNotTransformColorsOfLightContent

  • editing/EditingStyle.cpp: (WebCore::EditingStyle::inverseTransformColorIfNeeded): Added caret-color to the transformed properties.
  • editing/ReplaceSelectionCommand.cpp: (WebCore::fragmentNeedsColorTransformed): Added. (WebCore::ReplaceSelectionCommand::inverseTransformColor): Added. (WebCore::ReplaceSelectionCommand::doApply): Call fragmentNeedsColorTransformed() and inverseTransformColor().
  • editing/ReplaceSelectionCommand.h:

Tools:

Added Tests: PasteHTML.TransformColorsOfDarkContent, PasteHTML.DoesNotTransformColorsOfLightContent,

PasteRTFD.TransformColorsOfDarkContent, PasteRTFD.DoesNotTransformColorsOfLightContent

  • TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
  • TestWebKitAPI/Tests/WebKitCocoa/PasteHTML.mm: (createWebViewWithCustomPasteboardDataSetting): Added argument to enable color filter.
  • TestWebKitAPI/Tests/WebKitCocoa/PasteRTFD.mm: (createWebViewWithCustomPasteboardDataEnabled): Added argument to enable color filter.
  • TestWebKitAPI/Tests/WebKitCocoa/rich-color-filtered.html: Added.
  • TestWebKitAPI/cocoa/TestWKWebView.h:
  • TestWebKitAPI/cocoa/TestWKWebView.mm: (-[TestWKWebView forceDarkMode]):

LayoutTests:

  • TestExpectations:
  • editing/pasteboard/paste-dark-mode-color-filtered-expected.txt: Added.
  • editing/pasteboard/paste-dark-mode-color-filtered.html: Added.
  • platform/ios-12/TestExpectations:
  • platform/ios/TestExpectations:
  • platform/mac/TestExpectations:

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

8:09 AM Changeset in webkit [251330] by Alan Bujtas
  • 3 edits in trunk/Source/WebCore

[LFC][IFC] Make InlineTextItem reusable when 'segment break' behavior changes
​https://bugs.webkit.org/show_bug.cgi?id=203184
<rdar://problem/56438945>

Reviewed by Antti Koivisto.

InlineTextItem::isWhitespace should dynamically check for 'preserve new line' behavior. This way we don't have to rebuild the inline item list
when the related style property value changes.

  • layout/inlineformatting/InlineTextItem.cpp:

(WebCore::Layout::isWhitespaceCharacter):
(WebCore::Layout::moveToNextNonWhitespacePosition):
(WebCore::Layout::InlineTextItem::createAndAppendTextItems):
(WebCore::Layout::InlineTextItem::createWhitespaceItem):
(WebCore::Layout::InlineTextItem::createNonWhitespaceItem):
(WebCore::Layout::InlineTextItem::createSegmentBreakItem):
(WebCore::Layout::InlineTextItem::createEmptyItem):
(WebCore::Layout::InlineTextItem::InlineTextItem):
(WebCore::Layout::InlineTextItem::split const):
(WebCore::Layout::InlineTextItem::isWhitespace const):
(WebCore::Layout::isSoftLineBreak): Deleted.

  • layout/inlineformatting/InlineTextItem.h:

(WebCore::Layout::InlineTextItem::isSegmentBreak const):
(WebCore::Layout::InlineTextItem::isWhitespace const): Deleted.

7:56 AM Changeset in webkit [251329] by Alan Bujtas
  • 8 edits in trunk/Source/WebCore

[LFC][IFC] Move the collapsed bit from InlineItems to runs
​https://bugs.webkit.org/show_bug.cgi?id=203183

Reviewed by Antti Koivisto.
<rdar://problem/56437181>

Let's not store the collapsed bit on the InlineTextItem. All we need to know is whether the InlineTextItem content is collapsible or not.
Also when only the white-space property changes (going from preserve whitespace to not and vice versa) we don't actually need to rebuild the
InlinItem list since they don't carry any layout dependent information.
This patch also fixes leading/trailing content preservation.

  • layout/inlineformatting/InlineLine.cpp:

(WebCore::Layout::Line::Run::canBeExtended const):
(WebCore::Layout::shouldPreserveTrailingContent):
(WebCore::Layout::shouldPreserveLeadingContent):
(WebCore::Layout::Line::appendTextContent):

  • layout/inlineformatting/InlineLine.h:

(WebCore::Layout::Line::Run::isCollapsed const):
(WebCore::Layout::Line::Run::setIsCollapsed):

  • layout/inlineformatting/InlineLineLayout.cpp:

(WebCore::Layout::inlineItemWidth):

  • layout/inlineformatting/InlineTextItem.cpp:

(WebCore::Layout::InlineTextItem::createAndAppendTextItems):
(WebCore::Layout::InlineTextItem::InlineTextItem):
(WebCore::Layout::InlineTextItem::split const):

  • layout/inlineformatting/InlineTextItem.h:

(WebCore::Layout::InlineTextItem::isCollapsible const):
(WebCore::Layout::InlineTextItem::isCollapsed const): Deleted.

  • layout/inlineformatting/text/TextUtil.cpp:

(WebCore::Layout::TextUtil::isTrimmableContent): Deleted.

  • layout/inlineformatting/text/TextUtil.h:

Oct 19, 2019:

4:50 PM Changeset in webkit [251328] by rniwa@webkit.org
  • 3 edits in trunk/LayoutTests

Flaky Test: fast/events/resize-subframe-in-rendering-update.html
​https://bugs.webkit.org/show_bug.cgi?id=203140
<rdar://problem/56415948>

Reviewed by Wenson Hsieh.

Removed the assertion in setTimeout to avoid flakiness. There isn't a way to deterministically order
callbacks of setTimeout and requestAnimationFrame for this test for now.

  • fast/events/resize-subframe-in-rendering-update-expected.txt:
  • fast/events/resize-subframe-in-rendering-update.html:
4:41 PM Changeset in webkit [251327] by Chris Dumez
  • 9 edits
    2 adds in trunk

FileReader should not prevent entering the back/forward cache
​https://bugs.webkit.org/show_bug.cgi?id=203106

Reviewed by Geoffrey Garen.

Source/WebCore:

FileReader should not prevent entering the back/forward cache. To support this,
its implementation now uses a SuspendableTaskQueue to dispatch events.

Test: fast/files/file-reader-back-forward-cache.html

  • dom/ActiveDOMObject.cpp:

(WebCore::ActiveDOMObject::isAllowedToRunScript const):

  • dom/ActiveDOMObject.h:
  • dom/ScriptExecutionContext.cpp:

(WebCore::ScriptExecutionContext::resumeActiveDOMObjects):

  • fileapi/FileReader.cpp:

(WebCore::FileReader::FileReader):
(WebCore::FileReader::stop):
(WebCore::FileReader::hasPendingActivity const):
(WebCore::FileReader::readInternal):
(WebCore::FileReader::abort):
(WebCore::FileReader::didStartLoading):
(WebCore::FileReader::didReceiveData):
(WebCore::FileReader::didFinishLoading):
(WebCore::FileReader::didFail):
(WebCore::FileReader::fireEvent):

  • fileapi/FileReader.h:

LayoutTests:

Add layout test coverage.

  • TestExpectations:
  • fast/files/file-reader-back-forward-cache-expected.txt: Added.
  • fast/files/file-reader-back-forward-cache.html: Added.
12:56 PM Changeset in webkit [251326] by Adrian Perez de Castro
  • 12 edits in trunk/Source

[GTK][WPE] Fix non-unified builds after r250857
​https://bugs.webkit.org/show_bug.cgi?id=203145

Reviewed by Carlos Garcia Campos.

Source/WebCore:

No new tests needed.

  • Modules/async-clipboard/ClipboardItem.cpp: Add missing inclusion of the Clipboard.h header.
  • Modules/async-clipboard/ClipboardItemBindingsDataSource.cpp: Add missing inclusion of the

ClipboardItem.h header.

  • Modules/async-clipboard/ClipboardItemPasteboardDataSource.cpp: Add missing inclusions of

the Clipboard.h, ClipboardItem.h, and JSDOMPromiseDeferred.h headers.

  • dom/AbstractEventLoop.h: Add missing inclusion of the wtf/RefCounted.h header.
  • dom/WindowEventLoop.h: Add missing inclusion of the DocumentIdentifier.h header.
  • dom/IdleCallbackController.h: Add missing forward-declaration for the Document class.
  • dom/RadioButtonGroups.h: Add needed inclusion of of the wtf/text/AtomStringHash.h header,

needed because AtomString is used as key for a HashMap; remove the (now unneeded) of the
wtf/Forward.h header.

  • page/WheelEventTestMonitor.cpp: Add missing inclusion of the wtf/OptionSet.h header.
  • rendering/style/ShadowData.cpp: Add missing inclusion of the wtf/text/TextStream.h header.

Source/WebKit:

  • UIProcess/WebProcessProxy.cpp: Add missing inclusion of the WebBackForwardCache.h header.
11:40 AM Changeset in webkit [251325] by Simon Fraser
  • 3 edits in trunk/Source/WTF

Add support to TextStream for dumping HashMap<> and HashSet<>
​https://bugs.webkit.org/show_bug.cgi?id=202969

Reviewed by Dean Jackson.

Make it possible to output HashMap<> and HashSet<> to TextStream,
so long as key and value types are streamable. Also implement operator<<(char)
so that chars show as ASCII, rather than numbers.

  • wtf/text/TextStream.cpp:

(WTF::TextStream::operator<<):

  • wtf/text/TextStream.h:

(WTF::operator<<):

8:46 AM Changeset in webkit [251324] by mitz@apple.com
  • 9 copies
    1 add in releases/Apple/Safari Technology Preview/Safari Technology Preview 94

Added a tag for Safari Technology Preview release 94.

8:41 AM Changeset in webkit [251323] by mitz@apple.com
  • 8 copies
    1 add in releases/Apple/iOS 13.1.3

Added a tag for iOS 13.1.3.

1:31 AM Changeset in webkit [251322] by rniwa@webkit.org
  • 11 edits
    4 adds in trunk

Integrate media query evaluation into HTML5 event loop
​https://bugs.webkit.org/show_bug.cgi?id=203134
<rdar://problem/56396316>

Reviewed by Antti Koivisto.

Source/WebCore:

Moved the code to call media query listeners to HTML5 event loop's step to update the rendering:
​https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering

Tests: fast/media/mq-inverted-colors-live-update-for-listener.html

fast/media/mq-prefers-reduced-motion-live-update-for-listener.html

  • css/MediaQueryMatcher.cpp:

(WebCore::MediaQueryMatcher::evaluateAll): Renamed from styleResolverChanged.

  • css/MediaQueryMatcher.h:
  • dom/Document.cpp:

(WebCore::Document::updateElementsAffectedByMediaQueries): Split from evaluateMediaQueryList.
This function is still called right after each layout update so that picture element may start
requesting newly selected image resources without having to wait for a rendering update.
But this function will no longer execute arbitrary scripts.
(WebCore::Document::evaluateMediaQueriesAndReportChanges): Split from evaluateMediaQueryList.
Evaluates media query listeners.

  • dom/Document.h:
  • inspector/agents/InspectorPageAgent.cpp:

(WebCore::InspectorPageAgent::setEmulatedMedia): Force the evaluation of media queries for now
but this code should really be scheduling a rendering update instead so added a FIXME.

  • page/Frame.cpp:

(WebCore::Frame::setPrinting): Evaluate media queries. We should consider invoking the full
algorithm to update the rendering here. e.g. intersection observer may add more contents.

  • page/Page.cpp:

(WebCore::Page::updateRendering): Call evaluateMediaQueriesAndReportChanges.

LayoutTests:

Added tests for listening to accessiblity related media queries without having any style rules
get affected by those media queries so that we can catch any future regressions. For now,
changing accessiblity settings seem to always schedule a rendering update so there is nothing to do
when these accessibility settings do change.

  • fast/media/media-query-list-07.html: Fixed the test to be compatible with new behavior.
  • fast/media/mq-inverted-colors-live-update-for-listener-expected.txt: Added.
  • fast/media/mq-inverted-colors-live-update-for-listener.html: Added.
  • fast/media/mq-prefers-reduced-motion-live-update-for-listener-expected.txt: Added.
  • fast/media/mq-prefers-reduced-motion-live-update-for-listener.html: Added.
Note: See TracTimeline for information about the timeline view.