Timeline

Jan 21, 2018:

11:57 PM Changeset in webkit [227284] by Carlos Garcia Campos

• 2 edits in trunk/Source/WebKit

Unreviewed. Fix compile warning.

Use #include instead of #import in cross-platform code.

• Shared/WebPreferencesDefaultValues.cpp:

11:38 PM Changeset in webkit [227283] by Dewei Zhu

• 3 edits in trunk/Websites/perf.webkit.org

Should reject updating a build request which has an associated build.
​https://bugs.webkit.org/show_bug.cgi?id=181893

Reviewed by Ryosuke Niwa.

Current code does not prevent submitting to same build request multiple times.
This could lead to a build losing its associated build request.
As a result, this build will be visible in charts which is not right.
Added a check when a build request is reported.
Addressed a 'FIXME' for the race condition inside ReportProcessor->resolve_build_id by surrounding
it with a database transaction.

• public/include/report-processor.php:

Wrap adding platform and resolve_build_id with a database transaction.
Add a check to make sure only a build request has no associated build can be updated.

• server-tests/api-report-tests.js: Added unit tests accordingly.

10:41 PM Changeset in webkit [227282] by rniwa@webkit.org

• 16 edits in trunk/Source

Turning off custom pasteboard data doesn't actually turn it off in WK2
​https://bugs.webkit.org/show_bug.cgi?id=181920
<rdar://problem/36686429>

Reviewed by Wenson Hsieh.

Source/WebCore:

Replaced the global settings for custom pasteboard data by regular runtime enabled flags.

• dom/DataTransfer.cpp:

(WebCore::DataTransfer::getDataForItem const):
(WebCore::DataTransfer::shouldSuppressGetAndSetDataToAvoidExposingFilePaths const):
(WebCore::DataTransfer::setDataFromItemList):
(WebCore::DataTransfer::types const):
(WebCore::DataTransfer::commitToPasteboard):

• dom/DataTransferItemList.cpp:

(WebCore::shouldExposeTypeInItemList):

• editing/Editor.cpp:

(WebCore::createDataTransferForClipboardEvent):

• editing/cocoa/WebContentReaderCocoa.mm:

(WebCore::createFragmentAndAddResources):
(WebCore::WebContentReader::readWebArchive):

• page/DeprecatedGlobalSettings.cpp:

(WebCore::DeprecatedGlobalSettings::defaultCustomPasteboardDataEnabled): Deleted.

• page/DeprecatedGlobalSettings.h:

(WebCore::DeprecatedGlobalSettings::setCustomPasteboardDataEnabled): Deleted.
(WebCore::DeprecatedGlobalSettings::customPasteboardDataEnabled): Deleted.

• page/RuntimeEnabledFeatures.h:

(WebCore::RuntimeEnabledFeatures::setCustomPasteboardDataEnabled):
(WebCore::RuntimeEnabledFeatures::customPasteboardDataEnabled const):

• testing/InternalSettings.cpp:

(WebCore::InternalSettings::Backup::Backup):
(WebCore::InternalSettings::Backup::restoreTo):
(WebCore::InternalSettings::setCustomPasteboardDataEnabled):

Source/WebKit:

Moved the code to decide when to enable custom pasteboard data from WebCore
since we never enable this feature in WebKit1.

• Shared/WebPreferences.yaml:
• Shared/WebPreferencesDefaultValues.cpp:

(defaultCustomPasteboardDataEnabled): Added.

• Shared/WebPreferencesDefaultValues.h:

Source/WebKitLegacy/mac:

Always disable custom pasteboard data in WebKit1. See r226156 for details.

• WebView/WebPreferences.mm:

(+[WebPreferences initialize]):

• WebView/WebView.mm:

(-[WebView _preferencesChanged:]):

7:58 PM Changeset in webkit [227281] by Wenson Hsieh

• 14 edits in trunk

Add a new feature flag for EXTRA_ZOOM_MODE and reintroduce AdditionalFeatureDefines.h
​https://bugs.webkit.org/show_bug.cgi?id=181918

Reviewed by Tim Horton.

Source/JavaScriptCore:

Add EXTRA_ZOOM_MODE to FeatureDefines.xconfig (off by default).

