Support for multiple metamorphs in the same DOM.

[borismus]

Chrome extensions live in isolated worlds, which means that JS is not shared, but DOM is. If a Chrome extension injects a content script (written in Ember) and you are on a webpage written in Ember, metamorphs will clash.

This is a pretty exotic usecase, but I spent a few hours scratching my head about what caused the weird cross-context magic I was seeing. That said, the change seems harmless and would be pretty beneficial for complex extension developers.

Obviously the random number from 0-10k approach is going to fail once in a while... could be smarter about it (checking the DOM for existing Metamorphs), but not sure that it's worth the complexity.

[devinrhode2]

I'm pretty familiar with chrome extensions actually, something you can consider is directly a script into the pages environment. It would be something like:

var s = document.createElement('script');
s.src = chrome.extension.getURL('runInPage.js');
document.documentElement.appendChild(s); //documentElement.appendChild is the fastest method to append to dom

Also, in chrome extension documentElement is ALWAYS available, so you can run your content_script at document_start (I think that's the earliest one) and it'll work great.

With this, you can enter the pages JS environment before the site's emberjs does.

...I don't know exactly how this can be helpful to your situation, but it might help ;)

[devinrhode2]

Note: with this method, runInPage.js is in the same javascript world as the page itself, therefore be sure to wrap your code in a closure(function(){ /* your code */ }())

You could also consider using the webRequest to intercept the request to load the emberjs file to do something interesting.

I know too much about chrome extensions... :/

[tomdale]

Rather than using a randomly-generated prefix that might occasionally conflict, would it be better to allow extension authors to specify a Metamorph "namespace" that is more likely to be unique?

[wycats]

@tomdale I like that

[wagenet]

@borismus What do you think of @tomdale's suggestion?

[borismus]

Sorry, missed this in a flood of notifications. I think it's a fine idea in theory.

@tomdale How would extension developers that use Ember be able to specify the Metamorph namespace? Sounds like this would require changes to Ember too.

[wagenet]

@borismus, it seems like the default behavior should remain unchanged with this just providing an optional way to namespace.

[wagenet]

We would probably change Ember to support since that would be beneficial, but a change shouldn't be required.

[borismus]

I guess my point was that if we introduce this optional namespacing into metamorph, it will be unusable without changes to Ember.

However, if metamorph automatically supports multiple instances coexisting, no changes are required. Happy with either approach, and agree that explicit namespacing is cleaner.