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

Timeline



Feb 19, 2017:

10:36 PM Changeset in webkit [212625] by Chris Dumez
  • 8 edits
    6 adds in trunk

onbeforeunload event return value coercion is not per-spec
​https://bugs.webkit.org/show_bug.cgi?id=168382

Reviewed by Darin Adler.

LayoutTests/imported/w3c:

Import test coverage from web-platform-tests. We were failing half the checks
before this patch.

  • resources/resource-files.json:
  • web-platform-tests/html/browsers/browsing-the-web/unloading-documents/MANIFEST:
  • web-platform-tests/html/browsers/browsing-the-web/unloading-documents/beforeunload-canceling-1.html: Added.
  • web-platform-tests/html/browsers/browsing-the-web/unloading-documents/beforeunload-canceling-expected.txt: Added.
  • web-platform-tests/html/browsers/browsing-the-web/unloading-documents/beforeunload-canceling.html: Added.
  • web-platform-tests/html/browsers/browsing-the-web/unloading-documents/w3c-import.log:

Source/WebCore:

Update handling of value returned by onbeforeunload event listeners
to match Firefox and the specification:

Namely, the following changes were made:

  • Only set the event's returnValue attribute to the returned value if the attribute value is the empty string (so as to not override the attribute value if it has explicitly been set by JS).
  • Cancel the event when the return value is not null by calling preventDefault().

Additionally, the following changes were made:

  • Ask the user to confirm the navigation if the event was canceled, not just if the returnValue attribute was set to a non-empty string.

as per:

Tests: fast/events/before-unload-return-string-conversion.html

imported/w3c/web-platform-tests/html/browsers/browsing-the-web/unloading-documents/beforeunload-canceling.html

  • bindings/js/JSEventListener.cpp:

(WebCore::handleBeforeUnloadEventReturnValue):
(WebCore::JSEventListener::handleEvent):

  • loader/FrameLoader.cpp:

(WebCore::shouldAskForNavigationConfirmation):
(WebCore::FrameLoader::dispatchBeforeUnloadEvent):

LayoutTests:

Add test case to check that the value returned by a beforeunload event handler
is already converted to a string, even if the returnValue attribute is also
set on the BeforeUnloadEvent. The existing code did not handle this properly
and it has been fixed in this patch.

  • fast/events/before-unload-return-string-conversion-expected.txt: Added.
  • fast/events/before-unload-return-string-conversion.html: Added.
  • fast/events/resources/before-unload-return-string-conversion-frame.html: Added.
10:34 PM Changeset in webkit [212624] by commit-queue@webkit.org
  • 3 edits in trunk/Source/JavaScriptCore

Unreviewed, rolling out r212472.
​https://bugs.webkit.org/show_bug.cgi?id=168584

