This looks fine for now, pretty neat way to fix it.
But I still don't think we can escape a revamp at some point. The 2 "largest" volatile objects I tested before were the storage, and doc/window, and they function differently. On doc and window, the volatile props (stuff like accessing DOM elements via props) are looked up after the prototypes, while on storage, they are looked up first, before even the prop on the object.
For example:
- localStorage.getItem("test") returns null (no volatile item). - Object.defineProperty(localStorage, "test", ...) creates normal prop on it. - localStorage.setItem("test", "blah") now it is `blah` (only way to retrieve the defined prop underneat is getOwnPropertyDescriptor) - localStorage.removeItem("test") now reveals the original defined prop
Worse is that it also hijacks deletion, so delete acts like removeItem, but if you call delete now, it won't delete the defineProperty prop (since there's no setItem so nothing to remove).
For doc and window it's the opposite and if anything in the prototype chain has the name of an element id, it will be returned instead.