Debug in Web Inspectors

[nilshoerrmann]

It would be neat, if the debug mode wasn't an extra page but a panel in the browsers' web inspectors.

[nilshoerrmann]

This idea just crossed my mind again while I was debugging a website. Would it be possible to move the debug view to a web developer panel in Firefox/Chrome/Safari?

[brendo]

I'm don't know much about integrating with the developer panels, but it's a great idea!

[nilshoerrmann]

I know that web inspector panels for JavaScript frameworks like Ember and React exist. They all seem to be based on common web technologies: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Anatomy_of_a_WebExtension

Accessing the debug and profile information in the inspector would enable a few interesting features:

• First and foremost, it would be possible to see the front-end page and the underlying XML at the same time (no more switching between different tabs that are not syncronised).
• It would be also be possible to format and view event results in the web inspector directly (removing the need for a comment in the HTML. This should make event debugging much easier
• As the default web inspectors already have a DOM tree view with collapsible nodes, this should be adaptable easily, see #17.
• A bit crazy, but as the debug mode knows all the templates and sources, it might even be possible to highlight the resulting HTML when hovering XML nodes in the "Symphony inspector".
• It might even be possible to show Symphony logs in the console.

I know from experience that debug mode performance suffers severely when dealing with large XML sources, but I never experienced this kind of problem with the markup view in the web inspectors. So the debug mode could benefit from core web inspector optimisations.

[michael-e]

+1. I love this idea.

[nilshoerrmann]

I'm don't know much about integrating with the developer panels, but it's a great idea!

Question @brendo: How to create a developer panel seems to be well documented (e. g. https://developer.mozilla.org/en-US/docs/Tools/Adding_a_panel_to_the_toolbox). But is there a way for Debug Devkit to either deliver its results with the current browser request or at least for the current browser request?

Currently, if I use the debugger, I always trigger a separate request. Same is true for the profiler, which decouples my page view in the browser from the profiler results. For a Symphony Inspector the actual data of the page I'm viewing in the browser would be needed. Otherwise event results couldn't be displayed.

[nitriques]

But is there a way for Debug Devkit to either deliver its results with the current browser request or at least for the current browser request?

From the top of my mind:

The extension would add a special http header to each request the browser makes. If Symphony sees it, it can then send all the content WITH the request: let's say in a hidden div. I've played with extensions in Chrome and could do this very easily.

[nilshoerrmann]

Nice idea! That would simplify the inspector a lot.

I have actually no idea how devkits work but would be possible to transmit the results of all devkits at once (xml, params, profile)?

[nilshoerrmann]

Having to admin that I have no idea how this stuff works between server and browser, would it be possible to send two consecutive server responses ("one split in two parts") so that the browser starts rendering when the HTML part has finished but keeps receiving the rest?

[nitriques]

I have actually no idea how devkits work but would be possible to transmit the results of all devkits at once

Yeah you could do it!

would it be possible to send two consecutive server responses ("one split in two parts") so that the browser starts rendering when the HTML part has finished but keeps receiving the rest?

HTTP2 can do this, but HTTP1 cannot. H2 is coming strong, but right now, it still hard to set up.

If you want to not delay rendering, you could put your html/xml/json in a script tag with the type="text/x-template" but you would still need to download the whole thing.

That being said, you could also issue a ajax request from the extension.

[nilshoerrmann]

That being said, you could also issue a ajax request from the extension.

That sound better for performance. But how would I get the devkit results for exactly that page view in my browser? Making an AJAX request would trigger an additional request with different context (think event results).

[michael-e]

Too complicated. The additional content will only get delivered to developers, right? (Of course one should be able to switch in it on and off nevertheless.)

[nilshoerrmann]

Yeah, it would make sense to only request it, if the related inspector panel is opened.

[nitriques]

That's why I would ship it with the current request. And that content is only sent when a specific browser extension is installed and running.

[nilshoerrmann]

Yes, I understand that.

I was just asking if there was another option because in case of large XML sources rendering for developers might be delayed notably – and it would be nice to prevent this. At least, I don't like to wait :)

[nitriques]

Until H2 is mainstream and well baked into php, we'll have delays sadly.

[michael-e]

@nilshoerrmann: Nor do I! I understand your concerns — but my biggest debug view is around 840 kB of XML (12.000 lines), but that would still be acceptable if you have a fast DSL connection. In this case Symphony's debug view is very very slow, so I must always use ?debug=raw.

[nilshoerrmann]

@michael-e: Fair point.

So, all we need as a base for a Symphony Inspector is a bundled response of all devkits if a special request header is sent. Am I correct that this is more something Symphony should provide and not this specific debug devkit?

[nitriques]

Am I correct that this is more something Symphony should provide and not this specific debug devkit?

I like the current separation of debug vs profile. and the would response to a query string OR a HTTP header, which is simple enough!

[nilshoerrmann]

I like the current separation of debug vs profile

In what way? Visually in terms of "having different URLs" / "having two tabs" or in terms of the technical implementation?

[nitriques]

In what way?

in terms of the technical implementation :)

[nilshoerrmann]

Okay, I haven't questioned the profiler and the debugger being separate extensions. This enables users to only add those devkits they really need, which is good.

My question is about where the response needed for a Symphony inspector panel would be emitted: Is it up to each devkit extension to add a comment with its results to the page on request or is this Symphony's responsibility?

I actually don't know how and where devkits hook into the system, but I though they were a core concept that's only used by extensions like this one or the profiler. Which makes a central point of emission logical in my eyes.

[nilshoerrmann]

Let me give an example:

• Let's say Symphony inspector panel add-ons for all browsers already existed. If opened, they would add a special header to the page requesting the devkit data.
• Symphony would receive this header and fire a special delegate that would invite devkit extensions to return the markup needed for the inspector panel.
• Those devkits supporting the inspector panels would respond to the delegate with the appropriate content and markup.
• In the end, Symphony would take the responses of all devkits and combining them in a comment at the end of the returned page.
• The add-ons would use the given markup in their inspector panels.

Is this a feasible approach?

[nitriques]

My question is about where the response needed for a Symphony inspector panel would be emitted: Is it up to each devkit extension to add a comment with its results to the page on request or is this Symphony's responsibility?

Yes it's extensions.

but I though they were a core concept that's only used by extensions like this one or the profiler.

Yeah they use the pub-sub pattern that is strangely only available to extensions. The whole core should work that way.

1. ok
2. Symphony would receive this header always and a special delegate that would invite devkit extensions to return the markup needed for the inspector panel. It would be up to the extension to findout the condition in which they need to act.
3. yes
4. yes
5. yes!