Memory-managed wrapper type.

Type class for types which can be safely cast to UserContentManager, for instance with toUserContentManager.

Cast to UserContentManager, for types for which this is known to be safe. For general casts, use castTo.

Adds a UserContentFilter to the given UserContentManager.

The same UserContentFilter can be reused with multiple UserContentManager instances.

Filters need to be saved and loaded from UserContentFilterStore.

Since: 2.24

Adds a UserScript to the given UserContentManager.

The same UserScript can be reused with multiple UserContentManager instances.

Since: 2.6

Adds a UserStyleSheet to the given UserContentManager.

The same UserStyleSheet can be reused with multiple UserContentManager instances.

Since: 2.6

Creates a new user content manager.

Since: 2.6

Registers a new user script message handler in script world.

After it is registered, scripts can use window.webkit.messageHandlers.<name>.postMessage(value) to send messages. Those messages are received by connecting handlers to the UserContentManager::scriptMessageReceived signal. The handler name is used as the detail of the signal. To avoid race conditions between registering the handler name, and starting to receive the signals, it is recommended to connect to the signal *before* registering the handler name:

c code

WebKitWebView *view = webkit_web_view_new ();
WebKitUserContentManager *manager = webkit_web_view_get_user_content_manager ();
g_signal_connect (manager, "script-message-received::foobar",
                  G_CALLBACK (handle_script_message), NULL);
webkit_user_content_manager_register_script_message_handler (manager, "foobar");

Registering a script message handler will fail if the requested name has been already registered before.

If Nothing is passed as the worldName, the default world will be used.

The registered handler can be unregistered by using userContentManagerUnregisterScriptMessageHandler.

Since: 2.40

Registers a new user script message handler in script world with name worldName.

Different from userContentManagerRegisterScriptMessageHandler, when using this function to register the handler, the connected signal is script-message-with-reply-received, and a reply provided by the user is expected. Otherwise, the user will receive a default undefined value.

If Nothing is passed as the worldName, the default world will be used. See userContentManagerRegisterScriptMessageHandler for full description.

Registering a script message handler will fail if the requested name has been already registered before.

The registered handler can be unregistered by using userContentManagerUnregisterScriptMessageHandler.

Since: 2.40

Removes all content filters from the given UserContentManager.

Since: 2.24

Removes all user scripts from the given UserContentManager

See also userContentManagerRemoveScript.

Since: 2.6

Removes all user style sheets from the given UserContentManager.

Since: 2.6

Removes a filter from the given UserContentManager.

Since 2.24

Removes a filter by the given identifier.

Removes a filter from the given UserContentManager given the identifier of a UserContentFilter as returned by userContentFilterGetIdentifier.

Since: 2.26

Removes a UserScript from the given UserContentManager.

See also userContentManagerRemoveAllScripts.

Since: 2.32

Removes a UserStyleSheet from the given UserContentManager.

See also userContentManagerRemoveAllStyleSheets.

Since: 2.32

Unregisters a previously registered message handler in script world with name worldName. If Nothing is passed as the worldName, the default world will be used.

Note that this does *not* disconnect handlers for the UserContentManager::scriptMessageReceived signal; they will be kept connected, but the signal will not be emitted unless the handler name is registered again.

See also userContentManagerRegisterScriptMessageHandler.

Since: 2.40

This signal is emitted when JavaScript in a web view calls <code>window.webkit.messageHandlers.<name>.postMessage()</code>, after registering <code><name></code> using userContentManagerRegisterScriptMessageHandler

Since: 2.8

Connect a signal handler for the scriptMessageReceived signal, to be run after the default handler. When overloading is enabled, this is equivalent to

after userContentManager #scriptMessageReceived callback

This signal admits a optional parameter detail. If it's not Nothing, we will connect to “script-message-received::detail” instead.

By default the object invoking the signal is not passed to the callback. If you need to access it, you can use the implit ?self parameter. Note that this requires activating the ImplicitParams GHC extension.

Connect a signal handler for the scriptMessageReceived signal, to be run before the default handler. When overloading is enabled, this is equivalent to

on userContentManager #scriptMessageReceived callback

This signal admits a optional parameter detail. If it's not Nothing, we will connect to “script-message-received::detail” instead.

This signal is emitted when JavaScript in a web view calls <code>window.webkit.messageHandlers.<name>.postMessage()</code>, after registering <code><name></code> using userContentManagerRegisterScriptMessageHandlerWithReply

The given reply can be used to send a return value with scriptMessageReplyReturnValue or an error message with scriptMessageReplyReturnErrorMessage. If none of them are called, an automatic reply with an undefined value will be sent.

It is possible to handle the reply asynchronously, by simply calling objectRef on the reply and returning True.

Since: 2.40

Connect a signal handler for the scriptMessageWithReplyReceived signal, to be run after the default handler. When overloading is enabled, this is equivalent to

after userContentManager #scriptMessageWithReplyReceived callback

This signal admits a optional parameter detail. If it's not Nothing, we will connect to “script-message-with-reply-received::detail” instead.

By default the object invoking the signal is not passed to the callback. If you need to access it, you can use the implit ?self parameter. Note that this requires activating the ImplicitParams GHC extension.

Connect a signal handler for the scriptMessageWithReplyReceived signal, to be run before the default handler. When overloading is enabled, this is equivalent to

on userContentManager #scriptMessageWithReplyReceived callback

This signal admits a optional parameter detail. If it's not Nothing, we will connect to “script-message-with-reply-received::detail” instead.