-
Notifications
You must be signed in to change notification settings - Fork 77
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
Combining procedural selector :has() and :style() #382
Comments
Put back the template and fill it if you want to file a bug. |
I reopen because I am aware of this, this is a TODO. Many AdGuard filters are discarded because of this. Repro steps:
Result: the output of the logger will show many such cosmetic filters being rejected. |
Apologies for not properly using the template, I wasn't really sure whether its a bug report or I'm simply missing something. Posting this to /r/uBlockOrigin as a question first would probably be a better way to go at this. Sorry! I'm not sure whether uBlockOrigin cares about enabling non-ad-blocking use-cases, but FWIW, what I was trying to do is reduce the visibility of facebook posts that contain a certain hashtag:
|
As for me, it's a bit of a strained example, you can do something like this with ViolentMonkey / GreasyMonkey / TamperMonkey also. |
Has If it is at all feasible, implementing this would be useful. A common need arises in unsticking headers (very helpful for mobile browsing). If I can find the correct DOM node with the element selector, often the selector is one that seems likely either to not apply on other pages of the site or to not last very long (i.e., small site changes likely to break the selector). Typically, I can create a procedural selector with either:
Thanks for everyone's work on uBlock Origin! |
Not that I've found. See gorhill's first comment on it that I could find - gorhill/uBlock#781 (comment) I would also find this useful (and have a real use case I would use this on as well) |
Found this old request and want to express my interest as well for having this feature. It's harder to make rules as element name randomizing has become more popular. |
I got this working locally. If you don't mind I'll open a PR later tonight. No expectation, of course. I saw that you occasionally accept PRs, but this might be a slightly larger change than you ordinarily accept, and I don't know enough about the performance implications to know whether there would be an issue. |
As long as you have permissions to send PR, the author prefers to take care of the quality of the code, and you will probably be able to see your version with a lot of patches. |
The reason why this is not fixed yet is not to implement supporting Now that said, @nuchi if you have something that work, let me inspect the code change in your repo -- I couldn't find any uBO repo in your GitHub page. |
Thanks! All those details are great to hear about. I took care of excluding the element picker from being styled, because the code for that was right next to the code I was touching, but the other things you mentioned are things I didn't know about. (And am happy to work on, now that you've brought them to my attention, if it makes it easier to accept a contribution.) I just pushed my changes. |
I just pushed three changes:
You can see those three changes in the three commits in the link above. I hope this might make it easier to accept my contribution, though as before, no expectation. |
Is there any news on this? This feature would be insanely helpful. Also, ideally this will be moot, but its very confusing that such rules currently silently fail, and the fact that they're not compatible is buried in the wiki. This just drove me crazy thinking my CSS or syntax was off. |
Related issue: - uBlockOrigin/uBlock-issues#382 Additionally, remnant code for pseudo-user stylesheets has been removed. Related commit: - 5c68867
@nuchi I appreciate your efforts to solve the issue here but this is something I had to go through myself. The reason is that when I have to fix such core feature, I think long before I write any code about what would be the best approach to fix the issue, and most of the time this involves some level of needed refactoring -- which was the case here. |
This works:
But these are not:
Though these works:
Well, now I think my case is a I've opened #1240 |
It looks like a protection against hiding AdGuard no have that protection. |
AdGuard syntax may no translated if have regex with
The only problem will be if someone is stubborn with the AGuard syntax. related AdguardTeam/ExtendedCss#114 |
Enabling AdGuard Base, AdGuard Mobile, AdGuard Annoyance, I get the following cosmetic filters reported as invalid:
Fixing your case (
The following filters were correctly reject, they have mistakes in them:
This leaves those two as improperly parsed:
For first one of these two, the parsing error is uBO improperly matching parenthesis. For the other ome, I have to investigate as I am not seeing anything wrong with it. |
Actually one is a |
And someting like: DandelionSprout/adfilt#63 (comment)
I reported |
Maybe fixed if server
in the feature. |
Is that valid CSS pseudo-element syntax? |
I fixed that one in uBO, along with the case where |
|
Nope for:
recommend in the past to read CSS values for |
While investigating, it looks like there is a regression. Trying to find existing filter, this one in uBlock filters:
The style is no longer applied, the change here causes uBO to always apply |
Related issue: - uBlockOrigin/uBlock-issues#382 Additionally, fix minor parsing issues with AdGuard's cosmetic filters.
@gorhill I think there may be another case where this doesn't work consistently - when filters targeting multiple DOM elements are consolidated into one filter and one of them includes the test link: After scrolling down the page a bit, try to create the following consolidated filters (applying CSS to three elements with one filter) using the element picker:
The filter that you can create with element picker also works on page reload, but the non-working filter doesn't work even if you add it to Tested on both firefox and chrome latest uBO dev builds. |
@yourduskquibbles You can't use a procedural operator in a list of selectors, you will need to separate When you use a procedural operator in a selector, the whole selector is parsed as a procedural one, and in such case this results in an invalid selector when using a comma-separated list of CSS selector. When not using a procedural operator, you end up with a valid list of plain CSS selectors and uBO does not try to parse this, it just declaratively inject the style. Note that the second form works because the prepended selector passes the In the first form, uBO tries to test |
AdGuard maybe support:
but |
Per uBlockOrigin/uBlock-issues#382 (comment) `:upward(n)` procedural filter needs to ALWAYS be on its own line and never combined with comma separated filters, even when using `:style()` modifications
Actually, I need to investigate why the first form does not show as an error, I would have expected so. |
In the next dev build, following selector will be marked and rejected as erroneous:
While the following one will be accepted as valid:
However, the last one has to be understood as result of |
This is a very useful combination, but it seems like they don't like working together?
The text was updated successfully, but these errors were encountered: