How to use the tool in online environments where context needs to be specified?

[specialorange]

http://stackoverflow.com/questions/24788968/use-backbone-debugger-in-online-js-environment

Trying to get the functionality to validate tested collaborative code on JSFiddle or Plnkr or the like...

[Maluen]

Currently backbone running into iframes isn't supported.

The extension still needs a way to detect the contexts of the page and to let you choose the one to use, plus changing the panel so to interact with the right context.

I've looked up at this time ago, since can be useful also for using it with Ripple, etc. but seemed to require quite a lot of work.

If you can help, I'm on this ;)

[ghost]

What would you need for help with this?

[Maluen]

A simple solution could be to detect the page iframes in the panel activation page (that with the link "Restart the application in debug mode") and let the user choose the context to use, e.g. with a select.

An instance of the backbone agent is injected in every frame (via inspectedWindow.reload, unfortunately doesn't seem to exist a way to choose a specific frame), hence, we need a way for each instance to detect in which frame it is running (probably by getting its url, could be that this must be done in the content script) in order to send that information to the panel.

The panel will then execute functions only in the choosen iframe (see inspectedWindow.eval "frameURL" and inspectedPageClient.js#L26) and ignore messages from other instances.

[ghost]

Do you have any branches you've already been working on this in?

[Maluen]

No branches unfortunately, I just did some problem analysis.

Anyway, the ember inspector is doing something similar, the codebase is huge, but you can take a look at:

• https://github.com/emberjs/ember-inspector/blob/master/dist_chrome/content-script.js#L46
• https://github.com/emberjs/ember-inspector/blob/master/app/adapters/chrome.js

I get that this can be quite confusing without knowing the codebase, I will try to look at that myself as soon as possible.

[Maluen]

Some screenshots ;)

Works, but before pushing I've to do some cleanups and adjustments.

[ghost]

Haha, guess I won't be of any help, I didn't have time last night to dig into it. Thanks for getting it done so quickly!

[Maluen]

Changes pushed, took a bit of time since I had to rethink various aspects of the communication model to integrate this new "multi frame" scenario in the seamless way possible.

No iframe selection dialogs or anything else to set on startup, no additional actions are required.
The frame used is the first where Backbone is detected, maybe in the future we could add the possibility to override the one to use, if needed.

However, to the best of my knowledge, it seems that Chrome allows you to execute code in the context of a frame only by specifying its url, which is not necessarily unique!
Follows a list of limitations of the current solution (that I'm aware of):

• Partial support for pages with multiple frames with the same url, if Backbone is defined in one of them. Since they result as indistinguishable, Chrome execute code only on the first, while the messages sent will sum up in the panel, very buggy.
• Don't work for Backbone define into sandboxed iframes, since content script cannoted be injected here <-- like jsbin! This requires more testing
• Didn't tested on iframes without src (e.g. with content injected directly via js), in those the url defaults to "about:blank", there could be content script injection problems or code execution issues. <-- like jsbin! This requires more testing
• The tool will break on older versions of Chrome where inspectedWindow.eval "frameURL" isn't supported, the documentation is not of great help here, it states that the feature is on beta channel and will come on stable from v38, but that's obviously false since I'm on stable (v37) and works (and worked also on v36) without a glance! This requires more testing

As an additional note, there is (very) limited support for Ripple since it dynamically completely change the page content after the page has loaded, moving all the content into an iframe with the same src of the page!
This leaves the tool with an old, already detected, useless context, with additional messages coming from the new iframe, which has the same url and are thus considered as the same, but with Chrome which continues to execute code in the old context (since they have the same urls).

[jasonLaster]

Hmm. I wonder if the injected script could find the frames.

Then search each for backbone. Extreme? Maybe...

[Maluen]

@jasonLaster yeh you could, right now that's pretty much what the debugger does, except it runs multiple injected script instances, one per frame.

You could also run one single instance on the top frame and search the frames here manually, but note that there are the same origin security policies that could prevent you from accessing the frame contents, this applies even to the associated content scripts.

[jasonLaster]

Hmm. Interesting. Maybe something here: emberjs/ember-inspector#29

[Maluen]

I looked a bit at their code, not too deeply, but it seems that they get the iframes on the page + monitor new added frames and inject the ember_debug (their corresponding agent) on them as soon as they are detected.

This is in a way what we are doing right now, except we use the chrome.devtools.inspectedWindow.reload function that does this automatically, since we need to run the agent since from the beginning, while they probably don't have this requirement.

Problem is in the communication from panel to agent, since we are using https://developer.chrome.com/extensions/devtools_inspectedWindow#method-eval but this allows only to specify the frameurl, not the frameid.

A solution is to use a messaging-only interaction, where the panel sends a message with a request, e.g. send me the view 12 info, and the agent sends back a message with the requested data.

The ember inspector seems to do something like this, which probably is also more general since they also support other browsers: each ember_debug instance creates an unique id based on the url, the date, the application itself, etc.

This unique id is then used in the communication, the panel sends a message with the unique id, every agent (ember_debug) receives it and skips the message if the id is not the same; you could also send a null id and the message seems to be interpreted like a broadcast.

This is a doable solution, but for sure could make the communication a bit trickier, since you have to keep track of what response is associated to what request, don't know if there is some simple method to track responses.

References:

• Inject ember_debug into detected iframes: https://github.com/emberjs/ember-inspector/blob/54c7fc6e6c1129c31409e91bf503bd296e2ce693/app/adapters/chrome.js#L57
• Keep track of instances unique ids to let the user choose: https://github.com/emberjs/ember-inspector/blob/54c7fc6e6c1129c31409e91bf503bd296e2ce693/app/port.js#L19
• Skip non-broadcast messages of another ember_debug instance: https://github.com/emberjs/ember-inspector/blob/master/ember_debug/port.js#L17