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

Timeline



Apr 14, 2019:

11:25 PM Changeset in webkit [244252] by bshafiei@apple.com
  • 7 edits in branches/safari-607-branch/Source

Versioning.

9:47 PM Changeset in webkit [244251] by Wenson Hsieh
  • 2 edits in trunk/Tools

API test WKAttachmentTests.AddAttachmentToConnectedImageElement is a flaky failure on Mac Release builds
​https://bugs.webkit.org/show_bug.cgi?id=196905
<rdar://problem/49886096>

Reviewed by Tim Horton.

This flaky test exercises a race condition between when attachment insertion updates are dispatched from the web
process to the UI process, and when script is executed via -[WKWebView evaluateJavaScript:completionHandler:].
Since attachment insertion and removal updates from the web process to the UI process are scheduled on a zero-
delay timer, we end up with this sequence of events in the problematic (failure) case:

(a) [UI] Run script #1 (which calls HTMLAttachmentElement.getAttachmentIdentifier)

...IPC from UI to web process...

(b) [Web] Evaluate script #1 in the web process, which schedules attachment updates on a zero-delay timer

...IPC from web to UI process...

(c) [UI] Invoke completion handler for script #1
(d) [UI] Run script #2 (which calls document.querySelector('img').attachmentIdentifier)

...IPC from UI to web process...

(e) [Web] Evaluate script #2 in the web process
(f) [Web] Zero-delay timer fires and dispatches attachment updates to the UI process

...which means that script #2 will complete before the UI process has received the attachment updates sent in
step (f). However, in the case where the flaky test succeeds, the zero-delay timer in (f) fires *before* script
#2 is run in step (e).

This patch fixes the flaky test by waiting until attachment insertion updates are guaranteed to be received in
the UI process by waiting on a script message posted by the web process, after attachment updates are
dispatched.

  • TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:

(TestWebKitAPI::TEST):

8:47 PM Changeset in webkit [244250] by Fujii Hironori
  • 2 edits in trunk/LayoutTests

[WinCairo][WKL] Unreviewed test gardening.

  • platform/wincairo-wk1/TestExpectations: Skip animation tests.
5:02 PM Changeset in webkit [244249] by aakash_jain@apple.com
  • 2 edits in trunk/Tools

Disable Flaky API Test WKAttachmentTests.AddAttachmentToConnectedImageElement
​https://bugs.webkit.org/show_bug.cgi?id=196909

Reviewed by Wenson Hsieh.

  • TestWebKitAPI/Tests/WebKitCocoa/WKAttachmentTests.mm:

(TestWebKitAPI::TEST):

1:52 PM Changeset in webkit [244248] by commit-queue@webkit.org
  • 17 edits
    8 adds in trunk

Link prefetch not useful for top-level navigation
​https://bugs.webkit.org/show_bug.cgi?id=195623

Patch by Rob Buis <​rbuis@igalia.com> on 2019-04-14
Reviewed by Youenn Fablet.

Source/WebCore:

Cache cross-domain top-level prefetches in a dedicated cache and not in the
memory cache. Ignore prefetches for content extension checks.

Tests: http/tests/cache/link-prefetch-main-resource-iframe.html

http/tests/cache/link-prefetch-main-resource.html

  • loader/LinkLoader.cpp:

(WebCore::LinkLoader::prefetchIfNeeded):

  • loader/ResourceLoadInfo.cpp:

(WebCore::toResourceType):

  • loader/ResourceLoadInfo.h:
  • loader/ResourceLoader.cpp:

(WebCore::ResourceLoader::willSendRequestInternal):

  • loader/cache/CachedResourceLoader.cpp:

(WebCore::CachedResourceLoader::requestResource):

Source/WebKit:

Cache cross-domain top-level prefetches in a dedicated cache. When a navigation
to the same url is done within a threshold (5 seconds), reuse the
prefetch cache entry, move it to the disk cache and navigate to
the url, meaning no extra network trip is needed. When not used within
the threshold period, the prefetch entry will be erased using a timer.

  • NetworkProcess/NetworkProcess.cpp:

