Bug 278016 – REGRESSION(275829@main): [GTK] PSON improperly enabled by default in GTK 3 API versions

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

Created attachment 472131 [details]
log for 2.46.5 with webext-surf

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, and messages and IPC to the parent process seem to be
dropped.  For a concrete case consider the suckless surf browser
git://git.suckless.org/surf branch origin/surf-webkit2 commit
9ef79bf7106496c736, patchs (to make it use webkit2gtk-4.1), and add
some debugging messages.

weburf-ext.c uses usermessages to communicate with the ui process and
get a ipc fd for further communications, it provides minimal
functionality by implementing scrolling via javascript. To show the
problem I use these steps first with with webkit-2.43.1 and then with
webkit-2.45.6.

 1. run "surf webkit://gpu"
 2. Ctrl-g , enter "file:///tmp" (to navigate to a new url with pages of scroll)
 3. type Ctrl-SPC Ctrl-b to scroll the page (via the extension)

There is no process swapping im 2.43.1, and in the step where the
communication is supposed to happen in webext-surf.c:(pagecreated),
i see a
```
Unhandled message WebPageProxy_SendMessageToWebViewWithReply from provisional process
```
The UI process doesn't see any message from the the web process.

Other browsers that use IPC without webkit user messages also seem to
be unable to communicate with the ui process (through unix send() on a
unix socket). The ui process cannot get to know how to contact the
webprocess, though the new WebPage is reflected in the WebView
page-id.

I'll be glad to supply more information and logs if needed. Can you
spot if surf is doing something wrong? or perhaps "process suspension"
stops the IPC messaging somehow

[Michael Catanzaro]

If your process is suspended, it wouldn't be able to send messages at all. It uses SIGSTOP/SIGCONT.

Created attachment 472140 [details]
patch for the surf browser mentioned in comment 1 (needed if surf is to be used to bisect)

[Michael Catanzaro]

I checked the surf source code, and I don't think it enables PSON at all.

Changing the Summary is misleading, It is true
that the immediate regression is that
pson is getting enabled on 4.1 api, where is should not
be enabled.  But the problem
I'm reporting is a bug in the IPC when PSON is enabled.

 "[Bug 278016] 2.45.6 communication with web processes under PSON"

The choice of my test case is unfortunate since surf is not
set up for pson and IPC, but the problem I want to demonstrate here
is when the security context changes,
a new extension process is created, and a new page is created
in the extension process, but user mesages sent when by the web page
to the ui process are not being delivered.

at the point the new page is created in the extension process,
other IPC mechanisms like send(2) to the UI process also fail

[Michael Catanzaro]

Your original summary here was "2.45.6 communication with web processes under PSON" which describes a topic rather than a bug. Feel free to reword it.

[Michael Catanzaro]

BTW: next step here is for somebody to bisect and figure out when this broke.

Created attachment 472637 [details]
fix unconditional pson on 4.1 api


I spotted this with a git grep psonEnabled, a misplaced ifdef CAIRO in
the 2.45.1 snapshot. The patch fixes the clients using webkit2-4.1
without turning on PSON

However when process-swap-on-cross-site-navigation-enabled is turned
on , the IPC communication bug I reported here is still present.

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.

Any insights (into what I may be missing) or advice welcome

[EWS]

No reviewer information in commit message, blocking PR #None. Details: [Build #1804](https://ews-build.webkit.org/#/builders/27/builds/1804)

[Michael Catanzaro]

Comment on attachment 472637 [details]
fix unconditional pson on 4.1 api

Thanks. You'll need to fix the commit message format.

An application that expects PSON will presumably not use these APIs in the same way surf is doing.

[Michael Catanzaro]

Proper commit message format is:



REGRESSION(275829@main): Communication with web processes broken in surf browser
https://bugs.webkit.org/show_bug.cgi?id=278016

Reviewed by NOBODY (OOPS!)

do not turn on pson unconditionally on 4.1 api when using skia

 * Source/WebKit/UIProcess/API/glib/WebKitWebContext.cpp:
(webkitWebContextConstructed): PSON was getting turned on
unconditionally in non-cairo builds.

[Michael Catanzaro]

Created attachment 472644 [details]
Patch attempt #2

Here's the same patch with a different commit message. Let's see if this works.

[EWS]

Committed 284088@main (911966a71e7c): <https://commits.webkit.org/284088@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 472644 [details].

[Adrian Perez]

The patch is now backported into the 2.46 branch in this commit:

 https://commits.webkit.org/282416.127@webkitglib/2.46