Broke CLoop builds when r212466 was rolled out in r212616
(Requested by rniwa on #webkit).

Reverted changeset:

"Unreviewed, fix cloop build."
​http://trac.webkit.org/changeset/212472

10:30 PM Changeset in webkit [212623] by Carlos Garcia Campos
  • 2 edits in trunk/Source/WebCore

[SOUP] Call SoupNetworkSession::setShouldIgnoreTLSErrors when testRunner.setAllowsAnySSLCertificate() is called
​https://bugs.webkit.org/show_bug.cgi?id=168571

Reviewed by Michael Catanzaro.

Fixes: http/tests/ssl/upgrade-origin-usage.html

  • testing/InternalSettings.cpp:

(WebCore::InternalSettings::setAllowsAnySSLCertificate):

10:29 PM Changeset in webkit [212622] by Carlos Garcia Campos
  • 2 edits in trunk/Source/WTF

[GTK] Test fast/events/message-port-postMessage-recursive.html times out
​https://bugs.webkit.org/show_bug.cgi?id=168570

Reviewed by Michael Catanzaro.

This has recently been added and the patch is good. It's just revealing a problem with our timers. The test is
posting a message recursively, and also starts a timeout timer to finish the test. The timeout timer is never
fired for us, because WebCore timers have lower priority than the one used by
postMessage. ScriptExecutionContext uses Document::postTask, that uses scheduleOnMainThread, that uses
RunLoop::dispatch(). We are not setting any priority for the timer used by RunLoop::dispatch, so it's using the
default. RunLoop::dispatch is normally used to schedule tasks between threads, or just to ensure something is
run in a different run loop iteration, but in general nothing urgent as a graphics redraw or something like
that. It's quite common to use g_idle_add to schedule tasks between threads, so I think it makes sense to use
G_PRIORITY_DEFAULT_IDLE for the RunLoop timer.

  • wtf/glib/RunLoopGLib.cpp:

(WTF::RunLoop::RunLoop):

10:22 PM Changeset in webkit [212621] by rniwa@webkit.org
  • 6 edits
    6 adds in trunk

REGRESSION(r212218): Assertion failures in and after parserRemoveChild
​https://bugs.webkit.org/show_bug.cgi?id=168458

Reviewed by Antti Koivisto.

Source/WebCore:

The bug was caused by parserRemoveChild not preceeding to remove oldChild even when
oldChild had been inserted elsewhere during unload evnets of the disconnected frames.
Fixed the bug by checking this condition and exiting early.

Also fixed various callers of parserRemoveChild to not call parserAppendChild when
the removed node had already been inserted elsewhere by scripts.

Tests: fast/parser/adoption-agency-unload-iframe-3.html

fast/parser/adoption-agency-unload-iframe-4.html
fast/parser/xml-error-unload-iframe.html

  • dom/ContainerNode.cpp:

(WebCore::ContainerNode::parserRemoveChild): Exit early when the node had been
inserted elsewhere while firing unload events. Also moved the call to
notifyRemovePendingSheetIfNeeded outside NoEventDispatchAssertion since it can
synchrnously fire a focus event.
(WebCore::ContainerNode::parserAppendChild): Moved adoptNode call to inside
NoEventDispatchAssertion since adoptNode call here should never mutate DOM.

  • html/parser/HTMLConstructionSite.cpp:

(WebCore::executeReparentTask): Added an early exit when the node had already been
inserted elsewhere.
(WebCore::executeInsertAlreadyParsedChildTask): Ditto.

  • xml/XMLErrors.cpp:

(WebCore::XMLErrors::insertErrorMessageBlock): Ditto.

  • xml/parser/XMLDocumentParser.cpp:

(WebCore::XMLDocumentParser::end): Fixed a crash unveiled by one of the test cases.
Exit early when insertErrorMessageBlock detached the parser (by author scripts).
(WebCore::XMLDocumentParser::finish): Keep the parser alive until we exit.

LayoutTests:

Add tests to make sure parserAppendChild aren't called when a node removed by parserRemoveChild
had already been been inserted elsewhere by scripts.

  • fast/parser/adoption-agency-unload-iframe-3-expected.txt: Added.
  • fast/parser/adoption-agency-unload-iframe-3.html: Added.
  • fast/parser/adoption-agency-unload-iframe-4-expected.txt: Added.
  • fast/parser/adoption-agency-unload-iframe-4.html: Added.
  • fast/parser/xml-error-unload-iframe-expected.txt: Added.
  • fast/parser/xml-error-unload-iframe.html: Added.
7:59 PM Changeset in webkit [212620] by mark.lam@apple.com
  • 3 edits in trunk/Source/JavaScriptCore

functionTestWasmModuleFunctions() should use a MarkedArgumentBuffer for storing args instead of a Vector.
​https://bugs.webkit.org/show_bug.cgi?id=168574

Reviewed by Filip Pizlo.

  • jsc.cpp:

(callWasmFunction):
(functionTestWasmModuleFunctions):

  • runtime/ArgList.h:
6:38 PM Changeset in webkit [212619] by Chris Dumez
  • 11 edits
    2 adds in trunk/Source/WebKit2

[WK2] Support termination of unresponsive WebContent processes that are in the background
​https://bugs.webkit.org/show_bug.cgi?id=168479
<rdar://problem/30558745>

Reviewed by Antti Koivisto.

Support termination of unresponsive WebContent processes that are in the background.
This protects us against cases where a background tab is unresponsive and has high CPU
usage, thus draining the battery without the user knowing about it (e.g.
<rdar://problem/29808005>).

The feature works as follows:

  • If a WebProcessProxy has pages but none of them are visible, then it will check regularly if its associated WebContent process is still responsive.
  • Every time we find that the WebContent process is responsive, we exponentially back off the timer to avoid waking up the process too often. The timer initially uses a 20 seconds interval and can back off up to 8 hours.
  • If the WebContent process is unresponsive, then we terminate it. No notification is shown to the user and the termination is not immediately observable since the tab is not visible and its title remains. The tab is not immediately reloaded so as to avoid getting back into a bad state in the background (and have a yo-yo effect).
  • If the user switches to a tab that was previously killed for being unresponsive while in the background, we will then reload the tab in a fresh WebContent process. The crash banner will only be shown if the tab has ever been visible. If it wasn't ever visible (e.g. session restore case), then it will look as if the tab loads for the first time when the user switches to it.

The functionality is disabled by default and can be enabled by the client via the new
WKContextSetUnresponsiveBackgroundProcessesTerminationEnabled() private API.

  • CMakeLists.txt:
  • UIProcess/API/APIProcessPoolConfiguration.cpp:

(API::ProcessPoolConfiguration::copy):

  • UIProcess/API/APIProcessPoolConfiguration.h:
  • UIProcess/API/C/WKContext.cpp:

(WKContextSetUnresponsiveBackgroundProcessesTerminationEnabled):

  • UIProcess/API/C/WKContextPrivate.h:
  • UIProcess/UnresponsiveWebProcessTerminator.cpp: Added.

(WebKit::UnresponsiveWebProcessTerminator::UnresponsiveWebProcessTerminator):
(WebKit::UnresponsiveWebProcessTerminator::updateState):
(WebKit::pagesCopy):
(WebKit::UnresponsiveWebProcessTerminator::timerFired):

  • UIProcess/UnresponsiveWebProcessTerminator.h: Added.

(WebKit::UnresponsiveWebProcessTerminator::shouldBeActive):

  • UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::reattachToWebProcess):
(WebKit::WebPageProxy::reloadAfterBeingKilledInBackground):
(WebKit::WebPageProxy::dispatchActivityStateChange):
(WebKit::WebPageProxy::terminateProcess):
(WebKit::WebPageProxy::resetStateAfterProcessExited):

  • UIProcess/WebPageProxy.h:
  • UIProcess/WebProcessProxy.cpp:

(WebKit::WebProcessProxy::WebProcessProxy):
(WebKit::m_backgroundResponsivenessTimer):
(WebKit::WebProcessProxy::createWebPage):
(WebKit::WebProcessProxy::addExistingWebPage):
(WebKit::WebProcessProxy::removeWebPage):
(WebKit::WebProcessProxy::updateBackgroundResponsivenessTimer):

  • UIProcess/WebProcessProxy.h:

(WebKit::WebProcessProxy::visiblePageCount):

  • WebKit2.xcodeproj/project.pbxproj:
5:46 PM Changeset in webkit [212618] by mark.lam@apple.com
  • 13 edits
    1 add in trunk/Source

CachedCall should let GC know to keep its arguments alive.
​https://bugs.webkit.org/show_bug.cgi?id=168567
<rdar://problem/30475767>

Reviewed by Saam Barati.

Source/JavaScriptCore:

We fix this by having CachedCall use a MarkedArgumentBuffer to store its
arguments instead of a Vector.

Also declared CachedCall, MarkedArgumentBuffer, and ProtoCallFrame as
WTF_FORBID_HEAP_ALLOCATION because they rely on being stack allocated for
correctness.

  • interpreter/CachedCall.h:

(JSC::CachedCall::CachedCall):
(JSC::CachedCall::call):
(JSC::CachedCall::clearArguments):
(JSC::CachedCall::appendArgument):
(JSC::CachedCall::setArgument): Deleted.

  • interpreter/CallFrame.h:

(JSC::ExecState::emptyList):

  • interpreter/Interpreter.cpp:

(JSC::Interpreter::prepareForRepeatCall):

  • interpreter/Interpreter.h:
  • interpreter/ProtoCallFrame.h:
  • runtime/ArgList.cpp:

(JSC::MarkedArgumentBuffer::expandCapacity):

  • runtime/ArgList.h:

(JSC::MarkedArgumentBuffer::ensureCapacity):

  • runtime/StringPrototype.cpp:

(JSC::replaceUsingRegExpSearch):

  • runtime/VM.cpp:

(JSC::VM::VM):

  • runtime/VM.h:

Source/WTF:

Added a WTF_FORBID_HEAP_ALLOCATION that will cause a compilation failure if
a class declared with it is malloced.

While this doesn't prevent that class declared WTF_FORBID_HEAP_ALLOCATION from
being embedded in another class that is heap allocated, it does at minimum
document the intent and gives the users of this class a chance to do the
right thing.

  • WTF.xcodeproj/project.pbxproj:
  • wtf/ForbidHeapAllocation.h: Added.
4:46 PM Changeset in webkit [212617] by Chris Dumez
  • 5 edits
    4 adds in trunk

<input type=color readonly> doesn't act per spec
​https://bugs.webkit.org/show_bug.cgi?id=168421
<rdar://problem/30593185>

Reviewed by Ryosuke Niwa.

Source/WebCore:

The 'readonly' attribute should not apply to <input type=color> as per the
HTML specification:

Chrome / Firefox and Edge already behave as per the specification.

Tests: fast/forms/color/input-color-disabled.html

fast/forms/color/input-color-readonly.html

  • html/ColorInputType.cpp:

(WebCore::ColorInputType::handleDOMActivateEvent):
(WebCore::ColorInputType::didChooseColor):

LayoutTests:

Add layout test coverage.

  • fast/forms/color/input-color-disabled-expected.txt: Added.
  • fast/forms/color/input-color-disabled.html: Added.
  • fast/forms/color/input-color-readonly-expected.txt: Added.
  • fast/forms/color/input-color-readonly.html: Added.
2:07 PM Changeset in webkit [212616] by commit-queue@webkit.org
  • 45 edits
    2 moves
    1 add
    16 deletes in trunk

Unreviewed, rolling out r212466.
​https://bugs.webkit.org/show_bug.cgi?id=168577

causes crashes on AArch64 on linux, maybe it's causing crashes
on iOS too (Requested by pizlo on #webkit).

Reverted changeset:

"The collector thread should only start when the mutator
doesn't have heap access"
​https://bugs.webkit.org/show_bug.cgi?id=167737
​http://trac.webkit.org/changeset/212466

8:24 AM Changeset in webkit [212615] by Alan Bujtas
  • 12 edits in trunk/Source/WebCore

Simple line layout: Implement positionForPoint.
​https://bugs.webkit.org/show_bug.cgi?id=168565
<rdar://problem/30593370>

Reviewed by Antti Koivisto.

With this patch, now we don't need to switch over to line box tree anymore when positionForPoint()
is called on a single RenderText content (which is the majority of the simple line content).
This patch also adds a new positionForPoint method which returns a Position object instead of VisiblePosition.
Some of the positionForPoint() callsites are only interested in the Position object so constructing a VisiblePosition
(which could potentially kick off a layout) is a waste. At this point the non-simple line layout codepath still constructs
a VisiblePosition and that should be addresses as part of webkit.org/b/168566.

Covered by existing tests.

  • dom/Document.cpp:

(WebCore::Document::caretRangeFromPoint):

  • rendering/RenderBlockFlow.cpp:

(WebCore::RenderBlockFlow::positionForPoint):

  • rendering/RenderBlockFlow.h:
  • rendering/RenderObject.cpp:

(WebCore::RenderObject::positionForPoint):

  • rendering/RenderObject.h:
  • rendering/RenderText.cpp:

(WebCore::RenderText::positionForPoint):

  • rendering/RenderText.h:
  • rendering/SimpleLineLayoutFunctions.cpp:

(WebCore::SimpleLineLayout::positionForPoint):

  • rendering/SimpleLineLayoutFunctions.h:
  • rendering/SimpleLineLayoutResolver.cpp:

(WebCore::SimpleLineLayout::RunResolver::runForPoint):

  • rendering/SimpleLineLayoutResolver.h:

(WebCore::SimpleLineLayout::RunResolver::Run::logicalLeft):
(WebCore::SimpleLineLayout::RunResolver::Run::logicalRight):

4:12 AM Changeset in webkit [212614] by Antti Koivisto
  • 15 edits in trunk/Source/WebCore

Execute pending scripts asynchronously after stylesheet loads complete
​https://bugs.webkit.org/show_bug.cgi?id=168367
rdar://problem/30561379

Reviewed by Andreas Kling.

The current synchronous execution is fragile and creates various problems.

  • css/StyleSheetContents.cpp:

(WebCore::StyleSheetContents::checkLoaded):

  • dom/ContainerNode.cpp:

(WebCore::ContainerNode::takeAllChildrenFrom):
(WebCore::ContainerNode::notifyChildInserted):
(WebCore::ContainerNode::removeChild):
(WebCore::ContainerNode::parserRemoveChild):
(WebCore::ContainerNode::removeChildren):

Remove various places where we would trigger delayed synchronous execution.

  • dom/Document.cpp:

(WebCore::Document::Document):
(WebCore::Document::recalcStyle):

Trigger scroll to anchor at the end of style resolution instead of when style sheet load completes.

(WebCore::Document::didRemoveAllPendingStylesheet):

Call asynchronous script execution function.

  • dom/Document.h:

(WebCore::Document::setNeedsNotifyRemoveAllPendingStylesheet): Deleted.
(WebCore::Document::notifyRemovePendingSheetIfNeeded): Deleted.

  • dom/ScriptableDocumentParser.cpp:

(WebCore::ScriptableDocumentParser::ScriptableDocumentParser):
(WebCore::ScriptableDocumentParser::executeScriptsWaitingForStylesheetsSoon):
(WebCore::ScriptableDocumentParser::scriptsWaitingForStylesheetsExecutionTimerFired):

Add a timer for executing pending scripts.

(WebCore::ScriptableDocumentParser::detach):

  • dom/ScriptableDocumentParser.h:

(WebCore::ScriptableDocumentParser::executeScriptsWaitingForStylesheets):

  • html/HTMLLinkElement.cpp:

(WebCore::HTMLLinkElement::removedFrom):
(WebCore::HTMLLinkElement::removePendingSheet):

  • html/HTMLLinkElement.h:
  • html/parser/HTMLDocumentParser.cpp:

(WebCore::HTMLDocumentParser::detach):

  • loader/DocumentLoader.cpp:

(WebCore::DocumentLoader::isLoadingInAPISense):

Stay in loading state if we have a pending script. This matches existing behavior.

  • style/StyleScope.cpp:

(WebCore::Style::Scope::removePendingSheet):

  • style/StyleScope.h:
3:54 AM Changeset in webkit [212613] by Carlos Garcia Campos
  • 2 edits in trunk/LayoutTests

Unreviewed GTK+ gardening. Rebaseline fast/visual-viewport/rubberbanding-viewport-rects-extended-background.html again.

This matches what bots expect now.

  • platform/gtk/fast/visual-viewport/rubberbanding-viewport-rects-extended-background-expected.txt:
3:39 AM Changeset in webkit [212612] by Carlos Garcia Campos
  • 1 edit
    1 add in trunk/LayoutTests

Unreviewed GTK+ gardening. Rebaseline http/tests/loading/server-redirect-for-provisional-load-caching.html.

I think we are just setting the FirstPartyForCookies to our request a bit earlier when redirecting.

  • platform/gtk/http/tests/loading/server-redirect-for-provisional-load-caching-expected.txt: Added.
3:14 AM Changeset in webkit [212611] by Carlos Garcia Campos
  • 2 edits
    2 adds in trunk/LayoutTests

Unreviewed GTK+ gardening. Update expectations of a few more tests and rebaseline fast/visual-viewport/rubberbanding-viewport-rects-extended-background.html.

  • platform/gtk/TestExpectations:
  • platform/gtk/fast/visual-viewport/rubberbanding-viewport-rects-extended-background-expected.txt: Added.

Feb 18, 2017:

11:22 PM Changeset in webkit [212610] by Chris Dumez
  • 10 edits in trunk

<input type=range readonly> doesn't act per spec
​https://bugs.webkit.org/show_bug.cgi?id=168422
<rdar://problem/30593189>

Reviewed by Ryosuke Niwa.

Source/WebCore:

'readonly' attribute should not apply to <input type=range> as per the HTML
specification:

Firefox and Edge already behave as per the specification.

No new tests, updated existing tests.

  • html/RangeInputType.cpp:

(WebCore::RangeInputType::handleMouseDownEvent):
(WebCore::RangeInputType::handleTouchEvent):
(WebCore::RangeInputType::handleKeydownEvent):

  • html/shadow/SliderThumbElement.cpp:

(WebCore::SliderThumbElement::defaultEventHandler):
(WebCore::SliderThumbElement::willRespondToMouseMoveEvents):
(WebCore::SliderThumbElement::willRespondToMouseClickEvents):

LayoutTests:

Update / rebaseline existing tests to reflect behavior change.

  • fast/forms/range/range-drag-expected.txt:
  • fast/forms/range/range-drag-when-toggled-disabled-expected.txt:
  • fast/forms/range/range-drag-when-toggled-disabled.html:
  • fast/forms/range/range-drag.html:
  • fast/forms/range/range-keyoperation-expected.txt:
  • fast/forms/range/range-keyoperation.html:
3:58 PM Changeset in webkit [212609] by Chris Dumez
  • 8 edits
    2 adds in trunk

Recursive MessagePort.postMessage() calls causes tab to become unresponsive
​https://bugs.webkit.org/show_bug.cgi?id=168548
<rdar://problem/29808005>

Reviewed by Darin Adler.

Source/WebCore:

MessagePort::dispatchMessages() was getting messages one by one of the
channel's MessageQueue and firing the MessageEvent for each of them.
The issue is that we can get stuck in an infinite loop if the
MessageEvent handler posts a message on the same post.

To address the issue, we now takes all messages from the queue before
iterating over them to fire the event. This way, if new messages are
added to the queue in one of the MessageEvent handlers, they will not
be processed until the next event loop iteration, as is expected.

Test: fast/events/message-port-postMessage-recursive.html

  • dom/MessagePort.cpp:

(WebCore::MessagePort::dispatchMessages):

  • dom/MessagePortChannel.h:

(WebCore::MessagePortChannel::EventData::EventData):

  • dom/default/PlatformMessagePortChannel.cpp:

(WebCore::MessagePortChannel::postMessageToRemote):

  • dom/default/PlatformMessagePortChannel.h:

(WebCore::PlatformMessagePortChannel::MessagePortQueue::takeMessage):
(WebCore::PlatformMessagePortChannel::MessagePortQueue::takeAllMessages):
(WebCore::PlatformMessagePortChannel::MessagePortQueue::appendAndCheckEmpty):

Source/WTF:

Add API to retrieve all messages in the queue at once.

  • wtf/MessageQueue.h:

LayoutTests:

Add layout test coverage. The test used to time out, it now passes.
The test also passes on Firefox and Chrome.

  • fast/events/message-port-postMessage-recursive-expected.txt: Added.
  • fast/events/message-port-postMessage-recursive.html: Added.
3:08 PM Changeset in webkit [212608] by Michael Catanzaro
  • 24 edits
    5 deletes in trunk/Source

Remove COORDINATED_GRAPHICS_MULTIPROCESS
​https://bugs.webkit.org/show_bug.cgi?id=168514

Reviewed by Darin Adler.

Source/WebCore:

  • platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.cpp:
  • platform/graphics/gstreamer/MediaPlayerPrivateGStreamerBase.h:

Source/WebKit2:

  • Shared/DrawingAreaInfo.h:
  • UIProcess/API/C/CoordinatedGraphics/WKView.cpp:

(WKViewFindZoomableAreaForRect):

  • UIProcess/AcceleratedDrawingAreaProxy.cpp:

(WebKit::AcceleratedDrawingAreaProxy::AcceleratedDrawingAreaProxy):

  • UIProcess/AcceleratedDrawingAreaProxy.h:

(WebKit::AcceleratedDrawingAreaProxy::coordinatedLayerTreeHostProxy): Deleted.

  • UIProcess/CoordinatedGraphics/CoordinatedLayerTreeHostProxy.cpp: Removed.
  • UIProcess/CoordinatedGraphics/CoordinatedLayerTreeHostProxy.h: Removed.
  • UIProcess/CoordinatedGraphics/CoordinatedLayerTreeHostProxy.messages.in: Removed.
  • UIProcess/CoordinatedGraphics/PageViewportController.cpp:

(WebKit::PageViewportController::pageTransitionViewportReady):

  • UIProcess/CoordinatedGraphics/WebPageProxyCoordinatedGraphics.cpp: Removed.
  • UIProcess/DrawingAreaProxy.h:
  • UIProcess/PageClient.h:
  • UIProcess/WebPageProxy.cpp:

(WebKit::WebPageProxy::pageDidRequestScroll): Deleted.
(WebKit::WebPageProxy::pageTransitionViewportReady): Deleted.
(WebKit::WebPageProxy::didRenderFrame): Deleted.
(WebKit::WebPageProxy::commitPageTransitionViewport): Deleted.

  • UIProcess/WebPageProxy.h:
  • UIProcess/WebPageProxy.messages.in:
  • WebProcess/WebPage/AcceleratedDrawingArea.cpp:

(WebKit::AcceleratedDrawingArea::AcceleratedDrawingArea):
(WebKit::AcceleratedDrawingArea::updateBackingStoreState):
(WebKit::AcceleratedDrawingArea::didReceiveCoordinatedLayerTreeHostMessage): Deleted.

  • WebProcess/WebPage/AcceleratedDrawingArea.h:
  • WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:

(WebKit::CoordinatedLayerTreeHost::CoordinatedLayerTreeHost):
(WebKit::CoordinatedLayerTreeHost::commitSceneState):
(WebKit::CoordinatedLayerTreeHost::createCoordinatedSurface):

  • WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.h:
  • WebProcess/WebPage/CoordinatedGraphics/WebPageCoordinatedGraphics.cpp: Removed.
  • WebProcess/WebPage/DrawingArea.cpp:

(WebKit::DrawingArea::create):

  • WebProcess/WebPage/DrawingArea.h:
  • WebProcess/WebPage/LayerTreeHost.cpp:

(WebKit::LayerTreeHost::create):

  • WebProcess/WebPage/LayerTreeHost.h:
  • WebProcess/WebPage/WebPage.cpp:

(WebKit::WebPage::~WebPage):
(WebKit::WebPage::pageDidRequestScroll):
(WebKit::WebPage::didCompletePageTransition):
(WebKit::WebPage::didReceiveMessage):
(WebKit::WebPage::commitPageTransitionViewport): Deleted.

  • WebProcess/WebPage/WebPage.h:
  • WebProcess/WebPage/WebPage.messages.in:
2:30 AM Changeset in webkit [212607] by Carlos Garcia Campos
  • 2 edits in trunk/LayoutTests

Unreviewed GTK+ gardening. Update expectations of a few more tests that are failing.

  • platform/gtk/TestExpectations:
2:17 AM Changeset in webkit [212606] by Carlos Garcia Campos
  • 1 edit
    5 adds in trunk/LayoutTests

Unreviewed GTK+ gardening. Rebaseline imported/w3c/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea.html.

Selection is always directional for us.

  • platform/gtk/imported/w3c/web-platform-tests/html/semantics/forms/textfieldselection/selection-not-application-textarea-expected.txt: Added.
2:01 AM Changeset in webkit [212605] by Michael Catanzaro
  • 2 edits in trunk/Source/WebKit2

[GTK] Cannot paste primary selection into web view in Wayland
​https://bugs.webkit.org/show_bug.cgi?id=166949

Reviewed by Carlos Garcia Campos.

Once upon a time, primary selection (middle-click paste) was not supported in Wayland. At
the time, I changed this function to report that primary selection was unsupported. But
nowadays, primary selection works fine in all GTK+ applications except WebKit. All we have
to do to make it work in WebKit is change this return value.

  • WebProcess/WebCoreSupport/WebEditorClient.cpp:

(WebKit::WebEditorClient::supportsGlobalSelection):

1:44 AM Changeset in webkit [212604] by Carlos Garcia Campos
  • 2 edits in trunk/LayoutTests

Unreviewed GTK+ gardening. Update expectations of several tests.

  • platform/gtk/TestExpectations:
Note: See TracTimeline for information about the timeline view.