Timeline

Jul 7, 2018:

3:29 PM Changeset in webkit [233624] by youenn@apple.com

• 2 edits in trunk/Tools

WPT importer should create dummy HTML files for *.window.js script files
​https://bugs.webkit.org/show_bug.cgi?id=187426

Reviewed by Ryosuke Niwa.

Some WPT tests use *.window.js tests, which should be accessed as *.window.html.
Do the same strategy as done for worker.js/any.js files.

• Scripts/webkitpy/w3c/test_importer.py:

(TestImporter.write_html_files_for_templated_js_tests):

2:05 PM Changeset in webkit [233623] by Wenson Hsieh

• 13 edits
  1 add in trunk

Introduce a layout milestone to track when the document contains a large number of rendered characters
​https://bugs.webkit.org/show_bug.cgi?id=187412
<rdar://problem/41744338>

Reviewed by Ryosuke Niwa.

Source/WebCore:

Implements a new layout milestone: DidRenderSignificantAmountOfText. This is similar to the existing
DidFirstVisuallyNonEmptyLayout milestone, but with a few important additional constraints:

• The minimum threshold of rendered characters is much larger (3000 instead of 200).
• The mean length of a text node must be large (at least 50).

This is a (computationally) lightweight heuristic intended to estimate the likelihood that a page is capable of
being presented in Reader mode. In many article-like pages, the average length of a text node is significantly
longer than other types of pages; thus, on pages where the average length of a text node is very large *and*
there is a large quantity of text, we can use this as a cue to opportunistically detect and enter Safari reader
mode on watchOS.

Test: RenderingProgressTests.DidRenderSignificantAmountOfText

• page/FrameView.cpp:

(WebCore::FrameView::reset):

Clear out new state members that keep track of whether the significant rendered text milestone has been met.

(WebCore::elementOverflowRectIsLargerThanThreshold):

Factor out logic to grab the overflow height of an element into a separate helper function.

(WebCore::FrameView::qualifiesAsVisuallyNonEmpty const):
(WebCore::FrameView::updateSignificantRenderedTextMilestoneIfNeeded):

Determines whether to fire this new milestone after the next layout pass is finished. The logic here is similar
to the logic in qualifiesAsVisuallyNonEmpty, requiring that there are not still pending stylesheets in the head
and that the document height is at least a minimum threshold. However, unlike the first visually non-empty
layout, this milestone is never guaranteed to fire.

(WebCore::FrameView::fireLayoutRelatedMilestonesIfNeeded):

• page/FrameView.h:

(WebCore::FrameView::incrementVisuallyNonEmptyCharacterCount):

• page/LayoutMilestones.h:

Source/WebKit:

Add plumbing for the new significant rendered text layout milestone in the modern WebKit client layer. See
WebCore/ChangeLog for more details.

• Shared/API/Cocoa/_WKRenderingProgressEvents.h:
• Shared/API/Cocoa/_WKRenderingProgressEventsInternal.h:

(renderingProgressEvents):

• Shared/API/c/WKPageLoadTypes.h:
• Shared/API/c/WKSharedAPICast.h:

(WebKit::toWKLayoutMilestones):
(WebKit::toLayoutMilestones):

• UIProcess/API/Cocoa/WKWebView.mm:

(layoutMilestones):

Tools:

Add a new API test to check that we observe the new rendering milestone in an article-like document.

• TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
• TestWebKitAPI/Tests/WebKitCocoa/significant-text-milestone.html: Added.
• TestWebKitAPI/Tests/ios/RenderingProgressTests.mm:

(TEST):

1:46 PM Changeset in webkit [233622] by Yusuke Suzuki

• 2 edits in trunk/Source/JavaScriptCore

[JSC] Optimize layout of SymbolTable to reduce padding
​https://bugs.webkit.org/show_bug.cgi?id=187437

Reviewed by Mark Lam.

Arrange the layout of SymbolTable to reduce the size from 88 to 72.

• runtime/SymbolTable.h:

1:29 PM Changeset in webkit [233621] by Yusuke Suzuki

• 5 edits in trunk/Source/JavaScriptCore

[JSC] Optimize layout of RegExp to reduce padding
​https://bugs.webkit.org/show_bug.cgi?id=187438

Reviewed by Mark Lam.

Reduce the size of RegExp from 168 to 144.

• runtime/RegExp.cpp:

(JSC::RegExp::RegExp):

• runtime/RegExp.h:
• runtime/RegExpKey.h:
• yarr/YarrErrorCode.h:

1:29 PM Changeset in webkit [233620] by Yusuke Suzuki

• 2 edits in trunk/Source/JavaScriptCore

[JSC] Optimize layout of ValueProfile to reduce padding
​https://bugs.webkit.org/show_bug.cgi?id=187439

Reviewed by Mark Lam.

Reduce the size of ValueProfile from 40 to 32 by reordering members.

• bytecode/ValueProfile.h:

(JSC::ValueProfileBase::ValueProfileBase):

11:40 AM Changeset in webkit [233619] by bshafiei@apple.com

• 7 edits in branches/safari-606.1.24-branch/Source

Versioning.

11:39 AM Changeset in webkit [233618] by bshafiei@apple.com

• 1 copy in tags/Safari-606.1.24.4

Tag Safari-606.1.24.4.

11:38 AM Changeset in webkit [233617] by bshafiei@apple.com

• 2 edits in branches/safari-606.1.24-branch/Source/WebKit

Cherry-pick r233616. rdar://problem/41931915

REGRESSION (r233561): MobileMail crashes when replying to an email
​https://bugs.webkit.org/show_bug.cgi?id=187436
rdar://problem/41931915

Reviewed by Alan Bujtas.

r233561 added a RELEASE_ASSERT(isMainThread()) in this function. This is fine most of the time,
until Mail spawns a WebThread for mail compose, at which point the meaning of isMainThread changes
and the RELEASE_ASSERT fires.

For now, just remove the RELEASE_ASSERT.

• UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _scheduleVisibleContentRectUpdateAfterScrollInView:]):

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

10:50 AM Changeset in webkit [233616] by Simon Fraser

• 2 edits in trunk/Source/WebKit

REGRESSION (r233561): MobileMail crashes when replying to an email
​https://bugs.webkit.org/show_bug.cgi?id=187436
rdar://problem/41931915

Reviewed by Alan Bujtas.

r233561 added a RELEASE_ASSERT(isMainThread()) in this function. This is fine most of the time,
until Mail spawns a WebThread for mail compose, at which point the meaning of isMainThread changes
and the RELEASE_ASSERT fires.

For now, just remove the RELEASE_ASSERT.

• UIProcess/API/Cocoa/WKWebView.mm:

(-[WKWebView _scheduleVisibleContentRectUpdateAfterScrollInView:]):

