Regardless of what is the reason of the current specific issue,

speaking generally: 100% compatibility all the time between uBO and AG extensions, even when using the same filter list, is not guaranteed, because some filters might be just not 100% compatible, like it's not guaranteed that the same website will work/look 100% same in different browsers (for example: Firefox vs Chrome).

Your comment is understandable enough. I think there is no need to go deep on this topic then. 🙂

Tested and it's certainly GFC. If you disabled uBf and enabled AG Base, you need ||fundingchoicesmessages.google.com^$3p and the aformentioned filters. Since the bait elements bail out too soon, they may not appear in logs. Or if you prefer AG's way of not blocking fundingchoicesmessages.google.com, *##div[class*=" "][style^="width: 1px; height: 1px; position: absolute; left: -10000px; top: -"]:style(display: block !important;)

It's not "earlier", uBO doesn't support generic css filter without *. Maybe will work if you set allowGenericProceduralFilters to true <= apparently not, as it's not a procedural cosmetic.

Raw JS cannot be updated via filter lists, because it would violate extension stores' no remote code execution policy. They have to be updated with the whole extension. Previously AG can update raw JS on chrome store only due to the store doesn't care about reviewing, but now with MV3, google doesn't allow it any more either. Firefox store is completely prohibited.

I have been thinking of supporting raw #%# JS by converting these to formal scriptlets with build-time generated hash-based names. However I am not sure the amount of work is worth the results, and keeping in mind working on this would prevent me from working on maybe more useful other stuff (for example the new jsonpath syntax).

f list maintainers think it's would be a top improvement to have versus other things to do, I am willing to work on this. Also, this would have to be filters available only from trusted sources, so AG wouldn't qualify since only uBO's own lists are to be trusted.

build-time generated hash-based names

I actually had one concern with raw JS when you discussed about it, which is what is the best way to make exceptions to the raw JS filter via quick update filter lists, since the raw JS is integrated to the extension (I assume that those would still have to be updated via extensions, is it correct) ?

The hash-based names might make sense I think if I understand correctly. So something like this:

example.com#@#+js(somehash)

?

Yes, assembled at build time, thus updated only via new published versions. Also yes, generated names would be used for exceptions. At runtime, uBO would use the same algorithm to derive name, then would use this to reference the scriptlet, hence can be used for exceptions or even to reuse the raw scriptlet for other sites if needed.

I gather sometimes no scriptlet fulfill the job while a small bit of raw JS would work. Downside is this requires an extension update, so uBOL would benefit most from this. Anyways, I need to know whether this is something that would really be useful to have.

Yeah, it's useful for some rpnt filters. But I think jsonpath is still more needed now, since raw JS is not too effective for sites that counter regularly, even for uBOL.