"Ghost" files are downloaded when browsing

Hello. Is there a way to reset a GNOME Web (Epiphany) installation?

I tried deleting the contents of the following directories, but I still have the issue described below. I also checked the integrity of the files in the installation paths with my distribution tools.

~/.cache/epiphany
~/.config/epiphany
~/.local/share/epiphany

I have a misconfigured installation that spontaneously downloads empty zero-length files into the Downloads directory. No such downloads should happen when browsing.

I can reproduce this issue if I go to a specific URL on this installation of GNOME Web. Below is an example URL which opens an article in the Ukrainian version of Forbes magazine. I cannot reproduce this issue in a different installation, only in this one.

https://forbes.ua/money/zapasi-izhi-vdoma-strakh-magaziniv-yak-zminilisya-spozhivatski-nastroi-ukraintsiv-pislya-povnomasshtabnogo-vtorgnennya-golovne-z-doslidzhennya-deloitte-30032023-12724

In this case, the browser loads the page and then downloads seven files. Each file is named tt. Duplicate files get a number in the bracers, like tt(6). (The latter is a normal behaviour preventing the newly downloaded file from overriding the previously downloaded file.) If I reload, a new batch of files is downloaded.

Over the last month, the browser downloaded files with the following names:

1
9534
AdDisplayTrackerServlet
bridge
c
cookiesyncendpoint
log
manage
no_match_opted_out
ps
setuid
tags
tt
v1

Does it ring a bell of what might be wrong?

$ epiphany --version
Web 42.4
$ gnome-shell --version
GNOME Shell 42.4

It uses webkitgtk@2.40.5.

Since you’re using system Epiphany and not a Flatpak, these are the only directories you need to clear. Everything is stored in those three places.

Guess: you’ve installed some custom MIME type configuration, and now these resources are being detected as content types not supported by WebKit? Got anything suspicious under ~/.local/share/mime?

1 Like

It looks like the “Block Advertisements” feature blocks the relevant part of the code in the example webpage. Clearing the directories did not reset the option because it is stored in dconf. I have it disabled while it is enabled by default. To reproduce the issue in a fresh install of the distribution, I had to turn the feature off in the settings.

$ gsettings get org.gnome.Epiphany.web:/org/gnome/epiphany/web/ enable-adblock
false

Now that I can reproduce it, I will report the bug to the distribution maintainers. I can reproduce it in GNOME Web in Guix, but not in a different browser or a different distribution. I also suspect that I should be able to encounter a different webpage that would be producing those empty files while the “Block Advertisements” feature is enabled.

I do not have a mime directory at ~/.local/share/, but I do not know whether it rules out a MIME content-type problem. However, your suggestion made me look into the code of the webpage, network requests, and eventually, the content-blocking settings. So, thank you for the help!

OK, there’s nothing wrong with your MIME data then. I was just guessing.

Wait, why would you do that? The Guix maintainers don’t know how to handle Epiphany bug reports. You want to report bugs upstream as far as possible so you find the humans who can actually fix them. Normally that would be the Epiphany or WebKit issue tracker, but in this case, the adblock filters are maintained by EasyList and their issue tracker is here.

You also want to try to find the particular rule that is causing the breakage by “bisecting” the filters list, which is here. This makes it much more likely that the EasyList developers will fix the problem. To do this, you want to download those filters to your home directory, then configure Epiphany to use them, something like this:

$ gsettings set org.gnome.Epiphany content-filters ['file:///home/mcatanzaro/easylist_min_content_blocker.json']

Then close Epiphany, remove half the filters, restart Epiphany and see if the bug occurs. If not, put back that half and remove the other half. Repeat, removing half the remaining filters in every step, until you eventually find the filter causing the problem.

Only problem is, the syntax for that gsettings command is wrong and I cannot figure out how to correct it. What really happens is actually this:

$ gsettings set org.gnome.Epiphany content-filters ['file:///home/mcatanzaro/easylist_min_content_blocker.json']
unknown keyword:
  [file:///home/mcatanzaro/easylist_min_content_blocker.json]
   ^^^^

The expected value is an array of strings, e.g. the default value is ['https://easylist-downloads.adblockplus.org/easylist_min_content_blocker.json'] so I’m surprised this syntax isn’t accepted. Not sure how to proceed. This really would significantly increase the odds of the EasyList developers fixing the bug, so we should try to figure it out.

Adrian found the solution:

$ gsettings set org.gnome.Epiphany content-filters "['file:///home/mcatanzaro/easylist_min_content_blocker.json']"

(Obviously you want to use your own home directory rather than mine.)

Sorry, I realized that I was unclear in my previous post. The test page downloads empty files only when the ad blocker is off. It was off on my computer and stayed off despite me clearing the directories. It is on by default on a freshly installed system. The test page is filtered and provides no empty files until I turn the ad blocker off.

Here is a table to visualize the test results, where “OK” means that the browser behaves as expected.

╒════════╤═══════════════╕
│        │ Block         │
│        │ Advertisements│
│        ┼──────┼────────┤
│        │ On   │ Off    │
╞════════╪══════╪════════╡
│ Guix   │ OK   │ Empty  │
│        │      │ files  │
├────────┼──────┼────────┤
│ Debian │ OK   │ OK     │
├────────┼──────┼────────┤
│ Fedora │ OK   │ OK     │
╘════════╧══════╧════════╛

I conclude that the ad blocker is not the cause of the problem. I do not know what the problem is. It appears specific to Guix. I guess it was a packaging mistake or some version inconsistency.

OK then, I think it’s MIME type related after all. It reminds me of this bug from last year. It’s fixed in libsoup 3.4; your libsoup is probably too old. Try updating that if possible.

Your WebKitGTK is new enough to have the fix for this issue (although you’re several months behind on security updates, which is inadvisable). And although the comment there also implies that you need an updated version of Epiphany as well, the change that landed there got reverted, so I don’t think Epiphany version matters. (Still, your Epiphany 42 is pretty old and using something newer would be advisable.)

1 Like

Sorry, I got confused. This was wrong. You also need this commit which is present in 44.0 and newer.

So, there you have it.

Guix currently has libsoup 3.1.4. I reproduced the issues described in the linked WebKit bug report. Luckily, a patch to update libsoup to 3.4.4 appeared on the Guix issue tracker a day before yesterday. I applied the patch and rebuilt Epiphany against that version. There are no unexpected downloads anymore.

Updating libsoup seems to be enough to stop unexpected downloads. Hopefully, Guix will get an updated Epiphany soon. A patch to update it to 44.7 appeared less than two weeks ago.

Thank you for your suggestions!

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.