9:20 AM Changeset in webkit [233615] by ddkilzer@apple.com

• 2 edits in trunk/Source/WTF

iOS port should define HAVE_RUNLOOP_TIMER
<​https://webkit.org/b/187370>

Reviewed by Simon Fraser.

• wtf/Platform.h:

(HAVE_DTRACE): Remove unused macro since r200568.
(HAVE_RUNLOOP_TIMER): Define for PLATFORM(COCOA), not just
PLATFORM(MAC). Alphabetize macros.

8:52 AM Changeset in webkit [233614] by Simon Fraser

• 5 edits
  1 copy
  3 adds in trunk/Tools

dump-class-layout reports wrong padding in many cases
​https://bugs.webkit.org/show_bug.cgi?id=185801

Reviewed by Dan Bates.

Enhance dump-class-layout, fixing bugs and adding unit tests. This also includes
the patch from bug 187141.

Move the code that uses lldb to fetch the class layout to its own module,
lldb_dump_class_layout.py, so it can be unit tested. Change this code
to build up a data structure for the class. This is necessary since correct
padding computation is easier with second traversal over the data structure.

Try to deal with the empty base class optimization, which is necessary to report
correct padding in classes using std::unique_ptr, and correctly handle virtual base classes.

The ClassLayoutBase class knows how to test for equality and generate a string
or string list representation of itself. The derived ClassLayout class knows
how to build up the class layout using the lldb Python bindings.

Finally we wrap the lldb debugger instance in LLDBDebuggerInstance so that we don't
have to make a new one for each unit test. The tests have to run serially.

Add to lldbWebKitTester a .cpp file that contains a set of C++ classes to unit-test
dump-class-layout.

• Scripts/dump-class-layout:

(main):

• lldb/dump_class_layout_unittest.py:

(destroy_cached_debug_session):
(TestDumpClassLayout):
(TestDumpClassLayout.setUpClass):
(TestDumpClassLayout.setUp):
(TestDumpClassLayout.serial_test_BasicClassLayout):
(serial_test_PaddingBetweenClassMembers):
(serial_test_BoolPaddingClass):
(serial_test_ClassWithEmptyClassMembers):
(serial_test_SimpleVirtualClass):
(serial_test_SimpleVirtualClassWithNonVirtualBase):
(serial_test_InterleavedVirtualNonVirtual):
(serial_test_ClassWithTwoVirtualBaseClasses):
(serial_test_ClassWithClassMembers):
(serial_test_ClassWithBitfields):
(serial_test_ClassWithUniquePtrs):
(serial_test_ClassWithOptionals):
(TestDumpClassLayout.test_BasicClassLayout): Deleted.

• lldb/lldbWebKitTester/DumpClassLayoutTesting.cpp:

(EmptyClass::doStuff):
(VirtualBaseClass::~VirtualBaseClass):
(VirtualBaseClass2::~VirtualBaseClass2):
(SimpleVirtualClass::~SimpleVirtualClass):
(SimpleVirtualClass::doStuff):
(SimpleVirtualClassWithNonVirtualBase::~SimpleVirtualClassWithNonVirtualBase):
(SimpleVirtualClassWithNonVirtualBase::doStuff):
(avoidClassDeadStripping):

• lldb/lldb_dump_class_layout.py:

(ansi_colors):
(ClassLayoutBase):
(ClassLayoutBase.init):
(ClassLayoutBase.ne):
(ClassLayoutBase.eq):
(ClassLayoutBase._to_string_recursive):
(ClassLayoutBase.as_string_list):
(ClassLayoutBase.as_string):
(ClassLayoutBase.dump):
(ClassLayoutExpected):
(ClassLayoutExpected.init):
(ClassLayout):
(ClassLayout.init):
(ClassLayout._has_polymorphic_base_class):
(ClassLayout._parse):
(ClassLayout._probably_has_empty_base_class_optimization):
(ClassLayout._compute_padding_recursive):
(ClassLayout._compute_padding):
(LLDBDebuggerInstance):
(LLDBDebuggerInstance.init):
(LLDBDebuggerInstance.del):
(LLDBDebuggerInstance._get_first_file_architecture):
(LLDBDebuggerInstance.layout_for_classname):
(ClassLayoutDumper): Deleted.
(ClassLayoutDumper.init): Deleted.
(ClassLayoutDumper._get_first_file_architecture): Deleted.
(ClassLayoutDumper.verify_type): Deleted.
(ClassLayoutDumper.verify_type_recursive): Deleted.
(ClassLayoutDumper._class_layout_as_string): Deleted.
(ClassLayoutDumper.dump_to_string): Deleted.
(ClassLayoutDumper.dump): Deleted.

12:10 AM Changeset in webkit [233613] by Yusuke Suzuki

• 2 edits in trunk/Source/WTF

[linux] ASSERT: Using an alternative signal stack is not supported. Consider disabling the concurrent GC.
​https://bugs.webkit.org/show_bug.cgi?id=187297

Reviewed by Mark Lam.

This patch relaxes the JSC's limitation: accepting an alternative signal stack mechanism.

• wtf/ThreadingPthreads.cpp:

(WTF::getApproximateStackPointer):
Fix approximate stack pointer function to make it valid.

(WTF::Thread::signalHandlerSuspendResume):
Use StackBounds::contains to check whether the given stack pointer is in range of StackBounds.
If it is out of range, it seems that this stack pointer is pointing an alternative signal stack.

(WTF::Thread::suspend):
Repeatedly retry suspension by using Thread::yield().

(WTF::isOnAlternativeSignalStack): Deleted.

Jul 6, 2018:

8:43 PM Changeset in webkit [233612] by timothy@apple.com

• 13 edits in trunk/Source

Semantic colors don't update when accessibility Increase Contrast mode is enabled.
​https://bugs.webkit.org/show_bug.cgi?id=187425
rdar://problem/39948240

Reviewed by Tim Horton.

Source/WebCore:

Added a listener for the accessibility change notification to invalidate our color caches.

Removed calls to RenderTheme::singleton().platformColorsDidChange() in Page, since that
ended up calling Page::updateStyleForAllPagesAfterGlobalChangeInEnvironment multiple times.
Instead, changed the functions to use the new instance version instead.

• page/Page.cpp:

(WebCore::Page::updateStyleAfterChangeInEnvironment): Added. Gives Page a direct way to do this work
per instance instead of on all pages (since appearance can be difference per view).
(WebCore::Page::updateStyleForAllPagesAfterGlobalChangeInEnvironment): Call updateStyleAfterChangeInEnvironment.
(WebCore::Page::setUseSystemAppearance): Call updateStyleAfterChangeInEnvironment.
(WebCore::Page::setUseDarkAppearance): Added. Call updateStyleAfterChangeInEnvironment.

• page/Page.h:

(WebCore::Page::setUseDarkAppearance): Moved to the implementation file.

• platform/mac/LocalDefaultSystemAppearance.mm:

(WebCore::LocalDefaultSystemAppearance::LocalDefaultSystemAppearance): Removed recursive check since it was interfering
with the setting of m_usingDarkAppearance and causing the wrong color cache to be used.
(WebCore::LocalDefaultSystemAppearance::~LocalDefaultSystemAppearance): Ditto.

• rendering/RenderThemeMac.mm:

(-[WebCoreRenderThemeNotificationObserver init]): Listen for NSWorkspaceAccessibilityDisplayOptionsDidChangeNotification.
(-[WebCoreRenderThemeNotificationObserver systemColorsDidChange:]): Removed assert since multiple notifications are used now.

Source/WebKit:

• UIProcess/API/Cocoa/WKWebView.mm:

(-[WKWebView _initializeWithConfiguration:]): Moved call to setUseDarkAppearance to WebViewImpl.
(-[WKWebView _setUseSystemAppearance:]): No need to call setUseDarkAppearance here anymore.
(-[WKWebView viewDidChangeEffectiveAppearance]): Added. This is the proper NSView method to use.
(-[WKWebView _effectiveAppearanceIsDark]): Deleted.
(-[WKWebView effectiveAppearanceDidChange]): Deleted. This method is a deprecated name.

• UIProcess/API/mac/WKView.mm:

(-[WKView viewDidChangeEffectiveAppearance]): Added. This is the proper NSView method to use.
(-[WKView _setUseSystemAppearance:]): No need to call setUseDarkAppearance here anymore.
(-[WKView _effectiveAppearanceIsDark]): Deleted.
(-[WKView effectiveAppearanceDidChange]): Deleted. This method is a deprecated name.

• UIProcess/Cocoa/WebViewImpl.h:
• UIProcess/Cocoa/WebViewImpl.mm:

(WebKit::WebViewImpl::WebViewImpl): Call setUseDarkAppearance before page config is sent in initializeWebPage.
(WebKit::WebViewImpl::effectiveAppearanceDidChange): Added.

• WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::setUseDarkAppearance): WebCore::Page::setUseDarkAppearance now handles the style changes.
The RenderTheme color caches also don't need cleared with platformColorsDidChange(), since we cache light
and dark colors seperatly in RenderThemeMac.

Source/WebKitLegacy/mac:

• WebView/WebView.mm:

(-[WebView _commonInitializationWithFrameName:groupName:]): Removed call to
_updateDefaultAppearance, which called setUseDarkAppearance. There is already
a call in this method to setUseDarkAppearance.
(-[WebView _setUseSystemAppearance:]): Just call the page, not setUseDarkAppearance.
(-[WebView viewDidChangeEffectiveAppearance]): Added. This is the proper NSView method to use.
(-[WebView _updateDefaultAppearance]): Deleted.
(-[WebView effectiveAppearanceDidChange]): Deleted. This method is a deprecated name.

7:56 PM Changeset in webkit [233611] by rniwa@webkit.org

• 16 edits in trunk/Source/WebCore

Make ReasonForSuspension enum class
​https://bugs.webkit.org/show_bug.cgi?id=187405

Reviewed by Zalan Bujtas.

Made ReasonForSuspension an enum class instead of enum and moved out of ActiveDOMObject.

• Modules/geolocation/Geolocation.cpp:

(WebCore::Geolocation::suspend):

• Modules/websockets/WebSocket.cpp:

(WebCore::WebSocket::suspend):

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

(WebCore::Document::didBecomeCurrentDocumentInFrame):
(WebCore::Document::suspendActiveDOMObjects):
(WebCore::Document::resumeActiveDOMObjects):
(WebCore::Document::suspend):
(WebCore::Document::resume):
(WebCore::Document::suspendScheduledTasks):
(WebCore::Document::resumeScheduledTasks):

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

(WebCore::ScriptExecutionContext::suspendActiveDOMObjects):
(WebCore::ScriptExecutionContext::resumeActiveDOMObjects):

• dom/ScriptExecutionContext.h:

(WebCore::ScriptExecutionContext::reasonForSuspendingActiveDOMObjects const):

• history/CachedFrame.cpp:

(WebCore::CachedFrameBase::restore):
(WebCore::CachedFrame::CachedFrame):

• html/HTMLMediaElement.cpp:

(WebCore::HTMLMediaElement::suspend):

• html/HTMLSourceElement.cpp:

(WebCore::HTMLSourceElement::suspend):

• inspector/PageScriptDebugServer.cpp:

(WebCore::PageScriptDebugServer::setJavaScriptPaused):

• loader/FrameLoader.cpp:

(WebCore::FrameLoader::commitProvisionalLoad):

• page/Frame.cpp:

(WebCore::Frame::suspendActiveDOMObjectsAndAnimations):
(WebCore::Frame::resumeActiveDOMObjectsAndAnimations):

• page/PageGroupLoadDeferrer.cpp:

(WebCore::PageGroupLoadDeferrer::PageGroupLoadDeferrer):
(WebCore::PageGroupLoadDeferrer::~PageGroupLoadDeferrer):

• xml/XMLHttpRequest.cpp:

(WebCore::XMLHttpRequest::suspend):

7:24 PM Changeset in webkit [233610] by chris.reid@sony.com

• 2 edits in trunk/Tools

[WinCairo] WebKit MiniBrowser crashes when attempting to navigate to certain URLs
​https://bugs.webkit.org/show_bug.cgi?id=187167

Reviewed by Alex Christensen.

A null byte was written past the end of the buffer causing the crash.
Some of the heap allocated buffers were also not getting deleted.

• MiniBrowser/win/WebKitBrowserWindow.cpp:

5:48 PM Changeset in webkit [233609] by youenn@apple.com

• 3 edits in trunk/Source/ThirdParty/libwebrtc

libWebRTC GetThreadCpuTimeNanos() leaks mach_ports
​https://bugs.webkit.org/show_bug.cgi?id=187403
<rdar://problem/41741599>

Reviewed by Simon Fraser.

• Source/webrtc/rtc_base/cpu_time.cc: Call mach_port_deallocate to

to ensure mach_port is deleted.

• libwebrtc.xcodeproj/project.pbxproj: Stop compiling this file since

this is not used except by libwebrtc tests.

5:44 PM Changeset in webkit [233608] by Nikita Vasilyev

• 2 edits in trunk/Source/WebInspectorUI

Web Inspector: Dark Mode: resource search field has white text on white background
​https://bugs.webkit.org/show_bug.cgi?id=187423

Reviewed by Timothy Hatcher.

Match the colors of sidebar filter fields.

• UserInterface/Views/DarkMode.css:

(@media (prefers-dark-interface)):
(.find-banner > input[type="search"]):

