Blocking via webRequest ignored for cached stylesheets
Categories
(WebExtensions :: Request Handling, defect, P3)
Tracking
(firefox86 affected, firefox87 affected, firefox88 affected)
People
(Reporter: thomas, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36
Steps to reproduce:
- Install attached extension.
- Open new tab and open Network panel in developer tools.
- Navigate to https://testpages.adblockplus.org/en/filters/stylesheet.
- Disable extension.
- Reload test page.
- Enable extension.
- Reload test page.
Actual results:
After 3) Request for stylesheet.css is blocked and red box with message "Failed. Stylesheet was NOT blocked." is not shown on the page.
After 5) No request for stylesheet.css is blocked and red box with message "Failed. Stylesheet was NOT blocked." is shown on the page.
After 7) Request for stylesheet.css is blocked and red box with message "Failed. Stylesheet was NOT blocked." is shown on the page.
This behavior has been observed on Firefox 79.0 and 87.0b2. It does not appear on Firefox 78.8.0esr, so this regression may have been introduced by https://bugzilla.mozilla.org/show_bug.cgi?id=1599160.
Clearing the cache using F5
or CTRL+F5
has no effect (unlike what's mentioned in https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/79#css). However, clearing the cache via the browser settings does have an effect.
Expected results:
After 3) Request for stylesheet.css is blocked and red box with message "Failed. Stylesheet was NOT blocked." is not shown on the page.
After 5) No request for stylesheet.css is blocked and red box with message "Failed. Stylesheet was NOT blocked." is shown on the page.
After 7) Request for stylesheet.css is blocked and red box with message "Failed. Stylesheet was NOT blocked." is not shown on the page.
This bug was first reported at https://gitlab.com/eyeo/adblockplus/abpui/adblockplusui/-/issues/930.
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'WebExtensions::Request Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 3•4 years ago
|
||
Hello,
I’ve managed to reproduce the issue on the latest Nightly (88.0a1/20210228215216), Beta (87.0b4/20210228185859) and Release (86.0/20210222142601) under Windows 10 x64 and Ubuntu 16.04 LTS, using the provided extension, however with a slight difference from the actual results form the description.
After performing steps 6 and 7, there are no blocked requests for stylesheet.css in the Network panel, but the "Failed. Stylesheet was NOT blocked." message is shown on the page. (see the attached screenshot).
This does confirm the issue, as the add-on is enabled, but stylesheet.css requests appear to not be blocked.
Clearing the cache via the browser settings also appears to fix the problem, as mentioned.
Comment 4•4 years ago
|
||
Updated•4 years ago
|
After performing steps 6 and 7, there are no blocked requests for stylesheet.css in the Network panel, but the "Failed. Stylesheet was NOT blocked." message is shown on the page. (see the attached screenshot).
Whether the requesti is shown as blocked in the developer tools indeed doesn't appear to be consistent across versions. In Firefox 79 and 80 I was able to see them marked as "cached", as shown in the screenshot. However, in Firefox 87.0b4 it is shown as being blocked by the example extension.
Comment 7•4 years ago
|
||
Alex, can you verify this bug without the extension? Specifically, the comment:
"Clearing the cache using F5 or CTRL+F5 has no effect (unlike what's mentioned in https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/79#css). However, clearing the cache via the browser settings does have an effect."
Using the browser toolbox and watching the network tab: A full reload should re-fetch the stylesheets, and at least on OSX I see them reloaded with cmd+shift+r, but there are no network entries for the css files with a simple reload (cmd+r). If you are able to reproduce this on windows or linux, file a regression against bug 1599160.
For this bug, unfortunately the likely end result will be adding documentation for the behavior. The css cache added in bug 1599160 entirely bypasses the network layer, so webrequest will never see those requests. I'll leave this open for further discussion in our next triage.
Comment 8•4 years ago
|
||
Thomas, when the new stylesheet cache is hit, there is never a http request. If in the first request, it is blocked, it will be re-requested. IIUC this is also per-process, so a request would be seen within each process. Rather than try to force those requests through somehow (unreleastic) it may be better to consider some alternative api or mechanism for ad blockers. Maybe by clearing the stylesheet cache when one is installed/enabled providing a way to see at least the initial request. If you have any thoughts on that let us know.
Comment 9•4 years ago
|
||
Re-tested without the extension on the latest Nightly (88.0a1/20210301220015) and Release (86.0/20210222142601) on Windows 10 x64.
I’ve done the following:
- Load the test page and monitor the network tab
- Perform a page reload using F5, CTRL+R, CTRL+F5 and CTRL+SHIFT+R and monitor the network tab
NOTE: After each reload, I cleared the cache via the browser settings, loaded the test page again and proceeded with another reload.
These are the results:
-
F5: stylesheet is NOT re-fetched and appears cached
-
CTRL+R: stylesheet is NOT re-fetched
-
CTRL+F5: stylesheet IS re-fetched
-
CTRL+SHIFT+R: stylesheet IS re-fetched
For further details, see the attached screenshot.
Simply using F5 does not have the desired effect, but CTRL+F5 (or CTRL+SHIFT+R) does - as mentioned on https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/79#css.
This invalidates the initial claim that “Clearing the cache using F5 or CTRL+F5 has no effect”.
Comment 10•4 years ago
|
||
Updated•4 years ago
|
Comment 11•4 years ago
|
||
I don't think there is anything we can do other than implement bug 1657575
Description
•