(WebKit::NetworkProcess::lowMemoryHandler):

  • NetworkProcess/NetworkProcess.h:

(WebKit::NetworkProcess::prefetchCache):

  • NetworkProcess/NetworkResourceLoader.cpp:

(WebKit::NetworkResourceLoader::retrieveCacheEntry):
(WebKit::NetworkResourceLoader::didReceiveResponse):
(WebKit::NetworkResourceLoader::didReceiveBuffer):
(WebKit::NetworkResourceLoader::tryStoreAsCacheEntry):
(WebKit::NetworkResourceLoader::isCrossOriginPrefetch const):

  • NetworkProcess/NetworkResourceLoader.h:
  • NetworkProcess/cache/PrefetchCache.cpp: Added.

(WebKit::PrefetchCache::Entry::Entry):
(WebKit::PrefetchCache::PrefetchCache):
(WebKit::PrefetchCache::~PrefetchCache):
(WebKit::PrefetchCache::clear):
(WebKit::PrefetchCache::take):
(WebKit::PrefetchCache::store):
(WebKit::PrefetchCache::sessionPrefetchMap const):
(WebKit::PrefetchCache::clearExpiredEntries):

  • NetworkProcess/cache/PrefetchCache.h: Added.

(WebKit::PrefetchCache::Entry::response const):
(WebKit::PrefetchCache::Entry::releaseBuffer):

  • Shared/WebPreferences.yaml:
  • Sources.txt:
  • WebKit.xcodeproj/project.pbxproj:

LayoutTests:

Verify that prefetching a cross-domain top-level main resource
is cached in the prefetch cache and only loaded once, and that non
top-level prefetches keep the old behavior.

  • http/tests/cache/link-prefetch-main-resource-expected.txt: Added.
  • http/tests/cache/link-prefetch-main-resource-iframe-expected.txt: Added.
  • http/tests/cache/link-prefetch-main-resource-iframe.html: Added.
  • http/tests/cache/link-prefetch-main-resource.html: Added.
  • http/tests/cache/resources/prefetched-main-resource-iframe.php: Added.
  • http/tests/cache/resources/prefetched-main-resource.php: Added.
  • platform/mac-wk1/TestExpectations:
  • platform/win/TestExpectations:
1:14 PM Changeset in webkit [244247] by dino@apple.com
  • 2 edits in trunk/Source/WebCore

Extract UTI mapping and allow for additions
​https://bugs.webkit.org/show_bug.cgi?id=196822
<rdar://problem/49822339>

Reviewed by Darin Adler

Post landing feedback on minimizing String constructors.

  • platform/network/mac/UTIUtilities.mm:

(WebCore::MIMETypeFromUTITree):
(WebCore::UTIFromMIMETypeCachePolicy::createValueForKey):

9:08 AM Changeset in webkit [244246] by aestes@apple.com
  • 3 edits in trunk/Source/WebKit

[Cocoa] WKCustomProtocolLoader should store a WeakPtr to its LegacyCustomProtocolManagerProxy
​https://bugs.webkit.org/show_bug.cgi?id=196893
<rdar://problem/48318983>

Reviewed by Anders Carlsson.

In addition to manually invalidating each WKCustomProtocolLoader's _customProtocolManagerProxy
pointer when the LegacyCustomProtocolManagerClient is invalidated, use a WeakPtr in case the
LegacyCustomProtocolManagerProxy is ever destroyed without first invalidating the client.
Also add null pointer checks to NSURLConnectionDelegate methods, which might be called after
the LegacyCustomProtocolManagerProxy has been destroyed.

  • UIProcess/Cocoa/LegacyCustomProtocolManagerClient.mm:

