"abort-*" scriptlets are the source of numerous issues for several reasons, and I suppose the main one is that they don't allow filter maintainers to narrow them down to some specific part of the code we're trying to abort.

I suggest adding one more optional argument to the "abort-*" scriptlets so that we could use the current stack trace as a condition.

For example, here's how it would look like in the case of abort-on-property-read:

example.org#%#//scriptlet('abort-on-property-read', <property>, <stack>)

• stack (optional) - string or regular expression that must match the current function call stack trace. Please find the stack trace example below.

Here's a simple code snippet that shows how we should get the stack trace:

const stack = new Error().stack // get original stack trace
    .split('\n').slice(3). // get rid of our own functions in the stack trace
    map((line) => line.trim()) // trim the lines
    .join('\n') // join

Here's an example of the stack trace:

at e (https://example.org/test.js:123:12)
at e (https://example.org/testtest.js:233:132)
at e (https://example.org/testtesttesttest.js:2:194548)
at e (https://example.org/testtesttesttesttesttesttesttest.js:2555:1212)

For instance, if you want to abort the property read that happens in test.js only, you can add a rule like this:

example.org#%#//scriptlet('abort-on-property-read', 'Object.prototype.someProperty', '/test.js')

Additionally, we should extend debug-on-property-read and debug-on-property-write:

1. Add stack argument there too
2. Calculate the stack trace as it was explained above and print it to console.

@AdguardTeam/filters-maintainers thoughts? Would you like