5:34 PM Changeset in webkit [233607] by n_wang@apple.com

• 4 edits
  2 adds in trunk

AX: add a subrole for meter elements on macOS
​https://bugs.webkit.org/show_bug.cgi?id=187409
<rdar://problem/41905702>

Reviewed by Chris Fleizach.

Source/WebCore:

Test: accessibility/mac/meter-subrole.html

• accessibility/mac/WebAccessibilityObjectWrapperMac.mm:

(-[WebAccessibilityObjectWrapper subrole]):

LayoutTests:

• accessibility/mac/meter-subrole-expected.txt: Added.
• accessibility/mac/meter-subrole.html: Added.
• platform/mac/accessibility/roles-exposed-expected.txt:

5:32 PM Changeset in webkit [233606] by bshafiei@apple.com

• 7 edits in branches/safari-606.1.24-branch/Source

Versioning.

5:15 PM Changeset in webkit [233605] by commit-queue@webkit.org

• 4 edits in trunk/Source/WebCore

For <video> element, use video fullscreen instead of element fullscreen.
​https://bugs.webkit.org/show_bug.cgi?id=186093
rdar://problem/40144751

Patch by Jeremy Jones <​jeremyj@apple.com> on 2018-07-06
Reviewed by Jer Noble.

Some pages use webkitRequestFullscreen directly on the video element, without any custom controls.
This will prevent native fullscreeen presentation mode conrols from being used.

This change makes webkitRequestFullscreen on a video element call webKitSetPresentationMode.

• dom/Element.h:
• html/HTMLVideoElement.cpp:

(WebCore::HTMLVideoElement::webkitRequestFullscreen):

• html/HTMLVideoElement.h:

4:47 PM Changeset in webkit [233604] by youenn@apple.com

• 10 edits
  2 deletes in trunk

WebRTC MediaStreamTrack Enable / Disable causes video delay / lag
​https://bugs.webkit.org/show_bug.cgi?id=186889
<rdar://problem/41370285>

Reviewed by Eric Carlson.

Source/WebCore:

Libwebrtc expects a continuous flow of calls for audio data since the API
does not provide any possiblity to give timestamps.

We were optimizing previously when a source is muted so that we would not transmit audio data.
This breaks synchronization between audio and video frames (which are timestamped).

This patch reverts the optimization and instead makes sure to send zeros for silenced audio tracks.

This requires MediaStreamTrackPrivate to send audio data even if disabled,
so that RealtimeOutgoingAudioSource will continue sending zeros at the correct pace.
This also requires WebAudioSourceProviderAVFObjC to exit early if its track is disabled.

Covered by existing tests.
Manual testing shows that synchronization is kept.

• platform/mediastream/MediaStreamTrackPrivate.cpp:

(WebCore::MediaStreamTrackPrivate::audioSamplesAvailable):

• platform/mediastream/RealtimeOutgoingAudioSource.cpp:

(WebCore::RealtimeOutgoingAudioSource::RealtimeOutgoingAudioSource):
(WebCore::RealtimeOutgoingAudioSource::initializeConverter):
(WebCore::RealtimeOutgoingAudioSource::stop):
(WebCore::RealtimeOutgoingAudioSource::sourceMutedChanged):
(WebCore::RealtimeOutgoingAudioSource::sourceEnabledChanged):
(WebCore::RealtimeOutgoingAudioSource::handleMutedIfNeeded): Deleted.

• platform/mediastream/RealtimeOutgoingAudioSource.h:

(WebCore::RealtimeOutgoingAudioSource::pullAudioData):
(WebCore::RealtimeOutgoingAudioSource::isSilenced const):
(WebCore::RealtimeOutgoingAudioSource::sendSilence): Deleted.

• platform/mediastream/mac/RealtimeOutgoingAudioSourceCocoa.cpp:

(WebCore::RealtimeOutgoingAudioSourceCocoa::pullAudioData):
(WebCore::RealtimeOutgoingAudioSourceCocoa::handleMutedIfNeeded): Deleted.
(WebCore::RealtimeOutgoingAudioSourceCocoa::sendSilence): Deleted.

• platform/mediastream/mac/RealtimeOutgoingAudioSourceCocoa.h:
• platform/mediastream/mac/WebAudioSourceProviderAVFObjC.mm:

(WebCore::WebAudioSourceProviderAVFObjC::audioSamplesAvailable):

LayoutTests:

Test is no longer valid since we are now sending 0 bytes for audio tracks.

• webrtc/audio-muted-stats2-expected.txt: Removed.
• webrtc/audio-muted-stats2.html: Removed.

4:40 PM Changeset in webkit [233603] by Ryan Haddad

• 2 edits in trunk/LayoutTests

Skip imported/w3c/web-platform-tests/infrastructure/assumptions/html-elements.html on debug.
​https://bugs.webkit.org/show_bug.cgi?id=187093

Unreviewed test gardening.

• TestExpectations:

4:30 PM Changeset in webkit [233602] by youenn@apple.com

• 2 edits in trunk/Source/WebCore

Make RealtimeOutgoingVideoSource use DestructionThread::Main
​https://bugs.webkit.org/show_bug.cgi?id=187402

Reviewed by Chris Dumez.

No change of behavior.

• platform/mediastream/RealtimeOutgoingVideoSource.h:

4:26 PM Changeset in webkit [233601] by Chris Dumez

• 3 edits in trunk/Source/WebKit

Add release assertions to try and catch a possible HashMap corruption in NetworkConnectionToWebProcess
​https://bugs.webkit.org/show_bug.cgi?id=187417

Reviewed by Ryosuke Niwa.

Add assertions to make sure we:

• Always use NetworkConnectionToWebProcess::m_networkResourceLoaders from the main thread
• Never use a 0 identifier as key for NetworkConnectionToWebProcess::m_networkResourceLoaders

We see crashes (rdar://problem/39265927) that only seem to make sense if this HashMap was
somehow getting corrupted. Let's try and catch the most common reasons for HashMap corruption.

• NetworkProcess/NetworkConnectionToWebProcess.cpp:

(WebKit::NetworkConnectionToWebProcess::didCleanupResourceLoader):
(WebKit::NetworkConnectionToWebProcess::didReceiveMessage):
(WebKit::NetworkConnectionToWebProcess::scheduleResourceLoad):
(WebKit::NetworkConnectionToWebProcess::performSynchronousLoad):
(WebKit::NetworkConnectionToWebProcess::removeLoadIdentifier):
(WebKit::NetworkConnectionToWebProcess::setDefersLoading):
(WebKit::NetworkConnectionToWebProcess::convertMainResourceLoadToDownload):

• WebProcess/Network/WebResourceLoader.cpp:

(WebKit::WebResourceLoader::messageSenderDestinationID):

4:11 PM Changeset in webkit [233600] by BJ Burg

• 2 edits in trunk/Source/WebKit

WebDriver: hang in Selenium test alerts_tests.py::testShouldHandleAlertOnPageBeforeUnload
​https://bugs.webkit.org/show_bug.cgi?id=187418
<rdar://problem/41909520>

Reviewed by Timothy Hatcher.

Per the W3C specification, “User prompts that are spawned from beforeunload event handlers,
are dismissed implicitly upon navigation or close window, regardless of the defined user prompt handler.”

This behavior differs from legacy Selenium behavior where (as in the test) it's expected that
a test can accept or dismiss a beforeunload alert manually.

Prior to this patch, beforeunload alerts hang because Safari uses a nested modal run loop, which does
not process incoming Automation messages, so there was no way for the test to manually dismiss
the alert.

• UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::runBeforeUnloadConfirmPanel):
Don't show beforeunload alerts for pages being controlled by automation.

3:54 PM Changeset in webkit [233599] by beidson@apple.com

• 2 edits in trunk/LayoutTests

This test is flaky. This unreviewed patch is my attempt to make it less so.

• storage/indexeddb/modern/opendatabase-after-storage-crash.html:

3:23 PM Changeset in webkit [233598] by Chris Dumez

• 2 edits in trunk/Source/WebKit

ASSERTION FAILED: contextConnection under WebCore::SWServer::terminateWorkerInternal
​https://bugs.webkit.org/show_bug.cgi?id=187348
<rdar://problem/41853270>

Reviewed by Youenn Fablet.

Make sure we mark corresponding SWServerWorkers as terminated when we terminate a
Service Worker context connection once it is no longer needed.

• StorageProcess/StorageProcess.cpp:

(WebKit::StorageProcess::swContextConnectionMayNoLongerBeNeeded):

3:22 PM Changeset in webkit [233597] by david_fenton@apple.com

• 2 edits in trunk/LayoutTests

Layout Test imported/w3c/web-platform-tests/IndexedDB/interfaces.any.worker.html is flaky.
​https://bugs.webkit.org/show_bug.cgi?id=187372

Unreviewed test gardening.

Added [ Slow ] to the existing [ Pass Timeout ] expectation.

• platform/mac-wk1/TestExpectations:

3:19 PM Changeset in webkit [233596] by rniwa@webkit.org

• 3 edits in trunk/Source/WebCore

Make HTMLMediaElement::remove*Track take a Ref<>&&
​https://bugs.webkit.org/show_bug.cgi?id=187407

Reviewed by Zalan Bujtas.

Make these functions take Ref<>&& since they can delete track objects.

• html/HTMLMediaElement.cpp:

(WebCore::HTMLMediaElement::removeAudioTrack):
(WebCore::HTMLMediaElement::removeTextTrack):
(WebCore::HTMLMediaElement::removeVideoTrack):
(WebCore::HTMLMediaElement::forgetResourceSpecificTracks):

• html/HTMLMediaElement.h:

2:50 PM Changeset in webkit [233595] by Ryan Haddad

• 2 edits in trunk/LayoutTests

Rebaseline accessibility/ios-simulator/strong-password-field.html after r233578.

Unreviewed test gardening.

• accessibility/ios-simulator/strong-password-field-expected.txt:

2:28 PM Changeset in webkit [233594] by commit-queue@webkit.org

• 2 edits in trunk/Tools

[WPE][GTK] Build php zlib plugin and enable sockets in flatpak
​https://bugs.webkit.org/show_bug.cgi?id=187401

Patch by Thibault Saunier <​tsaunier@igalia.com> on 2018-07-06
Reviewed by Philippe Normand.

• flatpak/org.webkit.WebKit.yaml:

2:01 PM Changeset in webkit [233593] by bshafiei@apple.com

• 1 copy in tags/Safari-606.1.24.3

Tag Safari-606.1.24.3.

1:38 PM Changeset in webkit [233592] by bshafiei@apple.com

• 2 edits in branches/safari-606.1.24-branch/Source/WebKit

Cherry-pick r233561. rdar://problem/41878797

Address two possible causes of missing tiles in iOS Safari, and add logging to gather more data about other possible causes
​https://bugs.webkit.org/show_bug.cgi?id=187376
rdar://problem/40941118

Reviewed by Tim Horton.

We have continual reports of users experiencing missing tiles in MobileSafari, where loading a page
shows the tiles at the top, but we don't render new tiles as the user scrolls down. This is consistent
with failing to dispatch visible content rect updates via -[WKWebView _updateVisibleContentRects].

This patch addresses two possible (but unlikely) causes. First, it resets _currentlyAdjustingScrollViewInsetsForKeyboard
after a web process crash. Second, it catches exceptions thrown by [webView _updateVisibleContentRects]
and resets _hasScheduledVisibleRectUpdate.

This patch also adds release logging that fires if over 1s has elapsed between scheduling
a visible content rect update and trying to re-schedule, and logging for all reasons that
-_updateVisibleContentRects returns early.

• UIProcess/API/Cocoa/WKWebView.mm: (-[WKWebView _initializeWithConfiguration:]): (-[WKWebView _processDidExit]): (-[WKWebView _addUpdateVisibleContentRectPreCommitHandler]): (-[WKWebView _scheduleVisibleContentRectUpdateAfterScrollInView:]): (-[WKWebView _updateVisibleContentRects]):

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

1:37 PM Changeset in webkit [233591] by david_fenton@apple.com

• 2 edits in trunk/LayoutTests

Layout Test imported/w3c/web-platform-tests/WebCryptoAPI/generateKey/successes_RSA-PSS.https.any.worker.html is flaky timeout.
​https://bugs.webkit.org/show_bug.cgi?id=187408

Unreviewed test gardening.

• platform/mac/TestExpectations:

1:37 PM Changeset in webkit [233590] by bshafiei@apple.com

• 7 edits in branches/safari-606.1.24-branch/Source

Versioning.

1:13 PM Changeset in webkit [233589] by aestes@apple.com

• 2 edits in trunk/Source/WebKit

[iOS] WKPDFView should show the Data Detectors sheet when long-pressing a URL that Data Detectors can handle
​https://bugs.webkit.org/show_bug.cgi?id=187396
<rdar://problem/41786980>

Reviewed by Dan Bernstein.

If a URL can be presented by Data Detectors, show the Data Detectors sheet instead
of the link sheet. Also implement the optional WKActionSheetAssistantDelegate
method that asks the UI delegate for its data detection context.

• UIProcess/ios/WKPDFView.mm:

(-[WKPDFView _showActionSheetForURL:atLocation:withAnnotationRect:]):
(-[WKPDFView dataDetectionContextForActionSheetAssistant:]):

12:39 PM Changeset in webkit [233588] by graouts@webkit.org

• 4 edits in trunk