(-[WKCustomProtocolLoader initWithLegacyCustomProtocolManagerProxy:customProtocolID:request:]):
(-[WKCustomProtocolLoader cancel]):
(-[WKCustomProtocolLoader connection:didFailWithError:]):
(-[WKCustomProtocolLoader connection:didReceiveResponse:]):
(-[WKCustomProtocolLoader connection:didReceiveData:]):
(-[WKCustomProtocolLoader connection:willSendRequest:redirectResponse:]):
(-[WKCustomProtocolLoader connectionDidFinishLoading:]):
(WebKit::LegacyCustomProtocolManagerClient::startLoading):
(WebKit::LegacyCustomProtocolManagerClient::invalidate):
(-[WKCustomProtocolLoader customProtocolManagerProxyDestroyed]): Deleted.

  • UIProcess/Network/CustomProtocols/LegacyCustomProtocolManagerProxy.h:
6:50 AM Changeset in webkit [244245] by don.olmstead@sony.com
  • 14 edits in trunk

[CMake] JavaScriptCore derived sources should only be referenced inside JavaScriptCore
​https://bugs.webkit.org/show_bug.cgi?id=196742

Reviewed by Konstantin Tokarev.

.:

Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
to support moving the JavaScriptCore derived sources outside of a shared directory.
This is in support of the target oriented design refactoring.

WinCairo is explicitly overriding the value as a canary for this setup.

Also move JavaScriptCore_SCRIPTS_DIR to WebKitFS to remove logic setting it in other projects.

  • Source/PlatformWin.cmake:
  • Source/cmake/OptionsAppleWin.cmake:
  • Source/cmake/OptionsWinCairo.cmake:
  • Source/cmake/WebKitFS.cmake:

Source/JavaScriptCore:

Migrate to using JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOURCES_JAVASCRIPTCORE_DIR
to support moving the JavaScriptCore derived sources outside of a shared directory.

Also use JavaScriptCore_DERIVED_SOURCES_DIR instead of DERIVED_SOUCES_DIR.

  • CMakeLists.txt:

Source/WebCore:

Don't set JavaScriptCore_SCRIPTS_DIR now that it is set within WebKitFS.

  • CMakeLists.txt:

Source/WebDriver:

Don't set JavaScriptCore_SCRIPTS_DIR now that it is set within WebKitFS.

  • CMakeLists.txt:

Source/WebKit:

Don't set JavaScriptCore_SCRIPTS_DIR now that it is set within WebKitFS.

  • CMakeLists.txt:
  • PlatformWin.cmake:

Remove use of DERIVED_SOURCES_JAVASCRIPTCORE_DIR.

Apr 13, 2019:

11:46 PM Changeset in webkit [244244] by zandobersek@gmail.com
  • 4 edits in trunk/Source/bmalloc

[bmalloc][Linux] Add support for memory status calculation
​https://bugs.webkit.org/show_bug.cgi?id=195938

Reviewed by Carlos Garcia Campos.

Memory status and under-memory-pressure capabilities in bmalloc can be
implemented on Linux by reading and parsing the statm file under the
proc filesystem.

We retrieve the resident set size from the statm file and multiply it
with the page size. This gives an upper-bound estimate of the memory
that's being consumed by the process.

The statm-based estimate seems preferable to other alternatives. One
such alternative would be reading and parsing more-detailed smaps file,
also exposed under the proc filesystem. This is at the moment being done
in WTF's MemoryFootprint implementation for Linux systems, but on Linux
ports this operation is being throttled to only execute once per second
because of the big computing expense required to read and parse out the
data. A future MemoryFootprint implementation could simply retrieve the
memory footprint value from bmalloc.

Another alternative is the Linux taskstats interface. This one would
require utilizing a netlink socket to retrieve the necessary statistics,
but it requires the process to have elevated privileges, which is a
blocker.

  • bmalloc/AvailableMemory.cpp:

(bmalloc::LinuxMemory::singleton):
(bmalloc::LinuxMemory::footprint const):
(bmalloc::computeAvailableMemory):
(bmalloc::memoryStatus):

  • bmalloc/AvailableMemory.h:

(bmalloc::isUnderMemoryPressure):

  • bmalloc/bmalloc.h:
9:22 PM Changeset in webkit [244243] by Chris Dumez
  • 3 edits in trunk/Source/WebKit

