Re: [whatwg/dom] [Proposal] Add EventTarget.getEventListeners() (#412)

> Me, personally, a _won't fix_, not because I don't understand the use case, simply because it's been too many years that libraries trust the fact listeners set privately or ASAP will never be reachaed or removed from the node.

This is simply not true.
As @LeaVerou noted above, it is well possible since _ages_ to do this.

In fact, I also mentioned my "hijack library" (see `@dorgaren/usable` at npm) for this and similar uses above last year.
(It has a few issues remaining, that are to be fixed soon, the primary one being multiple registration, but as this not being self-promotion, this is not my focus here.)
Loading that at the beginning of a page (either by embedding it into a script on the very same page, _or_ creating a 20-line browser addon that guarantees to load it _before_ any page is loaded).

It makes it facile to retrieve and remove (that is the primary scope) event listeners attached by anyone to anything.

This very ability / behavior, I think, makes most points above by everyone about _expectations_ around some sort of _encapsulation_, as well as _security_ moot.

Any page relying on third party scripts could load something similar (either intentionally or "inadvertently", via hijacking, sandbox vulnerabilities, or any other method) to make this possible for such (or any other) third party scripts (or, as my intention was, for the "JS app" belonging to / being the "page" itself).

Would it be better if this has been implemented natively with some configurable security? Sure, I think.
Is relying on any such stuff for privacy, security, or expectation of actions to be taken / lack thereof unreasonable? Sure, I also think.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/412#issuecomment-1063402953
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/412/1063402953@github.com>