[Web Animations] Make WPT test at interfaces/KeyframeEffect/processing-a-keyframes-argument-002.html pass reliably
​https://bugs.webkit.org/show_bug.cgi?id=186502
<rdar://problem/41000229>l

Reviewed by Dean Jackson.

LayoutTests/imported/w3c:

Mark WPT progression.

• web-platform-tests/web-animations/interfaces/KeyframeEffect/processing-a-keyframes-argument-002-expected.txt:

Source/WebCore:

Ensure we only attempt to convert defined objects or we risk to throw errors in valid situations.

• animation/KeyframeEffectReadOnly.cpp:

(WebCore::processKeyframeLikeObject):

12:33 PM Changeset in webkit [233587] by Chris Dumez

• 3 edits in trunk/Source/WebKit

WebResourceLoadStatisticsStore::callHasStorageAccessForFrameHandler() should take in a CompletionHandler
​https://bugs.webkit.org/show_bug.cgi?id=187392

Reviewed by Youenn Fablet.

• UIProcess/WebResourceLoadStatisticsStore.cpp:

(WebKit::WebResourceLoadStatisticsStore::callHasStorageAccessForFrameHandler):

• UIProcess/WebResourceLoadStatisticsStore.h:

12:24 PM Changeset in webkit [233586] by aakash_jain@apple.com

• 4 edits in trunk/Tools

[ews-build] EWS should run javascriptcore tests
​https://bugs.webkit.org/show_bug.cgi?id=187365

Reviewed by David Kilzer.

• BuildSlaveSupport/ews-build/steps.py: Added step to run JavaScriptCoreTests.
• BuildSlaveSupport/ews-build/steps_unittest.py: Added unit-tests.
• BuildSlaveSupport/ews-build/factories.py:

11:43 AM Changeset in webkit [233585] by graouts@webkit.org

• 8 edits in trunk

[Web Animations] Make WPT test at interfaces/Animation/finish.html pass reliably
​https://bugs.webkit.org/show_bug.cgi?id=186496
<rdar://problem/41000179>

Reviewed by Dean Jackson.

LayoutTests/imported/w3c:

Mark a WPT progression.

• web-platform-tests/web-animations/interfaces/Animation/finish-expected.txt:

Source/WebCore:

We used to only resolve animations that had a target element, but animations need not have a target and their
current time should still advance so that their finished promise may resolve. We now maintain a list of animations
without targets and we iterate through them as well as animations with targets in DocumentTimeline::updateAnimations().

• animation/AnimationTimeline.cpp:

(WebCore::AnimationTimeline::addAnimation):
(WebCore::AnimationTimeline::removeAnimation):
(WebCore::AnimationTimeline::animationWasAddedToElement):
(WebCore::AnimationTimeline::animationWasRemovedFromElement):

• animation/AnimationTimeline.h:

(WebCore::AnimationTimeline:: const):

• animation/DocumentTimeline.cpp:

(WebCore::DocumentTimeline::updateAnimations):

• animation/WebAnimation.cpp:

(WebCore::WebAnimation::resolve):

• animation/WebAnimation.h:

11:37 AM Changeset in webkit [233584] by graouts@webkit.org

• 6 edits in trunk

[Web Animations] Make WPT test at interfaces/Animation/finished.html pass reliably
​https://bugs.webkit.org/show_bug.cgi?id=186497
<rdar://problem/41000193>

Reviewed by Dean Jackson.

LayoutTests/imported/w3c:

Mark WPT progression.

• web-platform-tests/web-animations/interfaces/Animation/finished-expected.txt:

Source/WebCore:

We need to ensure the finished state is updated as a result of any timing property changing.

• animation/AnimationEffectReadOnly.cpp:

(WebCore::AnimationEffectReadOnly::timingDidChange):

• animation/WebAnimation.cpp:

(WebCore::WebAnimation::effectTimingPropertiesDidChange):

• animation/WebAnimation.h:

11:31 AM Changeset in webkit [233583] by graouts@webkit.org

• 9 edits
  4 adds in trunk

[Web Animations] Using a Web Animation leaks the Document
​https://bugs.webkit.org/show_bug.cgi?id=187088
<rdar://problem/41392046>

Reviewed by Darin Adler.

Source/WebCore:

Test: webanimations/leak-document-with-web-animation.html

We need to ensure that any remaining animation is cleared when the DocumentTimeline is detached from its Document.
We rename WebAnimation::prepareAnimationForRemoval() to WebAnimation::remove() since it really actively disassociates
the animation from its timeline.

An earlier version of this patch (r233349) was rolled out due to crashes caught in the ASan configuration. The following
changes were made to make it safe:

• We protect the DocumentAnimationScheduler instance in displayRefreshFired() against code that might run in a

requestAnimationFrame() callback that would trigger the object to be deleted.

• We protect the WebAnimation instance in remove() against setEffectInternal() or setTimelineInternal() potentially

causing the object to be deleted. Similar protections were addede to setEffect() and setTimeline().

• We changed ~DocumentTimeline() to a default implementation to ensure it calls ~DisplayRefreshMonitorClient()

to avoid callbacks after the object has been marked for deletion.

• animation/AnimationTimeline.cpp:

(WebCore::AnimationTimeline::removeAnimationsForElement): We no longer need the call to removeAnimation()
since the new WebAnimation::remove() method will also set the timeline to null which will eventually call
removeAnimation() on the disassociated timeline.

• animation/DeclarativeAnimation.cpp:

(WebCore::DeclarativeAnimation::remove):
(WebCore::DeclarativeAnimation::prepareAnimationForRemoval): Deleted.

• animation/DeclarativeAnimation.h:
• animation/DocumentAnimationScheduler.cpp:

(WebCore::DocumentAnimationScheduler::displayRefreshFired):

• animation/DocumentTimeline.cpp:

(WebCore::DocumentTimeline::detachFromDocument): Call remove() on all known animations.
(WebCore::DocumentTimeline::~DocumentTimeline): Deleted.

• animation/WebAnimation.cpp:

(WebCore::WebAnimation::remove): Set the timeline to null to fully disassociate this animation from its timeline.
(WebCore::WebAnimation::setEffect):
(WebCore::WebAnimation::setEffectInternal):
(WebCore::WebAnimation::setTimeline): Factor the internal timeline-association code out of this JS API method so
that we can call this code without any JS-facing implications.
(WebCore::WebAnimation::setTimelineInternal):
(WebCore::WebAnimation::prepareAnimationForRemoval): Deleted.

• animation/WebAnimation.h:

LayoutTests:

• webanimations/leak-document-with-web-animation-expected.txt: Added.
• webanimations/leak-document-with-web-animation.html: Added.
• webanimations/resources/web-animation-leak-iframe.html: Added.

11:25 AM Changeset in webkit [233582] by Chris Dumez