[ Mac Debug ] TestWebKitAPI.ProcessSwap.ReuseSuspendedProcessForRegularNavigationRetainBundlePage is a flaky crash
​https://bugs.webkit.org/show_bug.cgi?id=196548
<rdar://problem/49567254>

Reviewed by Darin Adler.

Update ProvisionalPageProxy methods to more consistently ignore unexpected IPC from the process. Previously,
some of the methods were doing this, but some other like didFailProvisionalLoadForFrame() weren't and this
was leading to this flaky crash. The issue is that if we do the load in an existing process that was recently
doing, there may be leftover IPC for the same pageID and this IPC gets received by the ProvisionalPageProxy
even though it is from a previous navigation. For this reason, the ProvisionalPageProxy should ignore all
incoming IPC that is not for its associated navigation.

  • UIProcess/ProvisionalPageProxy.cpp:

(WebKit::ProvisionalPageProxy::didPerformClientRedirect):
(WebKit::ProvisionalPageProxy::didStartProvisionalLoadForFrame):
(WebKit::ProvisionalPageProxy::didFailProvisionalLoadForFrame):
(WebKit::ProvisionalPageProxy::didCommitLoadForFrame):
(WebKit::ProvisionalPageProxy::didNavigateWithNavigationData):
(WebKit::ProvisionalPageProxy::didChangeProvisionalURLForFrame):
(WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionAsync):
(WebKit::ProvisionalPageProxy::decidePolicyForResponse):
(WebKit::ProvisionalPageProxy::didPerformServerRedirect):
(WebKit::ProvisionalPageProxy::didReceiveServerRedirectForProvisionalLoadForFrame):
(WebKit::ProvisionalPageProxy::decidePolicyForNavigationActionSync):

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

Unreviewed, try to fix the internal build after r244239

Force the bots to regenerate WKWebpagePreferences.h by touching the file. Adds a Foundation/Foundation.h
import that was missing anyways.

  • UIProcess/API/Cocoa/WKWebpagePreferences.h:
1:54 AM Changeset in webkit [244241] by Tadeu Zagallo
  • 6 edits
    1 add in trunk

CodeCache should check that the UnlinkedCodeBlock was successfully created before caching it
​https://bugs.webkit.org/show_bug.cgi?id=196880

Reviewed by Yusuke Suzuki.

JSTests:

  • stress/bytecode-cache-syntax-error.js: Added.

(catch):

Source/JavaScriptCore:

CodeCache should not tell the SourceProvider to cache the bytecode if it failed
to create the UnlinkedCodeBlock.

  • runtime/CodeCache.cpp:

(JSC::CodeCache::getUnlinkedGlobalCodeBlock):

Tools:

Add a new function for bytecode cache tests that does not forceDiskCache
for the second run: runBytecodeCacheNoAssetion. This is necessary for the
test added in this patch, since the code is invalid and therefore won't be
cached. It should also be useful for tests that evaluate dynamically
generated code.

  • Scripts/jsc-stress-test-helpers/bytecode-cache-test-helper.sh:
  • Scripts/run-jsc-stress-tests:
1:00 AM Changeset in webkit [244240] by graouts@webkit.org
  • 6 edits in trunk/Source/WebCore

Provide a quirk to disable Pointer Events
​https://bugs.webkit.org/show_bug.cgi?id=196877
<rdar://problem/49863470>

Reviewed by Dean Jackson.

Add a quirk to disable Pointer Events. We also opt a website that has compatibility issues with Pointer Events into this new quirk.

  • dom/PointerEvent.idl:
  • page/Quirks.cpp:

(WebCore::Quirks::shouldDisablePointerEventsQuirk const):

  • page/Quirks.h:
  • page/scrolling/ScrollingCoordinator.cpp:

(WebCore::ScrollingCoordinator::absoluteEventTrackingRegionsForFrame const):

  • style/StyleTreeResolver.cpp:

(WebCore::Style::TreeResolver::resolveElement):

Note: See TracTimeline for information about the timeline view.