[GTK] WebKitWebView::load-failed-with-tls-errors should receive the failing URI instead of a host
https://bugs.webkit.org/show_bug.cgi?id=136889

Reviewed by Gustavo Noronha Silva.

Source/WebKit2:

We were passing a host for two different reasons, first because
it's more convenient to add an exception with
webkit_web_context_allow_tls_certificate_for_host(), but also
because we were assuming the active URI is the failing URI in case
of failure. This assumption is correct because our current code
does that, but I'm not sure we are doing it on purpose. That
behaviour is not documented anywhere and it's not what WebKit2 does
internaly.

* UIProcess/API/gtk/WebKitWebView.cpp:
(webkit_web_view_class_init):
(webkitWebViewLoadFailedWithTLSErrors):
* UIProcess/API/gtk/WebKitWebView.h:

Tools:

* TestWebKitAPI/Tests/WebKit2Gtk/TestSSL.cpp:
(testLoadFailedWithTLSErrors): Check that LoadFailedWithTLSErrors
event was added to the events vector.
* TestWebKitAPI/gtk/WebKit2Gtk/LoadTrackingTest.cpp:
(loadFailedCallback): Do not assume the web view URI is the
failing URI when the load fails before the committed state.
(loadFailedWithTLSErrorsCallback): Handle the case of load failure
because of TLS errors can call LoadTrackingTest::loadFailedWithTLSErrors.
(LoadTrackingTest::LoadTrackingTest): Connect to WebKitWebView::load-failed-with-tls-errors.
(LoadTrackingTest::loadFailedWithTLSErrors): Add
LoadFailedWithTLSErrors event to the events vector.
* TestWebKitAPI/gtk/WebKit2Gtk/LoadTrackingTest.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@173691 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Fix runtime critical warnings when writing to the clipboard after r173687
https://bugs.webkit.org/show_bug.cgi?id=136891

Reviewed by Philippe Normand.

* platform/gtk/PasteboardHelper.cpp:
(WebCore::PasteboardHelper::writeClipboardContents): Check passed
callback is not null before trying to ref/unref it since
g_closure_ref/unref are not null safe.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@173692 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Exclude page visibility from PageThrottler's hysteresis
https://bugs.webkit.org/show_bug.cgi?id=136866

Reviewed by Geoff Garen.

Including visibility in the hysteresis mechanism has the effect of prolonging the visually
idle timeout, and causing the page hide event to be run at foreground priority. Neither of
these are particularly desirable. Instead separate visibility from the rest of the page
activities we track (and apply hysteresis to), and feed this directly into determination
of the UserActivity state.

* page/PageThrottler.cpp:
(WebCore::PageThrottler::PageThrottler):
    - when the PageThrottler is instantiated call updateUserActivity to set initial UserActivity.
(WebCore::PageThrottler::incrementActivityCount):
    - simplified - when m_activityCount becomes non-zero, start m_hysteresis.
(WebCore::PageThrottler::decrementActivityCount):
    - simplified - when m_activityCount becomes zero, stop m_hysteresis.
(WebCore::PageThrottler::updateUserActivity):
    - end the UserActivity (allow AppNap) if visually idle and no page activity is taking place.
(WebCore::PageThrottler::setViewState):
    - when the visually idle state changed call updateUserActivity to update the UserActivity.
(WebCore::PageThrottler::started):
(WebCore::PageThrottler::stopped):
    - when the hysteresis state changed call updateUserActivity to update the UserActivity.
(WebCore::PageThrottler::updateHysteresis): Deleted.
    - removed: simplified the hysteresis trigger, we now incorporate visually idle state in updateUserActivity.
* page/PageThrottler.h:
    - removed updateHysteresis, added updateUserActivity.
* platform/HysteresisActivity.h:
(WebCore::HysteresisActivity::state):
    - determine the curent state of the HysteresisActivity - started, waiting, or stopped.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@173693 268f45cc-cd09-0410-ab3c-d52691b4dbfc