Bug 216430 – [GTK][WPE] Epiphany does not make connections in Incognito Mode after clearing .cache

• Component: WebKitGTK
• Status: RESOLVED FIXED

Created attachment 408585 [details]
Screencast

After clearing ~/.cache, Epiphany does not connect to any site when in Incognito Mode. Checking the .cache/epiphany/adblock shows, that in Incognito, Epiphany does not download and compile the adblock list. To restore connectivity user must start in regular mode (in regular mode Epiphany downloads and compiles the adblock list), after which user can switch to Incognito mode and browse normally. Incognito Mode seems to work as long as the adblock list in .cache/epiphany/adblock is not cleared.


Epiphany 3.37.91, Fedora 33, first noticed with WebKitGTK 2.29.92, issue persists in WebKitGTK 2.30.0. Downgrading to WebKitGTK 2.29.91 solves the issue: adblock list is downloaded at launch and connections work.



Downstream bug report: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1331

[Michael Catanzaro]

Hmm, not a lot changed between 2.29.91 and 2.29.92. Maybe r266389...?

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #1)
> Maybe r266389...?

Yup, that's it. But that commit looks like an important fix that probably should not be reverted.

I have not investigated further yet, but my guess is the adblocker is unable to download adblock filters because it's blocked waiting for itself to download adblock filters. Nothing is allowed to be downloaded until the filters are ready.

[Michael Catanzaro]

Let's continue on Epiphany bugtracker for now.

[Michael Catanzaro]

Reopening. I did a little more investigation, but can't find anything wrong from the Epiphany side of things. There is only one WebKitPolicyDecision involved, a navigation policy decision for ephy-about:incognito. Epiphany correctly delays that until the adblock filters are ready. There's no policy decision for the download (probably because it's started by an API request). The download just never completes. I'm not sure why, but I don't think Epiphany is responsible for this. Switching ephy_download_new_for_uri_internal() to use the default web context avoids this bug, but we shouldn't do that.

[Michael Catanzaro]

*** Bug 216535 has been marked as a duplicate of this bug. ***

[Carlos Garcia Campos]

I missed this bug because it was not in WebKitGTK component not webkitgtk was added to the CC. I'll check what's going on, but I ideally ephy shouldn't write anything to disk in ephemeral sessions, so adblock would only work in the rules are already there, the same way it happens with the disk cache, for example. If we want to make the adblock work in ephemeral sessions, maybe we need to add a way to download and compile the rules without writing to disk (I'm not sure that's even possible).

[Michael Catanzaro]

Oops. :) Thanks.

I think it's OK to write the adblock filters to disk because they're the same for every user; they do not contain any website data. That's why they're shared by storing them in the default cache directory instead of using the WebKitWebsiteDataManager's cache directory. There's no point in trying to avoid writing them; it would only slow down the browser for users who set the browser to always start in incognito mode, since then you'd need to wait for them to download each time you launch the browser.

[Adrian Perez]

(In reply to Carlos Garcia Campos from comment #6)
> I missed this bug because it was not in WebKitGTK component not webkitgtk
> was added to the CC. I'll check what's going on, but I ideally ephy
> shouldn't write anything to disk in ephemeral sessions, so adblock would
> only work in the rules are already there, the same way it happens with the
> disk cache, for example. If we want to make the adblock work in ephemeral
> sessions, maybe we need to add a way to download and compile the rules
> without writing to disk (I'm not sure that's even possible).

We need a file system location for WebKitUserContentFilterStore, and
there is no way around it because the files will be mmap'd and file
descriptor handles passed across processes over IPC. The only option
to handle filters in an ephemeral way would be to use some location
under “/tmp” — and I think it should be the responsibility of the
application to decide whether to do that or not.

[Michael Catanzaro]

(In reply to Adrian Perez from comment #8) 
> We need a file system location for WebKitUserContentFilterStore

Anyway, it shouldn't be a problem because ephy_filters_manager_constructed() ensures it uses the default cache dir rather than relying on the WebsiteDataManager. I'm not sure why the download doesn't complete.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #7)
> Oops. :) Thanks.
> 
> I think it's OK to write the adblock filters to disk because they're the
> same for every user; they do not contain any website data. That's why
> they're shared by storing them in the default cache directory instead of
> using the WebKitWebsiteDataManager's cache directory. There's no point in
> trying to avoid writing them; it would only slow down the browser for users
> who set the browser to always start in incognito mode, since then you'd need
> to wait for them to download each time you launch the browser.

I agree with Michael here: The bytecode in filters depends only on the input
JSON rules, which do not contain any user/website specific data. Epiphany
adds sidecar files (a serialized GVariant) with some metadata which also
does not contain any user/website specific data.

[Carlos Garcia Campos]

The problem is that when using an ephemeral context, the download is started before the ephemeral session has been registered in the network process, so it's just ignored.

[Carlos Garcia Campos]

Created attachment 408916 [details]
Patch

[Adrian Perez]

Comment on attachment 408916 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=408916&action=review

> Source/WebKit/UIProcess/WebProcessPool.cpp:1677
> +    return ensureNetworkProcess(&dataStore).createDownloadProxy(dataStore, request, frameInfo, originatingPage);

Wow, the subtlety!

[Adrian Perez]

Also, this could happen with the WPE port as well (maybe others?).

[Alberto Garcia]

(In reply to Carlos Garcia Campos from comment #12)
> Created attachment 408916 [details]
> Patch

I confirm that this patch fixes the problem. I'm using Epiphany 3.32.1.2 in Debian buster.

[Michael Catanzaro]

Comment on attachment 408916 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=408916&action=review

Nice test.

>> Source/WebKit/UIProcess/WebProcessPool.cpp:1677
>> +    return ensureNetworkProcess(&dataStore).createDownloadProxy(dataStore, request, frameInfo, originatingPage);
> 
> Wow, the subtlety!

Wow indeed.

Excellent, thank you for everyone involved!

[Carlos Garcia Campos]

Committed r267226: <https://trac.webkit.org/changeset/267226>