Bug 280684
| Summary: | [Spiel] speech synthesis does not work with bubblewrap sandbox on | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | q66 <q66> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | bugs-noreply, eitan, mcatanzaro, philn, webkit-bug-importer |
| Priority: | P2 | ||
| Version: | WebKit Local Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
q66
Added in https://bugs.webkit.org/show_bug.cgi?id=270742.
The speech synthesis does not work because libspiel is unable to find any providers. This is because our xdg-dbus-proxy configuration does not allow the provider names to be seen in the filter. Unfortunately, we cannot wildcard them because xdg-dbus-proxy does not allow wildcarding prefixes. That clashes with how the speech provider names work; e.g. for espeak you have `org.espeak.Speech.Provider`, for something else you have `org.somethingelse.Speech.Provider` (the `.Speech.Provider` suffix is the same always). Since the dbus proxy does not filter them correctly, the `ListNames` and `ListActivatableNames` output does not include the provider (which libspiel checks for) and it goes undetected.
I was able to make it work specifically for espeak with this little patch:
```
--- a/Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp
+++ b/Source/WebKit/UIProcess/Launcher/glib/XDGDBusProxy.cpp
@@ -85,6 +85,10 @@ std::optional<CString> XDGDBusProxy::dbusSessionProxy(const char* baseDirectory,
if (allowPortals == AllowPortals::Yes)
m_args.append("--talk=org.freedesktop.portal.Desktop");
+#if USE(SPIEL)
+ m_args.append("--talk=org.espeak.Speech.Provider");
+#endif
+
if (!g_strcmp0(g_getenv("WEBKIT_ENABLE_DBUS_PROXY_LOGGING"), "1"))
m_args.append("--log");
```
This is, of course, not correct, as it does not match providers generically (otherwise i'd open a pull request). I'm not sure what the best way would be to match them generically. Thoughts?
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Eitan Isaacson
There are plans for a speech synthesis portal, but no work has started on that in earnest. Here is an open issue for that: https://github.com/project-spiel/libspiel/issues/19
q66
well, i'd say a portal is a bit orthogonal to this issue, since this is related to webkit-internal sandbox and webkit works fine in an env without portals (the portal is more relevant to a flatpaked environment...)
so we'll probably still want to let the unportaled provider to be seen from within the sandbox (just like everything else)
Patrick Griffis
The Speech Provider API seems fairly reasonable to expose - https://project-spiel.org/dbus_iface.html
My main concern is just that the host service isn't hardened/sandboxed itself and could be exploited.