[Webkit-unassigned] [Bug 214811] [GTK] Web process crash during user media permission request calling gst_v4l2_open()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=214811

--- Comment #4 from Víctor M. Jáquez L. <vjaquez at igalia.com> ---
(In reply to Michael Catanzaro from comment #3)
> Well it's definitely a bug. Even if there's no permission to access
> /dev/video1, WebKit shouldn't crash. That's happening because of this
> critical: assertion 'GST_IS_ELEMENT (element)' failed. So that's the first
> issue to fix.

Did you compile WebKit with Flatpak?

If so, I guess I get why it is happening: We need to compile gstv4l2 without udev support, because flatpak can't handle it, and gstv4l2 fallbacks to traversing a hard-coded list of possible devices, where probing is opening try-and-error.

Then this probing is done without an element associated, raising the precondition check.

> 
> Now, as to why the permission error is occurring... I think you were correct
> to guess a sandbox problem. I would actually never have thought of that, but
> that must be it. There's actually sandbox rule to bind /dev/video1 in
> bindV4l in BubblewrapLauncher.cpp. But it can only be bound if it already
> exists at the time the web process is launched! Testing now, /dev/video0 and
> /dev/video1 are only created when I actually plug in my webcam, which I
> usually do long after the web process is already running. The sandbox will
> never be able to allow access to files that don't already exist at the time
> the web process is launched, so using /dev/video0 and /dev/video1 from the
> web process cannot be made to work. I'm pretty sure pipewire is designed to
> avoid this problem, right? (We're going to need to hook up to pipewire to
> make desktop sharing work anyway. Maybe we should have a separate bug for
> pipewire integration?)

AFAIK, pipewire takes care of the available devices, so yes. But -- again, afaik -- we need to upgrade pipewire to work in flatpak

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200806/6427924d/attachment.htm>