wails
wails copied to clipboard
wailsapp
[v2, linux] custom AssetsHandler ignores HTML video's src on production
Description
I'm trying to serve local video files form a custom AssetsHandler.
From the dev server everything works fine, however on production the AssetsHandler "ignores" the requests from the HTML video's src tag. Images etc. are fine.
As far as I can see the implementation for dev and prod are quite different.
To Reproduce
- git clone [email protected]:Lyimmi/wails-video-example.git
- download https://test-videos.co.uk/vids/bigbuckbunny/webm/vp8/1080/Big_Buck_Bunny_1080_10s_5MB.webm
- In main.go line 22. change the path to the download folder!
- wails dev => see the video playing
- wails build -debug => run and see that the request for the video file is not present on the network tab
Expected behaviour
I expect that all asset calls are "routed" trough the assetsHandler if not found in embed.Fs.
Screenshots
dev
prod
Attempted Fixes
To be honest I'm a bit confused whit this one. But if some one can point me in a direction it would be great!
I tired to fish around for some info in v2/internal/frontend/assetserver/assetserver.go, but at this time I can only see that the video file request doesn't reach the (d *assetHandler) ServeHTTP function.
System Details
This is from a PopOS machine, but 22.04 Ubuntu behaves the same way with this issue.
System
------
OS: Pop!_OS
Version: 22.04
ID: pop
Go Version: go1.18.2
Platform: linux
Architecture: amd64
Wails
------
Version: v2.0.0-beta.38
Package Manager: apt
Dependency Package Name Status Version
---------- ------------ ------ -------
*docker docker.io Installed 20.10.14
gcc build-essential Installed 11.2.0
libgtk-3 libgtk-3-dev Installed 3.24.33-1ubuntu2
libwebkit libwebkit2gtk-4.0-dev Installed 2.36.3-0ubuntu0.22.04.1
npm npm Installed 8.8.0
*nsis nsis Installed v3.08-2
pkg-config pkg-config Installed 0.29.2
* - Optional Dependency
Diagnosis
---------
Your system is ready for Wails development!
Additional context
No response
Thanks for opening this issue.
Do you see something on the console tab, might some security setting have blocked the access? Does it work if you have the file in the embedded assets?
Even if the assetshandler internal implementation has a problem I would expect to see the request in the network tab.
There is nothing on the console. Edit: same result if I embed it. (Embedded another folder because Vite keeps deleting it.) But if I request an image from that folder it goes to the AssetsHandler just fine. :)
And if I log out the requestURIs from the serveHTTP, the video's request is missing.
2022/07/14 23:09:17 &{false}
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
2022/07/14 23:09:17 wails://wails/
2022/07/14 23:09:17 [AssetHandler] Loading file 'index.html'
2022/07/14 23:09:17 wails://wails/assets/index.ec80fd27.js
2022/07/14 23:09:17 [AssetHandler] Loading file 'assets/index.ec80fd27.js'
2022/07/14 23:09:17 wails://wails/assets/index.dbe33b87.css
2022/07/14 23:09:17 [AssetHandler] Loading file 'assets/index.dbe33b87.css'
2022/07/14 23:09:17 wails://wails/assets/nunito-v16-latin-regular.06f3af3f.woff2
2022/07/14 23:09:17 [AssetHandler] Loading file 'assets/nunito-v16-latin-regular.06f3af3f.woff2'
This might be unrelated but I saw a similar thing happen when I was writing the guide on AssetHandler. I thought it was because there was no extension on the file but that might have been a wrong assumption. I can try and reproduce and debug it tonight.
Thanks for testing the embedded case. If that also doesn't work it really seems like webkit doesn't call our handler for a video request on the custom scheme 'wails://'
There are some options for custom scheme registration, like registering it as local or as secure. Maybe that helps, but I'm currently away and can't do any further testing.
This might be unrelated but I saw a similar thing happen when I was writing the guide on AssetHandler. I thought it was because there was no extension on the file but that might have been a wrong assumption. I can try and reproduce and debug it tonight.
That could really be the known limitation if it happened when using 'wails dev' and vite.
NOTE: When used in combination with a Frontend DevServer there might be limitations, eg. Vite serves the index.html on every path, that does not contain a file extension.
No need to hurry, just thought I'd share it with you. Can work around it with a separate HTTP server from localhost like the dev server.
Seems like tauri has the same issue https://github.com/tauri-apps/tauri/issues/3725#issuecomment-1160842638
This is the upstream WebKitGTK bug report 146351.
There's also a link to a gist https://gist.github.com/ptomato/e180132d2313d07102d2 with a workaround by using javascript to load the video. This seemed to work in my tests, but I have no idea if streaming of large video works nicely without first loading the whole video.
Nice find 👍 If this works then I'll add it to the troubleshooting guide.
7yo bug 😱
7yo bug 😱
Yeah... If webkit wouldn't take a day to be build I would give it a try to fix it...
7yo bug 😱
Yeah... If webkit wouldn't take a day to be build I would give it a try to fix it...
I've got a pretty serious machine (Ryzen 9 16core Threadripper + 64G RAM). Perhaps I could try by booting from USB and compiling?
I've tested @stffabi's recommendation with comparison with net/http's http.ServeFile():
- The XMLHttpRequest style workaround works, but it loads the whole file into memory before starting. You can observe (on linux) that the webkit process uses about as much (+some extra) more memory than the file you are requesting.
- With net/http's http.ServeFile() style workaround, the webkit player uses range-requests to buffer ahead and as far as I can see, if the video is large enough occasionally frees memory as well.
So yeah, I think in the case of playing one small file the XMLHttpRequest request can be used, otherwise it won't be cheap. In my current case I'm going to stick to a localhost:port http.ServeFile() solution.
As usual, thanks for your help @stffabi & @leaanthony! ps: I used WEBM-s, other codecs may vary...
Let's hope the bug is fixed. If not, this is a great candidate for a plugin
Yeah, that's what I thought, suspected it will not stream the video with that workaround. Too bad because linux is currently the only platform where we would support streaming large requests with the AssetsHandler.
I currently see no sign this is fixed in WebKitGTK, bug is still open and current latest stable release has no fix.
I think the WebKit guys fixed this issue in WebKitGTK 2.36.5 This is the ticket for it: https://bugs.webkit.org/show_bug.cgi?id=242156
@Lyimmi just wanted to ask if you probably have tested WebKitGTK 2.36.5+ to see if everything works there? Would be great if we could close this issue.
@stffabi I tested the original example repo with WebKit version: 2.36.8 and unfortunately the example still behaves exactly the same way. Tested on Ubuntu 22.04. The request for the video file still does not reach the assetHandler.
To be sure I added the following to the v2/internal/frontend/desktop/linux/window.go:221, simply printing out the WebKit version.
printf("WebKit version: %d.%d.%d\n", webkit_get_major_version(), webkit_get_minor_version(), webkit_get_micro_version());
Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal
Webkit version: 2.36.8
WebKit wasn't able to find a WebVTT encoder. Subtitles handling will be degraded unless gst-plugins-bad is installed.
Long story short, still not good.
Too bad, hopefully they will fix that in an upcoming version. Thanks for taking your time to test it @Lyimmi
Tauri release v1.2.0
@zakaria-chahboun thanks for bringing this up. Maybe I'm overlooking something but I currently don't see how the headers would help in this case. It seem like in this case the request is never initiated by WebKit2GTK, there's no CORS warning or something shown in the console. Were you able to get this working with Tauri, if so do you probably know what headers they add?