• 2 edits in trunk/Source/WebKit

[iOS] Assertion failure in WebProcessProxy::allProcesses() (isMainThread())
​https://bugs.webkit.org/show_bug.cgi?id=187394

Reviewed by Dan Bernstein.

Use RunLoop::isMain() instead of isMainThread() in the assertion to fix issues for
applications using both WebKit and WebKitLegacy.

• UIProcess/WebProcessProxy.cpp:

10:44 AM Changeset in webkit [233581] by sbarati@apple.com

• 2 edits in trunk/LayoutTests

Layout Test editing/selection/navigation-clears-editor-state.html is flaky
​https://bugs.webkit.org/show_bug.cgi?id=187389

Reviewed by Mark Lam.

• editing/selection/navigation-clears-editor-state.html:

Make the test's internal time out mechanism longer since
it's being hit on the bots.

10:29 AM Changeset in webkit [233580] by n_wang@apple.com

• 3 edits in trunk/LayoutTests

AX: setValue on text controls should send out key events
​https://bugs.webkit.org/show_bug.cgi?id=186690
<rdar://problem/41169985>

Reviewed by Chris Fleizach.

Editor's clearText function will also dispatch the InputEvent. In the test,
we need to make sure each test case finishes handling all the input events
before moving to the next test case.

• accessibility/mac/set-value-editable-dispatch-events-expected.txt:
• accessibility/mac/set-value-editable-dispatch-events.html:

10:29 AM Changeset in webkit [233579] by Ryan Haddad

• 2 edits in trunk/LayoutTests

Layout Test imported/w3c/web-platform-tests/2dcontext/imagebitmap/createImageBitmap-origin.sub.html is flaky
​https://bugs.webkit.org/show_bug.cgi?id=187393

Unreviewed test gardening.

Patch by Truitt Savell <Truitt Savell> on 2018-07-06

• TestExpectations:

9:29 AM Changeset in webkit [233578] by dbates@webkit.org

• 39 edits
  10 deletes in trunk

Remove Strong Confirmation Password button
​https://bugs.webkit.org/show_bug.cgi?id=187306
<rdar://problem/41795185>

Reviewed by Sam Weinig.

Remove support for the Strong Confirmation Password button because we never made use of it.

Source/WebCore:

• English.lproj/Localizable.strings:
• accessibility/ios/WebAccessibilityObjectWrapperIOS.mm:

(-[WebAccessibilityObjectWrapper _accessibilityIsStrongPasswordField]):

• accessibility/mac/WebAccessibilityObjectWrapperMac.mm:

(-[WebAccessibilityObjectWrapper accessibilityAttributeValue:]):

• html/HTMLInputElement.h:

(WebCore::HTMLInputElement::hasAutoFillStrongPasswordButton const):

• html/HTMLTextFormControlElement.h:
• html/TextFieldInputType.cpp:

(WebCore::autoFillButtonTypeToAccessibilityLabel):
(WebCore::autoFillButtonTypeToAutoFillButtonText):
(WebCore::autoFillButtonTypeToAutoFillButtonPseudoClassName):
(WebCore::isAutoFillButtonTypeChanged):

• platform/LocalizedStrings.cpp:

(WebCore::AXAutoFillStrongConfirmationPasswordLabel): Deleted.

• platform/LocalizedStrings.h:
• rendering/RenderTextControlSingleLine.cpp:

(WebCore::RenderTextControlSingleLine::layout):

• testing/Internals.cpp:

(WebCore::toAutoFillButtonType):
(WebCore::toInternalsAutoFillButtonType):

• testing/Internals.h:
• testing/Internals.idl:

Source/WebKit:

• WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInNodeHandle.mm:

(toAutoFillButtonType):
(toWKAutoFillButtonType):

• WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInNodeHandlePrivate.h:
• WebProcess/InjectedBundle/API/c/WKBundleNodeHandle.cpp:

(toAutoFillButtonType):
(toWKAutoFillButtonType):

• WebProcess/InjectedBundle/API/c/WKBundleNodeHandlePrivate.h:

LayoutTests:

• accessibility/ios-simulator/strong-password-field-expected.txt:
• accessibility/ios-simulator/strong-password-field.html:
• fast/forms/auto-fill-button/auto-fill-strong-password-button-when-maxlength-changes-expected.html:
• fast/forms/auto-fill-button/auto-fill-strong-password-button-when-maxlength-changes.html:
• fast/forms/auto-fill-button/auto-fill-strong-password-button-when-minlength-changes-expected.html:
• fast/forms/auto-fill-button/auto-fill-strong-password-button-when-minlength-changes.html:
• fast/forms/auto-fill-button/hide-auto-fill-strong-password-button-when-form-is-reset-expected.html:
• fast/forms/auto-fill-button/hide-auto-fill-strong-password-button-when-form-is-reset.html:
• fast/forms/auto-fill-button/hide-auto-fill-strong-password-button-when-value-changes-expected.html:
• fast/forms/auto-fill-button/hide-auto-fill-strong-password-button-when-value-changes.html:
• fast/forms/auto-fill-button/hide-strong-password-when-field-type-changes-expected.html:
• fast/forms/auto-fill-button/hide-strong-password-when-field-type-changes.html:
• fast/forms/auto-fill-button/input-autofilled-disabled-strong-password-auto-fill-button-expected.html: Removed.
• fast/forms/auto-fill-button/input-autofilled-disabled-strong-password-auto-fill-button.html: Removed.
• fast/forms/auto-fill-button/input-autofilled-readonly-strong-password-auto-fill-button-expected.html: Removed.
• fast/forms/auto-fill-button/input-autofilled-readonly-strong-password-auto-fill-button.html: Removed.
• fast/forms/auto-fill-button/input-disabled-strong-password-and-strong-confirmation-password-auto-fill-buttons-expected.html:
• fast/forms/auto-fill-button/input-disabled-strong-password-and-strong-confirmation-password-auto-fill-buttons.html:
• fast/forms/auto-fill-button/input-readonly-strong-password-and-strong-confirmation-password-auto-fill-buttons-expected.html:
• fast/forms/auto-fill-button/input-readonly-strong-password-and-strong-confirmation-password-auto-fill-buttons.html:
• fast/forms/auto-fill-button/input-strong-confirmation-password-auto-fill-button.html: Removed.
• fast/forms/auto-fill-button/last-auto-fill-button-type-expected.txt:
• fast/forms/auto-fill-button/last-auto-fill-button-type.html:
• platform/gtk/TestExpectations:
• platform/gtk/fast/forms/auto-fill-button/input-strong-confirmation-password-auto-fill-button-expected.txt: Removed.
• platform/ios/fast/forms/auto-fill-button/input-strong-confirmation-password-auto-fill-button-expected.txt: Removed.
• platform/mac/fast/forms/auto-fill-button/input-strong-confirmation-password-auto-fill-button-expected.txt: Removed.
• platform/win/TestExpectations:
• platform/win/fast/forms/auto-fill-button/input-strong-confirmation-password-auto-fill-button-expected.txt: Removed.
• platform/wincairo/fast/forms/auto-fill-button/input-strong-confirmation-password-auto-fill-button-expected.txt: Removed.