• Configurations/FeatureDefines.xcconfig:

Source/WebCore:

Add EXTRA_ZOOM_MODE to FeatureDefines.xconfig (off by default). No change in behavior.

• Configurations/FeatureDefines.xcconfig:

Source/WebCore/PAL:

Add EXTRA_ZOOM_MODE to FeatureDefines.xconfig (off by default).

• Configurations/FeatureDefines.xcconfig:

Source/WebKit:

Add EXTRA_ZOOM_MODE to FeatureDefines.xconfig (off by default).

• Configurations/FeatureDefines.xcconfig:

Source/WebKitLegacy/mac:

Add EXTRA_ZOOM_MODE to FeatureDefines.xconfig (off by default).

• Configurations/FeatureDefines.xcconfig:

Source/WTF:

Include AdditionalFeatureDefines.h, if possible. This allows WebKitAdditions to override
the value of certain feature flags in the OpenSource WebKit repository.

• wtf/Platform.h:

Tools:

Add EXTRA_ZOOM_MODE to FeatureDefines.xconfig (off by default).

• TestWebKitAPI/Configurations/FeatureDefines.xcconfig:

7:39 PM Changeset in webkit [227280] by rniwa@webkit.org

• 5 edits
  5 adds in trunk

Release assertion in canExecuteScript when executing scripts during page cache restore
​https://bugs.webkit.org/show_bug.cgi?id=181902

Reviewed by Antti Koivisto.

Source/WebCore:

The crash was caused by an erroneous instantiation of ScriptDisallowedScope::InMainThread in CachedPage::restore.
It can execute arbitrary scripts since CachedFrame::open can update style, layout, and evaluate media queries.

This is fine because there is no way to put this page back into a page cache until the load is commited via
FrameLoader::commitProvisionalLoad is invoked later which only happens after CachedPage::restore had exited.

Also added a release assert to make sure this condition holds.

Tests: fast/history/page-cache-execute-script-during-restore.html

fast/history/page-cache-navigate-during-restore.html

• history/CachedPage.cpp:

(WebCore::CachedPageRestorationScope::CachedPageRestorationScope): Added.
(WebCore::CachedPageRestorationScope::~CachedPageRestorationScope): Added.
(WebCore::CachedPage::restore): Don't instantiate ScriptDisallowedScope::InMainThread. Set isRestoringCachedPage
on the cached pate to release-assert that there won't be any attempt to put this very page back into the cache.

• history/PageCache.cpp:

(WebCore::canCachePage): Added a release assert to make sure the page which is in the process of being restored
from the page cache is not put into the page cache.

• page/Page.h:

(WebCore::Page::setIsRestoringCachedPage): Added.
(WebCore::Page::isRestoringCachedPage const): Added.

LayoutTests:

Added regression tests for the release assertion and navigating while a document is being restored from the page cache.
WebKit should not hit any assertions in either situations.

• fast/history/page-cache-execute-script-during-restore-expected.txt: Added.
• fast/history/page-cache-execute-script-during-restore.html: Added.
• fast/history/page-cache-navigate-during-restore-expected.txt: Added.
• fast/history/page-cache-navigate-during-restore.html: Added.
• fast/history/resources/navigate-back-with-finish-test-stage.html: Added.

7:30 PM Changeset in webkit [227279] by eric.carlson@apple.com

• 18 edits in trunk

Resign NowPlaying status when no media element is eligible
​https://bugs.webkit.org/show_bug.cgi?id=181914
<rdar://problem/35294116>

Reviewed by Jer Noble.

Source/WebCore:

Updated API test.

• html/HTMLMediaElement.cpp:

(WebCore::HTMLMediaElement::removedFromAncestor): Call mediaSession->clientCharacteristicsChanged
so NowPlaying status will be updated.

• html/MediaElementSession.cpp:

(WebCore::MediaElementSession::canShowControlsManager const): Return false when being queried
for NowPlaying status in an inactive document.

• platform/audio/PlatformMediaSessionManager.cpp:

(WebCore::PlatformMediaSessionManager::updateNowPlayingInfoIfNecessary): Implement in for all
ports.

• platform/audio/PlatformMediaSessionManager.h:

(WebCore::PlatformMediaSessionManager::registeredAsNowPlayingApplication const):

• platform/audio/ios/MediaSessionManagerIOS.h:
• platform/audio/mac/MediaSessionManagerMac.h:
• platform/audio/mac/MediaSessionManagerMac.mm:

(WebCore::MediaSessionManagerMac::updateNowPlayingInfo): Call MRMediaRemoteSetCanBeNowPlayingApplication
whenever status changes.
(WebCore::PlatformMediaSessionManager::updateNowPlayingInfoIfNecessary): Deleted, implemented
in the base class.

Source/WebKit:

• UIProcess/API/Cocoa/WKWebView.mm:

(-[WKWebView _requestActiveNowPlayingSessionInfo:]): Return registeredAsNowPlayingApplication
status.

• UIProcess/API/Cocoa/WKWebViewPrivate.h:

• UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::nowPlayingInfoCallback): Ditto.

• UIProcess/WebPageProxy.h:
• UIProcess/WebPageProxy.messages.in:
• WebProcess/WebPage/Cocoa/WebPageCocoa.mm:

(WebKit::WebPage::requestActiveNowPlayingSessionInfo): Ditto.

Tools:

• TestWebKitAPI/Tests/WebKitCocoa/NowPlayingControlsTests.mm:

(-[NowPlayingTestWebView hasActiveNowPlayingSession]):
(TestWebKitAPI::TEST):

• TestWebKitAPI/Tests/WebKitCocoa/large-video-test-now-playing.html:

6:38 PM Changeset in webkit [227278] by jer.noble@apple.com

• 4 edits in trunk

REGRESSION (macOS 10.13.2): imported/w3c/web-platform-tests/media-source/mediasource-* LayoutTests failing
​https://bugs.webkit.org/show_bug.cgi?id=181891

Reviewed by Eric Carlson.

Source/WebCore:

In macOS 10.13.2, CoreMedia changed the definition of CMSampleBufferGetDuration() to return
the presentation duration rather than the decode duration. For media streams where those two
durations are identical (or at least, closely similar), this isn't a problem. But the media
file used in the WPT tests have an unusual frame cadence: decode durations go {3000, 1, 5999,
1, 5999,...} and presentation durations go {3000, 2999, 3000, 2999}. This caused one check in
the "Coded Frame Processing" algorithm to begin failing, where it checks that the delta
between the last sample's decode time and the new decode time is no more than 2x as far as
the last sample's duration. That's not a problem as long as the "duration" is the "decode
duration" and the samples are all adjacent. Once the "duration" is "presentation duration",
all the assumptions in the algorithm are invalidated. In the WPT test case, the delta between
decode times is 5999, and 2 * the presentation duration is 5998, causing all samples up to
the next sync sample to be dropped.

To work around this change in behavior, we'll adopt the same technique used by Mozilla's MSE
implementation, which was done for similar reasons. Rather than track the "last frame duration",
we'll record the "greatest frame duration", and use actual decode timestamps to derive this
duration. The "greatest frame duration" field will be reset at the same times as "last frame
duration", and will be used only in the part of the algorithm that checks for large decode
timestamp gaps.

• Modules/mediasource/SourceBuffer.cpp:

(WebCore::SourceBuffer::TrackBuffer::TrackBuffer):
(WebCore::SourceBuffer::resetParserState):
(WebCore::SourceBuffer::sourceBufferPrivateDidReceiveSample):

LayoutTests:

• platform/mac/TestExpectations:

1:41 PM Changeset in webkit [227277] by aestes@apple.com

• 5 edits
  4 adds in trunk

[ios] LayoutTest imported/w3c/web-platform-tests/payment-request/rejects_if_not_active.https.html is crashing in JSC::JSONParse
​https://bugs.webkit.org/show_bug.cgi?id=177832
<rdar://problem/34805315>

Reviewed by Tim Horton.

Source/WebCore:

Test: http/tests/paymentrequest/rejects_if_not_active.https.html

• Modules/paymentrequest/PaymentRequest.cpp:

(WebCore::PaymentRequest::show): Rejected promise if the document is not active.

LayoutTests:

Made a copy of imported/w3c/web-platform-tests/payment-request/rejects_if_not_active.https.html
and modified it to handle Apple Pay and user gesture requirements.

• http/tests/paymentrequest/rejects_if_not_active.https-expected.txt: Added.
• http/tests/paymentrequest/rejects_if_not_active.https.html: Added.
• http/tests/paymentrequest/resources/page1.html: Added.
• http/tests/paymentrequest/resources/page2.html: Added.
• platform/ios-wk2/TestExpectations:
• platform/mac-wk2/TestExpectations:

12:57 AM Changeset in webkit [227276] by aakash_jain@apple.com

• 2 edits in trunk/Tools

Fix broken unit-tests after r227192
​https://bugs.webkit.org/show_bug.cgi?id=181909

Reviewed by Carlos Garcia Campos.

• BuildSlaveSupport/build.webkit.org-config/steps_unittest.py:

Jan 20, 2018:

11:07 PM Changeset in webkit [227275] by beidson@apple.com

• 10 edits in trunk/Source/WebCore

Make garbage collection of MessagePort objects be asynchronous.
​https://bugs.webkit.org/show_bug.cgi?id=181910

Reviewed by Andy Estes.

No new tests (Covered by existing tests, including GC-specific ones).

The basic premise here is as follows:

• You can *always* GC a MessagePort that is closed
• You can *always* GC a MessagePort that has no onmessage handler, as incoming messages cannot possibly revive it.
• You can GC a MessagePort, even if it has a message handler, as long as there are no messages in flight between it and the remote port, and as long as the remote port is "maybe eligible for GC."

A MessagePort is considered "maybe eligible for GC" once hasPendingActivity is asked once.

A MessagePort loses "maybe eligible for GC" status once it is used for sending or receiving a message.

The changes to MessagePort.cpp implement the above with a tiny little bool-driven state machine.

• dom/MessagePort.cpp:

(WebCore::MessagePort::postMessage):
(WebCore::MessagePort::disentangle):
(WebCore::MessagePort::registerLocalActivity):
(WebCore::MessagePort::start):
(WebCore::MessagePort::close):
(WebCore::MessagePort::contextDestroyed):
(WebCore::MessagePort::dispatchMessages):
(WebCore::MessagePort::hasPendingActivity const):
(WebCore::MessagePort::isLocallyReachable const):
(WebCore::MessagePort::addEventListener):
(WebCore::MessagePort::removeEventListener):

• dom/MessagePort.h:

• Remove the lock and any background-thread code paths
• Add ASSERT(isMainThread())s throughout
• dom/messageports/MessagePortChannel.cpp:

(WebCore::MessagePortChannel::MessagePortChannel):
(WebCore::MessagePortChannel::includesPort):
(WebCore::MessagePortChannel::entanglePortWithProcess):
(WebCore::MessagePortChannel::disentanglePort):
(WebCore::MessagePortChannel::closePort):
(WebCore::MessagePortChannel::postMessageToRemote):
(WebCore::MessagePortChannel::takeAllMessagesForPort):
(WebCore::MessagePortChannel::checkRemotePortForActivity):
(WebCore::MessagePortChannel::hasAnyMessagesPendingOrInFlight const):

• dom/messageports/MessagePortChannel.h:

Add a callback for a MessagePortChannel to go ask the remote MessagePort object about local activity:

• dom/messageports/MessagePortChannelProvider.h:
• dom/messageports/MessagePortChannelProviderImpl.cpp:

(WebCore::MessagePortChannelProviderImpl::checkRemotePortForActivity):
(WebCore::MessagePortChannelProviderImpl::checkProcessLocalPortForActivity):
(WebCore::MessagePortChannelProviderImpl::hasMessagesForPorts_temporarySync): Deleted.

• dom/messageports/MessagePortChannelProviderImpl.h:

• Remove the lock and any background-thread code paths
• Add ASSERT(isMainThread())s throughout
• dom/messageports/MessagePortChannelRegistry.cpp:

(WebCore::MessagePortChannelRegistry::messagePortChannelCreated):
(WebCore::MessagePortChannelRegistry::messagePortChannelDestroyed):
(WebCore::MessagePortChannelRegistry::didEntangleLocalToRemote):
(WebCore::MessagePortChannelRegistry::didDisentangleMessagePort):
(WebCore::MessagePortChannelRegistry::didCloseMessagePort):
(WebCore::MessagePortChannelRegistry::didPostMessageToRemote):
(WebCore::MessagePortChannelRegistry::takeAllMessagesForPort):
(WebCore::MessagePortChannelRegistry::checkRemotePortForActivity):
(WebCore::MessagePortChannelRegistry::existingChannelContainingPort):
(WebCore::MessagePortChannelRegistry::hasMessagesForPorts_temporarySync): Deleted.

• dom/messageports/MessagePortChannelRegistry.h:

8:29 PM Changeset in webkit [227274] by aestes@apple.com

• 27 edits in trunk/Source

[Apple Pay] Stop eagerly loading PassKit.framework
​https://bugs.webkit.org/show_bug.cgi?id=181911
<rdar://problem/36555369>

Reviewed by Tim Horton.

Source/WebCore:

r226458 and r226123 added code that caused PassKit.framework to be eagerly loaded when
initializing a WKWebView. This is costly and should only be done when Apple Pay is first used.

To avoid eagerly loading PassKit, this patch does two things:

1. Instead of sending the available payment networks as part of WebPageCreationParameters,

PaymentCoordinator asks for them using a syncrhonous message the first time they are needed.

2. Instead of setting the Apple Pay preference to false when PassKit can't be loaded,

the following API entry points check for a missing PassKit and return false, or throw
exceptions, or reject promises:

• ApplePaySession.canMakePayments()
• ApplePaySession.canMakePaymentsWithActiveCard()
• ApplePaySession.openPaymentSetup()
• ApplePaySession.begin()

No new tests for (1), which causes no change in behavior. (2) was manually verified by
locally moving aside PassKit.framework, but that's not possible to do in an automated test.

• Modules/applepay/PaymentCoordinator.cpp:

(WebCore::PaymentCoordinator::PaymentCoordinator):
(WebCore::PaymentCoordinator::validatedPaymentNetwork const):
(WebCore::toHashSet): Deleted.

• Modules/applepay/PaymentCoordinator.h:
• Modules/applepay/PaymentCoordinatorClient.h:
• loader/EmptyClients.cpp:
• page/MainFrame.cpp:

(WebCore::MainFrame::MainFrame):

Removed PaymentCoordinator::m_availablePaymentNetworks and made
PaymentCoordinator::validatedPaymentNetwork() call
PaymentCoordinatorClient::validatedPaymentNetwork() instead.

• page/PageConfiguration.h:

Removed availablePaymentNetworks from PageConfiguration.

• testing/Internals.cpp:

(WebCore::Internals::Internals):

• testing/MockPaymentCoordinator.cpp:

(WebCore::MockPaymentCoordinator::validatedPaymentNetwork):

• testing/MockPaymentCoordinator.h:

Implemented PaymentCoordinatorClient::validatedPaymentNetwork().

Source/WebKit:

• Shared/WebPageCreationParameters.cpp:

(WebKit::WebPageCreationParameters::encode const):
(WebKit::WebPageCreationParameters::decode):

• Shared/WebPageCreationParameters.h:

Removed availablePaymentNetworks from WebPageCreationParameters.

• UIProcess/API/C/WKPreferences.cpp:

(WKPreferencesSetApplePayEnabled):

• UIProcess/API/Cocoa/WKWebView.mm:

(-[WKWebView _initializeWithConfiguration:]):

Stopped calling WebPaymentCoordinatorProxy::platformSupportsPayments().

• UIProcess/ApplePay/WebPaymentCoordinatorProxy.cpp:

(WebKit::WebPaymentCoordinatorProxy::availablePaymentNetworks):

• UIProcess/ApplePay/WebPaymentCoordinatorProxy.h:
• UIProcess/ApplePay/WebPaymentCoordinatorProxy.messages.in:

Added message AvailablePaymentNetworks, which synchronously returns a Vector of payment
networks.

• UIProcess/ApplePay/cocoa/WebPaymentCoordinatorProxyCocoa.mm:

(WebKit::WebPaymentCoordinatorProxy::platformCanMakePayments):

Returned false if PassKitLibrary() fails.

(WebKit::WebPaymentCoordinatorProxy::platformCanMakePaymentsWithActiveCard):
(WebKit::WebPaymentCoordinatorProxy::platformOpenPaymentSetup):

Called completionHandler with false if PassKitLibrary() fails.

(WebKit::WebPaymentCoordinatorProxy::platformAvailablePaymentNetworks):
(WebKit::WebPaymentCoordinatorProxy::availablePaymentNetworks):

Renamed availablePaymentNetworks to platformAvailablePaymentNetworks

(WebKit::WebPaymentCoordinatorProxy::platformSupportsPayments): Deleted.

• UIProcess/ApplePay/mac/WebPaymentCoordinatorProxyMac.mm:

(WebKit::WebPaymentCoordinatorProxy::platformShowPaymentUI):

Called completionHandler with false if PassKitLibrary() fails.

• UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::creationParameters):

Stopped calling WebPaymentCoordinatorProxy::availablePaymentNetworks().

• WebProcess/ApplePay/WebPaymentCoordinator.cpp:

(WebKit::WebPaymentCoordinator::availablePaymentNetworks):
(WebKit::WebPaymentCoordinator::validatedPaymentNetwork):

• WebProcess/ApplePay/WebPaymentCoordinator.h:

Implemented PaymentCoordinatorClient::validatedPaymentNetwork(). m_availablePaymentNetworks
starts off as std::nullopt, but is initialized by sending the AvailablePaymentNetworks sync
message the first time it's accessed.

• WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::WebPage):

Stopped setting PageConfiguration::availablePaymentNetworks.

Source/WebKitLegacy/mac:

• WebCoreSupport/WebPaymentCoordinatorClient.h:
• WebCoreSupport/WebPaymentCoordinatorClient.mm:

(WebPaymentCoordinatorClient::validatedPaymentNetwork):

Implemented PaymentCoordinatorClient::validatedPaymentNetwork().

12:02 PM Changeset in webkit [227273] by Chris Dumez

• 2 edits in trunk/Tools

API test URLSchemeHandler.Leaks1 is timing out on iOS simulator debug
​https://bugs.webkit.org/show_bug.cgi?id=174984
<rdar://problem/33665676>

Reviewed by Alexey Proskuryakov.

Disable URLSchemeHandler.Leaks1 API test on iOS as it sometimes times out.

• TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-leaks.mm:

(TEST):

8:55 AM Changeset in webkit [227272] by jer.noble@apple.com

• 7 edits
  2 adds in trunk

Release ASSERT when reloading Vimeo page @ WebCore: WebCore::Document::updateLayout
​https://bugs.webkit.org/show_bug.cgi?id=181840
<rdar://problem/36186214>

Reviewed by Simon Fraser.

Source/WebCore:

Test: media/video-fullscreen-reload-crash.html

Short circuit play() or pause() operations if the document is suspended or stopped.

• html/HTMLMediaElement.cpp:

(WebCore::HTMLMediaElement::playInternal):
(WebCore::HTMLMediaElement::pauseInternal):

Source/WebKit:

Updating layout while the document is suspended or stopped is unsafe.

• WebProcess/cocoa/VideoFullscreenManager.mm:

(WebKit::inlineVideoFrame):

LayoutTests:

• media/video-fullscreen-reload-crash-expected.txt: Added.
• media/video-fullscreen-reload-crash.html: Added.
• platform/ios/TestExpectations:

4:53 AM Changeset in webkit [227271] by Caio Lima

• 5 edits
  6 adds in trunk

[JSC] NumberPrototype::extractRadixFromArgs incorrectly cast double to int32_t
​https://bugs.webkit.org/show_bug.cgi?id=181182

Reviewed by Darin Adler.

JSTests:

• stress/big-int-prototype-to-string-cast-overflow.js: Added.
• stress/big-int-prototype-to-string-exception.js: Added.
• stress/big-int-prototype-to-string-wrong-values.js: Added.
• stress/number-prototype-to-string-cast-overflow.js: Added.
• stress/number-prototype-to-string-exception.js: Added.
• stress/number-prototype-to-string-wrong-values.js: Added.

