Bug 280247 – [WPE][GTK] IPC communication with web processes broken when PSON is enabled

• Status: NEW
• Component: WebKitGTK

Since bug #278016 was closed and fixed a regression I'd like to start
a new bug with the unresolved issues presented there

"When a new webprocess is swapped in, it appears to be unable to
communicate with the ui process. typically the page-created is used to
communicate to the parent process to negotiate an IPC channel and/or
register the page-id for further communication, this seems to be
failing."

This is not a regression as it broken even in webkit 2.44

"when "process-swap-on-cross-site-navigation-enabled" is turned
on messages sent by
webkit_web_page_send_message_to_view messages are not delivered at all
from the "page-created" callback to the WebView.

webkit_web_extension_send_message_to_context is delivered to the
WebContext in the UI process but the WeBPage page_id is not yet
initialized, and there is no reliable way to assciate the WebProcess
with the WebPage on the page-created signal"

It is not only that these officially supported IPC mechanisms
fail, all IPC seems to be failing. Perhaps Chris could verify
this is the case?

The comment should read "reliable way to associate the WebPage [(of the swapped in WebProcess)] with the WebView" 

[at the page-created stage]

[Michael Catanzaro]

With PSON enabled, you probably don't want to use your own IPC channel anymore. But if you do so, then your code needs to be aware of process swaps.

> "when "process-swap-on-cross-site-navigation-enabled" is turned
> on messages sent by
> webkit_web_page_send_message_to_view messages are not delivered at all
> from the "page-created" callback to the WebView.

How exactly does it fail? The function call completes successfully (webkit_web_page_send_message_to_view_finish() does not return any error)?

page-created is probably just too soon. Maybe the page is not associated with a web view yet? But you should at least receive an error.

> webkit_web_extension_send_message_to_context is delivered to the
> WebContext in the UI process but the WeBPage page_id is not yet
> initialized, and there is no reliable way to assciate the WebProcess
> with the WebPage on the page-created signal"

WebKitUserMessage doesn't convey page_id. Where exactly are you noticing an uninitialized page_id?

Sorry if I'm repeating myself, but the message sent by webkit_web_page_send_message_to_view messages  (from the "page-created" callback) 
is not received by the view.
this means that the "user-message-received" signal does not fire
in the view. consequently any webkit_user_message_send_reply that
the view sends to the webpage never gets called. Consequently
The AsyncReadyCallback passed to webkit_user_message_send_reply
never gets called, and so any webkit_web_page_send_message_to_view_finish
in that AsyncReadyCallback never gets called.

I'll address to the other errors (pageid including zombie webprocesses)
once you can verify this behaviour is indeed happening
and I am correct in stating what I am observing.

[Michael Catanzaro]

(In reply to enometh from comment #3)
> Sorry if I'm repeating myself, but the message sent by
> webkit_web_page_send_message_to_view messages  (from the "page-created"
> callback) 
> is not received by the view.
> this means that the "user-message-received" signal does not fire
> in the view. consequently any webkit_user_message_send_reply that
> the view sends to the webpage never gets called. Consequently
> The AsyncReadyCallback passed to webkit_user_message_send_reply
> never gets called, and so any webkit_web_page_send_message_to_view_finish
> in that AsyncReadyCallback never gets called.

OK, I think WebKit shouldn't allow this to happen. Even if the communication is not going to be possible, the calls should fail rather than just never return.

> I'll address to the other errors (pageid including zombie webprocesses)
> once you can verify this behaviour is indeed happening
> and I am correct in stating what I am observing.

Please attach a demo program.

the setup I posted in https://bugs.webkit.org/show_bug.cgi?id=278016 (2024-08-13) with surf demonstrates the problem even if the code is not conceptually right, the only difference would be that pson should be explicitly enabled.