4:49 AM Changeset in webkit [233577] by fred.wang@free.fr

• 3 edits in trunk/Source/WTF

WTF's internal std::optional implementation should abort() on bad optional access
​https://bugs.webkit.org/show_bug.cgi?id=186536

Patch by Frederic Wang <​fwang@igalia.com> on 2018-07-06
Reviewed by Michael Catanzaro.

Currently, some ports built with recent compilers will cause the program to abort when one
tries to access the value of an unset std:optional (i.e. std::nullopt) as specified by C++17.
However, most ports still use WTF's internal std::optional implementation, which does not
verify illegal access. Hence it's not possible for developers working on these ports to
detect issues like bugs #186189, #186535, #186752, #186753, #187139, #187145, #187243 or
#187382.
WTF's version of std::optional was introduced in bug #164199 but it was not possible to
verify the availability of the value inside constexpr member functions because the assert
might involve asm declarations. This commit introduces a new ASSERT_UNDER_CONSTEXPR_CONTEXT
macro (a simplified version of ASSERT that can be used in constexpr context) and uses it in
WTF's implementation of std::optional.

• wtf/Assertions.h: Define ASSERT_UNDER_CONSTEXPR_CONTEXT as a version of ASSERT that can be

used in constexpr context (in particular avoids asm declarations).

• wtf/Optional.h:

(std::optional::operator ->): Add an assert to ensure the optional value is available.
(std::optional::operator *): Ditto.
(std::optional::value const): Ditto.
(std::optional::value): Ditto.
(std::optional<T::value const): Ditto.

3:51 AM Changeset in webkit [233576] by Carlos Garcia Campos

• 2 edits in trunk/Tools

[GTK][WPE] REGRESSION(r233111): Test /webkit/WebKitUserContentManager/script-message-received fails
​https://bugs.webkit.org/show_bug.cgi?id=187383

Reviewed by Žan Doberšek.

This is actually a problem in the test itself. The problem is that we run js, connect to message-received and
quite the main loop when the message is received, which happens before the run js operation has been
completed. The test finishes early and since r233111 an IPC message is still pending (I guess the run js
callback) and the web page is still protected. Just adding a run loop operation before finishing the test would
fix it. We should wait for the js run to complete, instead of the message.

• TestWebKitAPI/Tests/WebKitGLib/TestWebKitUserContentManager.cpp:

(UserScriptMessageTest::scriptMessageReceived):
(UserScriptMessageTest::waitUntilMessageReceived):
(UserScriptMessageTest::runJavaScriptFinished):
(UserScriptMessageTest::postMessageAndWaitUntilReceived):

3:38 AM Changeset in webkit [233575] by commit-queue@webkit.org

• 2 edits in trunk/Source/WebCore

[GTK][WPE] REGRESSION(r233239): proxy settings not applied after r233239
​https://bugs.webkit.org/show_bug.cgi?id=187381

Patch by Carlos Garcia Campos <​cgarcia@igalia.com> on 2018-07-06
Reviewed by Yusuke Suzuki.

This is because the static variable for proxy settings was replaced by a NeverDestroyed, but the function is not
returning a reference, but a copy. This is causing several unit tests to fail.

• platform/network/soup/SoupNetworkSession.cpp:

(WebCore::proxySettings):

3:10 AM Changeset in webkit [233574] by commit-queue@webkit.org

• 2 edits in trunk/Source/WebCore

[Crash] Illegal use of uninitialized std::optional value in WebCore::AnimationBase::updateStateMachine
​https://bugs.webkit.org/show_bug.cgi?id=187382

Patch by Frederic Wang <​fwang@igalia.com> on 2018-07-06
Reviewed by Carlos Garcia Campos.

WebCore::AnimationBase::updateStateMachine has two potential places where the use of an
uninitialized std:optional value is possible and one of them is hit when using Google drive.
Since that old animation code is going to be removed soon, we just quickly patch this issue
via value_or() so that we can restore the ASSERT added in bug 186536.

No new tests, code is going to be removed soon.

• page/animation/AnimationBase.cpp:

(WebCore::AnimationBase::updateStateMachine): Use value_or(0) to avoid potential crashes.

12:59 AM Changeset in webkit [233573] by bshafiei@apple.com

• 1 copy in tags/Safari-606.1.24.2

Tag Safari-606.1.24.2.

12:48 AM Changeset in webkit [233572] by commit-queue@webkit.org

• 4 edits in trunk/Source/WebCore

Rename HTMLTreeBuilder::didCreateCustomOrCallbackElement
​https://bugs.webkit.org/show_bug.cgi?id=187317

Patch by Frederic Wang <​fwang@igalia.com> on 2018-07-06
Reviewed by Ryosuke Niwa.

This function is called with a new custom element or the fallback HTMLUnknownElement element
so we rename it didCreateCustomOrFallbackElement.

No new tests, behavior unchanged.

• html/parser/HTMLDocumentParser.cpp:

(WebCore::HTMLDocumentParser::runScriptsForPausedTreeBuilder):

• html/parser/HTMLTreeBuilder.cpp:

(WebCore::HTMLTreeBuilder::didCreateCustomOrFallbackElement):
(WebCore::HTMLTreeBuilder::didCreateCustomOrCallbackElement): Deleted.

• html/parser/HTMLTreeBuilder.h:

12:37 AM Changeset in webkit [233571] by rniwa@webkit.org

• 5 edits in trunk/Source/WebCore

REGRESSION(r233496): macOS Sierra hits debug assertions in TrackListBase::suspend
​https://bugs.webkit.org/show_bug.cgi?id=187378
<rdar://problem/41878885>

Reviewed by Eric Carlson.

These assertions were wrong since inline debugger, alert, etc... can suspend active DOM objects without
calling canSuspendForDocumentSuspension. Fixed the bug by removing the assertion and instead suspending
and resuming the generic event queue.

• Modules/mediasource/MediaSource.cpp:

(WebCore::MediaSource::suspend):
(WebCore::MediaSource::resume):

• Modules/mediasource/SourceBuffer.cpp:

(WebCore::SourceBuffer::suspend):
(WebCore::SourceBuffer::resume):

• Modules/mediasource/SourceBufferList.cpp:

(WebCore::SourceBufferList::suspend):
(WebCore::SourceBufferList::resume):

• html/track/TrackListBase.cpp:

(WebCore::TrackListBase::suspend):
(WebCore::TrackListBase::resume):