Source/JavaScriptCore:

Casting double to integer is undefined behavior when the truncation
results into a value that doesn't fit into integer size,
according C++ spec[1]. Thus, we are changing bigIntProtoFuncToString and
numberProtoFuncToString to remove these source of undefined
behavior.

[1] - ​http://en.cppreference.com/w/cpp/language/implicit_conversion

• runtime/BigIntPrototype.cpp:

(JSC::bigIntProtoFuncToString):

• runtime/NumberPrototype.cpp:

(JSC::numberProtoFuncToString):
(JSC::extractToStringRadixArgument):
(JSC::extractRadixFromArgs): Deleted.

• runtime/NumberPrototype.h:

2:45 AM Changeset in webkit [227270] by commit-queue@webkit.org

• 14 edits in trunk

fetch redirect is incompatible with "no-cors" mode
​https://bugs.webkit.org/show_bug.cgi?id=181866
<rdar://problem/35827140>

Patch by Youenn Fablet <​youenn@apple.com> on 2018-01-20
Reviewed by Chris Dumez.

LayoutTests/imported/w3c:

• web-platform-tests/fetch/api/redirect/redirect-mode-expected.txt:
• web-platform-tests/fetch/api/redirect/redirect-mode-worker-expected.txt:
• web-platform-tests/fetch/api/redirect/redirect-mode.js:

(redirectMode):

• web-platform-tests/service-workers/service-worker/fetch-event-redirect.https-expected.txt:
• web-platform-tests/service-workers/service-worker/fetch-event-redirect.https.html:
• web-platform-tests/service-workers/service-worker/fetch-request-redirect.https-expected.txt:

Source/WebCore:

Covered by updated tests.

Return a network error when no-cors mode and redirect mode is manual or error.
Update preflight implementation to no longer use manual redirect mode to simulate ​https://fetch.spec.whatwg.org/#http-network-or-cache-fetch.
Instead implement redirectReceived callback to treat any redirect response as the preflight response.

• loader/cache/CachedResourceLoader.cpp:

(WebCore::CachedResourceLoader::canRequest):

• loader/CrossOriginPreflightChecker.cpp:

(WebCore::CrossOriginPreflightChecker::redirectReceived):
(WebCore::CrossOriginPreflightChecker::startPreflight):

• loader/CrossOriginPreflightChecker.h:

LayoutTests:

• http/tests/fetch/redirectmode-and-preload-expected.txt:
• http/tests/fetch/redirectmode-and-preload.html:

2:43 AM Changeset in webkit [227269] by Chris Dumez

• 2 edits in trunk/Source/WebKit

DOMCache data sometimes not properly removed when clearing data for a given origin
​https://bugs.webkit.org/show_bug.cgi?id=181887
<rdar://problem/36671239>

Reviewed by Youenn Fablet.

• NetworkProcess/cache/CacheStorageEngine.cpp:

(WebKit::CacheStorage::Engine::clearCachesForOrigin):
This code was iterating through folders on disk, then reading the folder's origin
from the origin file on disk. Then, if the origin would match the one we want to
delete, it would regenerate the folder path using cachesRootPath(*folderOrigin).
I don't know how but on my machine, I was ended up in a state where the path
generated by cachesRootPath(*folderOrigin) differed from the actual folder path
we read the origin from (Likely a different salt?). To make the code more robust,
I updated the code to delete "folderPath", which is the path we read the origin
from.

12:42 AM Changeset in webkit [227268] by BJ Burg

• 2 edits in trunk/Tools

WebDriver: fix some nits that prevent running W3C tests on Mac
​https://bugs.webkit.org/show_bug.cgi?id=181864

Reviewed by Carlos Garcia Campos.

• Scripts/webkitpy/webdriver_tests/webdriver_w3c_web_server.py:

(WebDriverW3CWebServer.init): _wsout needs to always be defined,
as we assume that the property exists later.

(WebDriverW3CWebServer.stop): If the temporary file doesn't
exist for some reason, the remove call will raise and exception.
Gracefully handle the case where the file isn't created due to
a problem/exception that happened elsewhere.