After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755280 - GNOME Web "leaks" (cache?) video files.
GNOME Web "leaks" (cache?) video files.
Status: RESOLVED NOTGNOME
Product: epiphany
Classification: Core
Component: Backend
3.17.x
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-19 23:43 UTC by Diogo Campos
Modified: 2015-09-21 13:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Diogo Campos 2015-09-19 23:43:19 UTC
GNOME Web (and/or WebKit) creates a video file for some reason (caching probably) in "~/.cache/" (instead of in "~/.cache/epiphany/") and doesn't get rid of it even when asked.

# Versions:

GNOME Web 3.17.91
WebKitGTK 2.9.92
Fedora 23

# Steps to reproduce:

1- Play some HTML5 video (reproduced with this one: https://upload.wikimedia.org/wikipedia/commons/a/ae/2TE116-1040_departure_from_Krustpils_to_Daugavpils.webm ).

2- Watch "~/.cache/" being populated with a video file, named "WebKitWebProcess-SOMETHING".

3- Close the tab playing the video.

4- Clear cache through GNOME Web.

5- Check that the video file wasn't deleted.
Comment 1 Michael Catanzaro 2015-09-20 15:13:12 UTC
Diogo, if you have a WebKit Bugzilla account, could you report this there?

Philippe, any ideas about this? I found three such leaked videos on my computer.
Comment 2 Philippe Normand 2015-09-20 15:24:14 UTC
It's GStreamer's playbin on-disk buffering I think. Not sure yet what's going on there, those files should be temporary and be removed when the GStreamer pipeline is disposed I think.
Comment 3 Michael Catanzaro 2015-09-20 16:24:16 UTC
I bet they're leaked if the web process crashes. That seems to happen rather a lot when playing videos, unfortunately.
Comment 4 Sebastian Dröge (slomo) 2015-09-21 09:20:42 UTC
Yes when the process crashes there's not much we could do to remove these files :) You should probably also tell playbin/queue2/downloadbuffer to place these files into your application cache directory instead of ~/.cache directly.
Comment 5 Claudio Saavedra 2015-09-21 12:24:20 UTC
We need to either do some house-keeping from time to time or use /tmp. We can't just leak videos like that.
Comment 6 Sebastian Dröge (slomo) 2015-09-21 12:26:54 UTC
If you store it in ~/.cache/epiphany, it would be cleaned automatically based on the cache size limit of epiphany, right?
Comment 7 Michael Catanzaro 2015-09-21 12:44:45 UTC
(In reply to Sebastian Dröge (slomo) from comment #6)
> If you store it in ~/.cache/epiphany, it would be cleaned automatically
> based on the cache size limit of epiphany, right?

Carlos would know.

Historical answers: until recently the answer was no, there would just be a huge cache leak. Since libsoup 2.50, Carlos fixed the soup cache to delete everything it doesn't recognize. Now WebKitGTK+ 2.10 with the network process (Epiphany 3.18 now uses the network process always) uses WebKit's new cache ~/.cache/epiphany/WebKitCache instead of the soup cache ~/.cache/epiphany/webkit. The new cache tracks what origin each cached item is from, so the cache can be cleared on a per-origin basis. I am not sure it will ever clear items that it didn't cache itself.
Comment 8 Michael Catanzaro 2015-09-21 12:48:44 UTC
It's easy for Epiphany to delete everything cached outside of ~/.cache/epiphany/WebKitCache when it starts. But, the problem here is really in WebKit. It wouldn't really be nice for WebKit to stomp on the application's entire cache. Also, WebKit doesn't seem to be cleaning up the old soup cache, so that entire cache will be leaked if you upgrade from older WebKit. But this is an unrelated problem.
Comment 9 Philippe Normand 2015-09-21 12:56:04 UTC
I agree this is a WebKit bug, see https://bugs.webkit.org/show_bug.cgi?id=119477