aeld with log argument - formerly aell · uBlockOrigin/uAssets · Discussion #17907 (original) (raw)
I can't seem to make it work.
I'm even trying the examples provided in the wiki, but still nothing is displayed.
wikipedia.org##+js(aeld, { "type": "/.^/", "log": 2 })
"Above filter will log all calls without defusing any of them (because type can't match anything)"
I've tested with FF 112.0.2 + uBO 1.49.0 and with chrome 109 + uBO 1.49.2
I also still have an old chrome 7x with uBO 1.46.0 where I've tested with wikipedia.org##+js(aell)
aell gives me a full listing of all eventlisteners (there are 79), while aeld shows nothing in FF and chrome.
I've checked in the logger that the filter is really applied.
What am I doing wrong?
You must be logged in to vote
your filter is working fine on my end
You must be logged in to vote
14 replies
Only now it is difficult to get out of this situation as they find a wiki with information or understand how JS code works without reading discussions and wikis.
Another reason is that I wanted to be sure that if stray filters with log/debug find their way into the lists, they won't cause issues with dev tools. This might have been the main reason.
Yes, website authors skilled with development tools will just install uBO dev build, and in the end nothing we can think of is going to stop them.
Will log functionality be available for dev build only? I thought it was just at the moment and will come to stable too.
Yes, website authors skilled with development tools will just install uBO dev build, and in the end nothing we can think of is going to stop them.
How about also requirng filterAuthorMode true? Sure they can find, but better than nothing?
What's a really convincing argument for having this available in stable build?
No, I meant adding another barrier in dev build. But maybe site owner who found using dev build will too find the flag...
Well it turns out a new way to pass extra parameters is working rather well I think, like with the new sed scriptlet, where pairs of extra parameters can be passed (position-independent), so I think this should be the way to go instead of the JSON approach. This would make using logging less cumbersome:
wikipedia.org##+js(aeld, /.^/, , runAt, idle, log, 1)
You must be logged in to vote
42 replies
Not uBO specific, same issue with AdGuard.
If I remove the logging of the element id on which the listener was added, the issue goes away. It seems Youtube may be trapping the access to the id property of an element and this causes failure somewhere.
So the logging of the element details was added as per request: uBlockOrigin/uBlock-issues#3061 (comment).
Accessing the id is causing an issue on Youtube, presumably because somewhere in Youtube's huge pile of JS, there is a trap which act on accessing the id of an element. I tried various things and somehow replacing:
if ( elem.id !== '' ) { parts.push(`#${CSS.escape(elem.id)}`); }
With:
const id = String(elem.id);
if ( id !== '' ) { parts.push(`#${CSS.escape(id)}`); }
Ends up solving the issue -- kind of a voodoo-esque solution...
This comment was marked as disruptive content.
so I think this should be the way to go instead of the JSON approach
Will the JSON approach be deprecated?
You must be logged in to vote
3 replies
I don't know. If eventually nobody uses it, probably.
I think set-constant and acis don't support the new way of passing optional parameters (They don't have get-extra-args.fn as dependency).
joysound.com##+js(set, document.body.oncopy, null, 3)
=>joysound.com##+js(set, document.body.oncopy, null, runAt, 3)
I will work on this in next dev cycle.