-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve representation of behind-the-scene network requests in the logger #3654
Comments
Works fine here. Use the logger to investigate such filter issues. |
Ah, I see. I never had What is the intended behaviour here? Is it possible that now other "background requests" are blocked as well? OCSP, FF version checks and so on (whatever this browser does "blindly")? |
Provide exact repro steps please if you want me to answer meaningfully. |
Also, keep in mind that if you are using advanced user mode and on top of this a block rule such as |
The log tells me that uBO is blocking the request. But it did not block the request in an earlier version using exact same settings and filters. This issue is about this undocumented behaviour change and whether it was intended. Steps to reproduce:
|
You forgot to tell whether |
|
I can reproduce. This is a change in behavior from the fix to #3546. You are dealing with a filterable behind-the-scene network request. The solution is to manually add a rule to override your global block rule: The request is categorized as a behind-the-scene one, because uBO is not provided the information from which tab it originates. However, uBO is provided the context in which the network request was made, as you can see from the logger (above): "from Solution, create a noop rule, however granular you wish it to be. Example: Or you could manually add These filterable behind-the-scene network requests can be filtered because Firefox API provide the needed information to do so, and hence are bypassing the Question: did you have |
I am going to provide a different icon from the behind-the-scene one in the logger so that there is no confusion. |
Thanks for explaining this. No, I did not have blog.fefe.de whitelisted in any way, as stated above already. That's why the issue came up - the feeds were working even though everything was blocked and suddenly they stopped working with some version update without me doing any settings or whitelist changes. I explicitly added the feed domains to my rules now, they are working again. |
This may also happen with static filtering. I can reproduce issue from comment in above reddit post using |
Best is to find out what exactly is blocking |
Turned out this was uMatrix https://old.reddit.com/r/uBlockOrigin/comments/8lqvbn/chrome_extention_google_dictionary_not_working_if/e37a0pw/ |
Alignment of the "type" column was changed here. Can you revert it? Or use "center"? Every time I want this information it somehow hides from me. It somehow merges visually with the URL. |
Feedback in related issue: - #3654 (comment)
Describe the issue
With one of the latest uBO Versions (can't exactly tell which one, somewhen in the 1.15.* line) aome Atom/RSS feeds stopped working. Disabling uBO makes them work again.
An example feed is https://blog.fefe.de/rss.xml - I can still add it perfectly fine to Firefox, the browser asks me if I want to add this live bookmark and this works. But when I try to open it in the bookmakrs menu I only get the message that the live bookmark could not be loaded. Disabling uBO + Browser restart makes it work again.
Some feeds are working normally however, like https://www.heise.de/newsticker/heise-atom.xml.
One or more specific URLs where the issue occurs
Does not work: https://blog.fefe.de/rss.xml
Does work: https://www.heise.de/newsticker/heise-atom.xml
Steps for anyone to reproduce the issue
Your settings
uBO is set to "everything globally denied" (top left column red button for all resources), sites are whitelisted on a per domain basis (right column domain-sepcific grey buttons)
Your filter lists
All, except "uBlock filters – Experimental", "Fanboy’s Anti-Thirdparty Social (see warning inside list)" and "JPN".
The text was updated successfully, but these errors were encountered: