AdguardTeam
Content script is not injected if website has specific meta tag and then is loaded from cache and Bitwarden extension is installed
Please answer the following questions for yourself before submitting an issue
- [X] Filters were updated before reproducing an issue
- [X] I checked the knowledge base and found no answer
- [X] I checked to make sure that this issue has not already been filed
AdGuard version
7.19.0 nightly 1 (4800) (CL 1.16.19, DL 2.5.41 )
Browser version
Chrome 128
OS version
Windows 11
Issue Details
Steps to reproduce:
- Install Chrome and Bitwarden extension - https://chromewebstore.google.com/detail/bitwarden-password-manage/nngceckbapebfimnlniiiahkandclblb
- Allow it to use in incognito window
- Add these rules to user rules:
||adguard.com^$replace=/<meta charset="utf-8">/<meta charset="utf-8">\n<link rel="profile" href="https:\/\/adguard.com">\n<link rel="icon" href="\n">\n/
adguard.com##.main
- Open incognito window
- Go to - https://adguard.com/en/welcome.html
- Click on the "Blog" link
- Click on the "Back" button
Expected Behavior
After navigating back, element hiding rules should be applied.
Actual Behavior
When website is loaded from the cache then in specific cases content script is not injected and element hiding rules do not work.
Screenshots
Video
https://github.com/user-attachments/assets/8d2e3ab5-37d9-4bd9-a331-67070c96f4a5
Additional Information
I'm not sure if it's CoreLibs bug or just some kind of incompatibility between Bitwarden and AdGuard app.
@AdamWr Hi! I've found that
||adguard.com^$replace=/<meta charset="utf-8">/<meta charset="utf-8">\n<link rel="icon" href="\n">/
||adguard.com^$replace=/Surf/Shmurf/
is enough to reproduce and illustrate the issue more clearly. It looks like Chrome fetches the "icon" as an image, using the URL of the original document:
23.01.2025 16:44:33.943764 DEBUG [20428] AGHttpProcessingUnit sendRequest: [id=1000004-h2-ssl-5] Processed request: GET /en/welcome.html HTTP/2.0
Host: adguard.com
...
accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
...
sec-fetch-dest: image
...
, caches the result, and then loads it from cache instead of the actual HTML document. Because of sec-fetch-dest: image, AdGuard detects the request type as "image", disabling injections and $replace rules. This way the cache is being "poisoned" by an unfiltered page.
The use of sec-fetch-dest: image request's result as a document only occurs when Bitwarden extension is enabled, so it could be that the extension is triggering a bug in Chrome. Could you try reporting this issue to Chrome and Bitwarden?
For a reproducer it would be better to create a clean website that demonstrates the issue (github pages?).
The bug is not related to AdGuard so mentioning it in the bug report will only complicate things.
I tried to create simple test page but I cannot reproduce this issue as constantly as on adguard.com.
Maybe something more should be added to the test page to make this issue more reproducible.
And on the test page it occurs even without any other extension, though I'm not sure if it's not a different issue and it occurs rather randomly.
Link - https://adamwr.github.io/test-page/cache.html
Rule to test:
adamwr.github.io###cache
There is h1 element with Test cache text which should be hidden.
Video:
https://github.com/user-attachments/assets/9f658588-123f-4437-9e75-3f35540029b2
If I'm looking at the correct log then it's probably the same issue.
VERBOSE, AdguardSvc.exe, Logger, 39, 23.01.2025 17:48:42.964, AGHttpProcessingUnit sendRequest: [id=1001964-h2-ssl-7] Processed request: GET /test-page/cache.html HTTP/2.0
Host: adamwr.github.io
pragma: no-cache
cache-control: no-cache
sec-ch-ua-platform: "Windows"
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
sec-ch-ua: "Not A(Brand";v="8", "Chromium";v="132", "Google Chrome";v="132"
sec-ch-ua-mobile: ?0
accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
sec-fetch-site: same-origin
sec-fetch-mode: no-cors
sec-fetch-dest: image
referer: https://adamwr.github.io/test-page/cache.html
Reported - https://issues.chromium.org/issues/391899125
Please let me know if I described something incorrectly or if there should be additional information added, or just add a comment there :)
For a reproducer it would be better to create a clean website that demonstrates the issue (github pages?).
The bug is not related to AdGuard so mentioning it in the bug report will only complicate things.
It's not easy to demonstrate the issue without AdGuard -- need a server that serves different resources for the same URL depending on the value of the sec-fetch-dest header.
It has been marked as Won't fix (Intended behavior).
By the way, it's not only Chrome, the same happens in Firefox.
Same happen for https://www.tokfm.pl/Tokfm/0,0.html Record: https://streamable.com/wl6fxx I have Adguard for Windows (stable), Chrome Stable and Bitwarden too.
