"uncaught TypeError: Illegal invocation" in Chrome

Context and 'this' in the spotlight

Let's delve into the world of "this". "this" in JavaScript refers to the context in the spot where the code is executed. When the methods, which heavily bank on their execution context, get detached from their parent objects, they tend to malfunction. This is because they subconsciously assume "this" to be the object they originally belonged to, and when they're called separately, "this" ends up referring to the global object, or if you're disciplined and use 'strict mode', undefined.

When darkness falls

Scenario: You're sailing smoothly until you hit the stormy sea of "Uncaught TypeError: Illegal invocation". Here are some common instances to look out for:

• DOM API methods like addEventListener or setTimeout - this was hoping to bond with a DOM element or the global window object.
• Console methods reminiscent of console.log where this had hopes of cozying up with the console object.
• HTML5 Web APIs like localStorage or sessionStorage, where this whispers sweet nothings to the storage object.

Fixing the broken heart

• Turn to the trusted .bind() to unite the function's this with the right object eternally.
• Flex the muscles of .call() or .apply() to customize the this value while demanding the function.

Callbacks and event listeners - The context twist

When you're giddily dealing with callbacks and event listeners, "Illegal invocation" errors often rain down, especially when methods are passed around as parameters minus their original context.

The callback saga

// Uh-oh! `this` was expecting myElement
myElement.addEventListener('click', myObj.handleClick);

// Yay! `this` found its love in myElement
myElement.addEventListener('click', myObj.handleClick.bind(myObj));


The event listener tale

Here's an angle with requestAnimationFrame, which has to be tied to the window context to avoid a catastrophic event:

// Watch out! "Illegal invocation" is lurking around
window.requestAnimationFrame(myObj.animationFrame);

// Safety secured! `window` as context is guaranteed
window.requestAnimationFrame(myObj.animationFrame.bind(window));


The context of native functions

Take the case of native methods like alert or localStorage.setItem. These chaps love their proper binding!

// Ouch! this will kick up a fuss
var storageSet = localStorage.setItem;
storageSet('key', 'value'); 

// Chill! context of localStorage is maintained
var storageSet = localStorage.setItem.bind(localStorage);
storageSet('key', 'value'); 


Compatibility across browsers

Cross-browser compatibility is a fickle mistress, context handling varies across browsers. For example, Function.prototype.bind() carries a polyfill for older versions of Internet Explorer (IE <= 8):

if (!Function.prototype.bind) {
  Function.prototype.bind = function(oThis) {
    // polyfill content here
  };
}


The "Implicit context loss" syndrome

The "Implicitly Lost" context syndrome covers those instances when you assign a method to a variable or shuffle it around as a callback. It's like a byproduct of Chrome errors, usually due to handling context as though it's a hot potato.