WPEWebKitWebView

This signal is emitted when the user is challenged with HTTP authentication. To let the application access or supply the credentials as well as to allow the client application to either cancel the request or perform the authentication, the signal will pass an instance of the WebKitAuthenticationRequest in the request argument. To handle this signal asynchronously you should keep a ref of the request and return TRUE. To disable HTTP authentication entirely, connect to this signal and simply return TRUE.

Available since: 2.2

Emitted when closing a WebKitWebView is requested. This occurs when a call is made from JavaScript’s window.close function or after trying to close the web_view with webkit_web_view_try_close(). It is the owner’s responsibility to handle this signal to hide or destroy the WebKitWebView, if necessary.

Emitted after WebKitWebView::context-menu signal, if the context menu is shown, to notify that the context menu is dismissed.

Emitted when the creation of a new WebKitWebView is requested. If this signal is handled the signal handler should return the newly created WebKitWebView.

This signal is emitted when WebKit is requesting the client to decide a policy decision, such as whether to navigate to a page, open a new window or whether or not to download a resource. The WebKitNavigationPolicyDecision passed in the decision argument is a generic type, but should be casted to a more specific type when making the decision. For example:

Emitted when JavaScript code calls element.webkitRequestFullScreen. If the signal is not handled the WebKitWebView will proceed to full screen its top level window. This signal can be used by client code to request permission to the user prior doing the full screen transition and eventually prepare the top-level window (e.g. hide some widgets that would otherwise be part of the full screen window).

This signal is emitted when insecure content has been detected in a page loaded through a secure connection. This typically means that a external resource from an unstrusted source has been run or displayed, resulting in a mix of HTTPS and non-HTTPS content.

Emitted when the WebKitWebView is about to restore its top level window out of its full screen state. This signal can be used by client code to restore widgets hidden during the WebKitWebView::enter-fullscreen stage for instance.

Emitted when a load operation in web_view changes. The signal is always emitted with WEBKIT_LOAD_STARTED when a new load request is made and WEBKIT_LOAD_FINISHED when the load finishes successfully or due to an error. When the ongoing load operation fails WebKitWebView::load-failed signal is emitted before WebKitWebView::load-changed is emitted with WEBKIT_LOAD_FINISHED. If a redirection is received from the server, this signal is emitted with WEBKIT_LOAD_REDIRECTED after the initial emission with WEBKIT_LOAD_STARTED and before WEBKIT_LOAD_COMMITTED. When the page content starts arriving the signal is emitted with WEBKIT_LOAD_COMMITTED event.

Emitted when an error occurs during a load operation. If the error happened when starting to load data for a page load_event will be WEBKIT_LOAD_STARTED. If it happened while loading a committed data source load_event will be WEBKIT_LOAD_COMMITTED. Since a load error causes the load operation to finish, the signal WebKitWebView::load-changed will always be emitted with WEBKIT_LOAD_FINISHED event right after this one.

Emitted when a TLS error occurs during a load operation. To allow an exception for this certificate and the host of failing_uri use webkit_web_context_allow_tls_certificate_for_host().

Available since: 2.6

This signal is emitted when the mouse cursor moves over an element such as a link, image or a media element. To determine what type of element the mouse cursor is over, a Hit Test is performed on the current mouse coordinates and the result is passed in the hit_test_result argument. The modifiers argument is a bitmask of GdkModifierType flags indicating the state of modifier keys. The signal is emitted again when the mouse is moved out of the current element with a new hit_test_result.

This signal is emitted when WebKit is requesting the client to decide about a permission request, such as allowing the browser to switch to fullscreen mode, sharing its location or similar operations.

This signal allows the User-Agent to respond to permission requests for powerful features, as specified by the Permissions W3C Specification. You can reply to the query using webkit_permission_state_query_finish().

Available since: 2.40

Emitted after WebKitWebView::create on the newly created WebKitWebView when it should be displayed to the user. When this signal is emitted all the information about how the window should look, including size, position, whether the location, status and scrollbars should be displayed, is already set on the WebKitWindowProperties of web_view. See also webkit_web_view_get_window_properties().

Emitted when a new resource is going to be loaded. The request parameter contains the WebKitURIRequest that will be sent to the server. You can monitor the load operation by connecting to the different signals of resource.

Emitted after WebKitWebView::ready-to-show on the newly created WebKitWebView when JavaScript code calls window.showModalDialog. The purpose of this signal is to allow the client application to prepare the new view to behave as modal. Once the signal is emitted a new main loop will be run to block user interaction in the parent WebKitWebView until the new dialog is closed.

This signal is emitted when the user interacts with a HTML element, requesting from WebKit to show a dialog to select one or more files to be uploaded. To let the application know the details of the file chooser, as well as to allow the client application to either cancel the request or perform an actual selection of files, the signal will pass an instance of the WebKitFileChooserRequest in the request argument.

Emitted when JavaScript code calls window.alert, window.confirm or window.prompt, or when onbeforeunload event is fired. The dialog parameter should be used to build the dialog. If the signal is not handled a different dialog will be built and shown depending on the dialog type: WEBKIT_SCRIPT_DIALOG_ALERT: message dialog with a single Close button. WEBKIT_SCRIPT_DIALOG_CONFIRM: message dialog with OK and Cancel buttons. WEBKIT_SCRIPT_DIALOG_PROMPT: message dialog with OK and Cancel buttons and a text entry with the default text. WEBKIT_SCRIPT_DIALOG_BEFORE_UNLOAD_CONFIRM: message dialog with Stay and Leave buttons.

This signal is emitted when a notification should be presented to the user. The notification is kept alive until either: 1) the web page cancels it or 2) a navigation happens.

Available since: 2.8

This signal is emitted when a form is about to be submitted. The request argument passed contains information about the text fields of the form. This is typically used to store login information that can be used later to pre-fill the form. The form will not be submitted until webkit_form_submission_request_submit() is called.

This signal is emitted when a WebKitUserMessage is received from the WebKitWebPage corresponding to web_view. You can reply to the message using webkit_user_message_send_reply().

Available since: 2.28

This signal is emitted when the web process terminates abnormally due to reason.

Available since: 2.20