It's theoretically possible to cheat this, but I don't know if it would actually gain anything. For example:

We could use something like L.noConflict() to help:

var L_ = L.noConflict();
// window.L is now back to its original value

and just use L_ everywhere instead. This would break third-party plugins, however.

We could do something more sneaky, and copy everything from L to L_:

var L_ = L.noConflict();
Object.keys(L_).each(function(k){
  L[k] = L_[k];
});

However this wouldn't work if something tries to edit properties on L or L_, as they wouldn't get updated on the other object. Plus, they'd risk overwriting things on the original L from the Ingress codebase.

It looks like trying to be clever with the L variable isn't really going to help us much. What other options are there?

Well really, the issue is that the Ingress code adds an event handler before the IITC code loads, and we can't remove that. Or can we? In main.js, we replace the entire contents of the <head> and <body> nodes. If instead we replace the nodes themselves, we lose all of the event listeners bound to them.

There is a potential catch — it's not immediately clear to me whether the handler causing the error is registered on the <body> element or the document itself. If the event handler is registered on the document, then the error will still occur. In that case, there would need to be some magic around replacing the way that event listeners get added to the page, so that we can remove any listeners that get added before IITC itself starts up.

Sorry, this was a bit of a braindump. But hopefully it explains why this is not an easy issue to solve, and presents a potential fix.

TypeError: L is not a constructor #964

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions