JBildstein
Cannot load video elements as embedded resources or from local file system on Linux
Before I start complaining, thank you for writing SpiderEye, you've saved me a bunch of work so far!
Describe the bug Unable to load video elements that are embedded resources on Linux.
To Reproduce Steps to reproduce the behavior:
- Add index.html (that contains a video element with a local src to a mp4 file) to SpiderEye.Core.App
<video class="video" autoplay muted loop style="z-index: 1;">
<source src="background.mp4" type="video/mp4">
</video>
- Add the background.mp4 referenced in index.html to SpiderEye.Core.App
- Run the app and observe the video does not play
Expected behavior Local references to multimedia content should play normally just like content from remote uris do.
Environment:
- OS: Linux
- SpiderEye Version: 1.0
Debugging output from gstreamer:
0:00:00.339282760 5020 0x565438c3db60 INFO webkitglvideosink GLVideoSinkGStreamer.cpp:118:webKitGLVideoSinkConstructed:
It would appear that the spidereye:// "protocol" is unknown to gstreamer, no surprise there. So I implemented my own LocalFileContentProvider to pull the content directly from the local filesystem, and it seems to work fine. The files are found (confirmed in the debugger) but at some point after that the spidereye:// prefix is being added to the uri. I can't seem to override the Uri.Scheme to tell it it's not an embedded resource either. Perhaps I'm looking at the problem wrong.
I can send you a pull request of what I have so far for the LocalFileContentProvider, but there's nothing insightful in it. :)
Thanks!
Digging through the Linux specific code looking for an entry point for making mods to allow the loading of content from the local file system (and staying within your architectural framework) I came across these two lines:
https://github.com/JBildstein/SpiderEye/blob/13a58151b169ec835b18fbc631feb5b889e64229/Source/SpiderEye.Linux/GtkWebview.cs#L83-L84
const string scheme = "spidereye";
customHost = new Uri(UriTools.GetRandomResourceUrl(scheme));
This seems to be the source of the hard coded spidereye scheme in the Uri I can't override... can you give some background on lines 83-84 and the need for a random uri generator?
Thanks.
I'm glad you like it and also thank you for thorough bug reports like this, they can only make SpiderEye better :)
The main problem seems to be that the media player/gstreamer circumvents the usual browser loading and attempts to do load stuff by itself.
Spiderye registers the spidereye protocol with webkit and handles any requests via the content provider which can load files from wherever (as you have done with the file provider).
The spidereye prefix is added because that's the URL the site was loaded from. If you request e.g. /index.hml to be loaded then SpiderEye goes ahead and opens spidereye://randomurl/index.html in the webview. Then any relative URLs on that page will also be loaded by the same root and can be handled by SpiderEye.
Same thing if you open https://foo.bar in a browser, any link/resource with a relative URL will be loaded from https://foo.bar/relativeLink
The reason for the random URL is security. If I'd always use the same URL and a malicious site knowing that would be loaded in the webview, it could request resources only meant for the app. Sure, it's not a huge risk but it's easily prevented and has no downside as far as I can see.
Anyway, back to the bug: From the looks of it, gstreamer needs its own protocol handler which probably can be done with this API: https://gstreamer.freedesktop.org/documentation/gstreamer/gsturihandler.html?gi-language=c
I'll have to look into it further on how to actually use and implement that though.
