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
Hmm, not a lot changed between 2.29.91 and 2.29.92. Maybe r266389...?
(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.
Let's continue on Epiphany bugtracker for now.
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.
*** Bug 216535 has been marked as a duplicate of this bug. ***
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).
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.
(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.
(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.
(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.
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.
Created attachment 408916 [details] Patch
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!
Also, this could happen with the WPE port as well (maybe others?).
(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.
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!
Committed r267226: <https://trac.webkit.org/changeset/267226>