Obsolescence of __noSuchMethod__

[barbaz]

Obsolete since Gecko 39 (Firefox 39 / Thunderbird 39 / SeaMonkey 2.36)
This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.

This is going to break a LOT of our surrogates.

While __noSuchMethod__ is non-standard, the ECMAScript Harmony (ES6) specification will have Proxy, with which you can achieve the below (and more).

EDIT SeaMonkey 2.37a1 gives this warning in the Error Console when a __noSuchMethod__ is hit:

Code: Select all

Warning: Error: __noSuchMethod__ is deprecated

Also, as of the time of this edit I have not seen or come up with any Proxy-based emulation of __noSuchMethod__ that is limited to function calls - in fact I don't even know if Proxy can tell whether a property is accessed as part of a function call... does that matter?

[barbaz]

So I've played with Proxy (fun stuff! ) and thought about this... and I think that Proxy trapping all property acesses is actually going to make the surrogates more stable than the current __noSuchMethod__.. I recently contributed a surrogate where the page explicitly checked for a property before using it, and unlike __noSuchMethod__, where I had to explicitly specify the property, the use of Proxy would have meant that it makes no difference.

So I think we only need to intercept the get() operation with a shim something like this:

Code: Select all

let canUseProxy = typeof Proxy != 'undefined';

if (canUseProxy) {
  someObject = new Proxy(_internal_someObject, {
    get: function(target, prop, rcv) {
      // Emulate __noSuchMethod__: Give a specified function that does nothing if the property isn't in our object
      // NOTE: This assumes all nonexistant properties attempted to be accessed were meant to be functions.  Be careful here...
      return prop in target ? target[prop] : target['__noSuchMethod__'];
    },
  });
}

right?
(Obviously we wouldn't want to override __noSuchMethod__ at this point, rather using some other name if we make the switch now. But when __noSuchMethod__ becomes obsolete...)

[barbaz]

The Mozilla bug on removing __noSuchMethod__, https://bugzilla.mozilla.org/show_bug.cgi?id=683218
(Note comment 26)

[therube]

(Since when did "popularity" mean anything in Mozilla decisions .)

[barbaz]

x [Surrogate] shimmed or replaced code causing deprecations

Does this change mean this thread can be marked resolved?

[fluffypuff]

noscript-2.9.0.4rc1 (noscriptService.js) still relies on __noSuchMethod__ but, as of ff44, mozilla has removed it
https://developer.mozilla.org/en-US/Firefox/Releases/44

After reading the MDN docs regarding js proxy
https://developer.mozilla.org/en-US/doc ... ects/Proxy and https://developer.mozilla.org/en-US/doc ... e[quote]if the revoke() function gets called, the proxy becomes unusable: Any trap to a handler will throw a TypeError. Once a proxy is revoked, it will remain revoked and can be garbage collected.[/quote]...I'm left wondering whether proxying will provide ineffectual functionality.
For surrogates, the proxy declaration(s) reside within contentscript, right?
What's to prevent, e.g. anti-adblock script authors, enumerating and revoking any proxies we've created?

Then, after reading this
https://ponyfoo.com/articles/es6-proxies-in-depth
I'm now wondering whether we could (should?) both create AND proactively revoke() to achieve the same end result as provided by __noSuchMethod__

[Thrawn]

I think perhaps you don't understand the workings of the Proxy object. How much JavaScript experience do you have?