[webkit-gtk] Sockets/file descriptors and the web extension

[Eric Williams]

On 12/5/18 3:28 PM, Michael Catanzaro wrote:
> WebKit uses several child processes. A WebKitWebExtension is just a way 
> to run code in the WebKitWebProcess. Each WebKitWebView corresponds to 
> one WebKitNetworkProcess and one or more WebKitWebProcess processes. 
> These will be created regardless of whether or not you use the 
> WebKitWebExtension class to inject code into the WebKitWebProcess 
> processes.
> 
> On Wed, Dec 5, 2018 at 1:51 PM, Adrian Perez de Castro 
> <aperez at igalia.com> wrote:
>> Are you setting the close-on-exec flag [1] on the file descriptor? If 
>> not,
>> it may be as well that the file descriptor for the socket is being 
>> inherited
>> by the child processes (WebKitNetworProcess, WebKitWebProcess, etc).
> 
> This should not be possible. WebKit creates subprocesses using 
> g_spawn_async() in ProcessLauncherGLib.cpp. You can review the relevant 
> code in GLib's gspawn.c. After forking, GLib iterates through all open 
> file descriptors (except stdin, stdout, and stderr) and sets FD_CLOEXEC 
> on each one to ensure they get closed when it later calls exec.
> 
> Otherwise, if Eclipse failed to set CLOEXEC itself, then the file 
> descriptors would be leaked in the child process, and you would probably 
> wind up with this socket in use or not available error. (This behavior 
> can be disabled using the G_SPAWN_LEAVE_DESCRIPTORS_OPEN flag, but 
> WebKit does not use this flag.)

This is very useful thank you, I am going to look into the closing of 
the port/socket a bit more closely as I am starting to suspect the issue 
lies there and not with WebKit.


> So Eric, you say "debugging shows that the web extension still holds 
> onto the socket/file descriptor." Are you sure the affected file 
> descriptor is really owned by the WebKitWebProcess? If so, something 
> very weird is happening inside gspawn.c, because it shouldn't be possible.

This is what was provided to me by the end user, and it's observed that 
the bug is reproducible in certain steps, only when a web extension is 
created. However this again could be related to the closing of the 
port/socket and not a WebKit issue. I'll look into it further.


>> On a different note, from the brief description if the use case you 
>> gave on
>> your first e-mail, I think you can probably get things done without using
>> a WebKitWebExtension at all.
> 
> Yes, if it's possible to avoid the need for a WebKitWebExtension 
> altogether, that would be ideal.

I did not write the WebKit implementation for SWT, but IIRC the reasons 
for using an extension are:

1) We have API that allows users to define JS functions which will (when 
executed) return values back to SWT at the Java level. We accomplish by 
creating an extension, registering a function, and communicating with 
the main SWT Java process via DBus.

2) These functions need to be available all the time, meaning they need 
to be re-registered whenever a page is refreshed. This means listening 
to the "window-object-cleared" signal, and re-registering the JS 
functions on page refresh.

3) There is also API which allows an SWT client to execute JS 
synchronously which is a bit tricky as webkit_web_view_run_javascript() 
is async. My colleague who implemented WebKit in SWT managed to 
workaround this by using a web extension and DBus.

Anyway thank you for your help on such a vague kind of question, I'm 
going to investigate the matter further with the bug reporter.


Eric