Bug 34764 – Web Inspector: provide a way to debug scripts dynamically added to document

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Andrey Kosyakov]

Currently, inspector binds scripts to resources and attempts to show them within a resource context. However, for a script that was added dynamically (e.g. via document.write() or by adding a script element), we're unable to display script in a resource. 
Thus, it is suggested that inspector should handle dynamically added scripts differently. To enable this, we would need to pass some indication to inspector that a script was added programmatically. As scripts written with document.write() are created from within HTMLTokenizer, it is suggested that we add a field (e.g. processingDynamicContents) to HTMLTokenizer and, whenever a document is opened from script, create HTMLTokenizer with processingDynamicContents set. This, in turn, would require adding a similar protected property to Document that would be used to pass a flag from Document::open() to HTMLDocument::createTokenizer().

[Timothy Hatcher]

We use to show these scripts but turned them off because they just poluted the menu. You can still get to them by stepping into a function defined in them, etc. Then they will be in the menu.

What you describe should not be required.

[Andrey Kosyakov]

Sometimes stepping into such a function would not be possible from a visible script (think setTimeout() or any other event callbacks). In particular, we bumped into this while trying to enable workers debugging by simulating workers using an iframe. Once we clearly mark dynamic scripts in a scripts drop-down box (e.g. by appending some id after script URL), I don't think pollution is going to be an issue -- after all, this is not supposed to be common in "simple" pages, and when dynamic scripts _are_ present, there are probably good reasons to be able to open them to set breakopints.

[Timothy Hatcher]

I think we also show dynamic scrips if the have a "@ sourceURL" comment.

http://blog.getfirebug.com/2009/08/11/give-your-eval-a-name-with-sourceurl/

[Patrick Mueller]

(In reply to comment #3)
> I think we also show dynamic scrips if the have a "@ sourceURL" comment.
> 
> http://blog.getfirebug.com/2009/08/11/give-your-eval-a-name-with-sourceurl/

That's correct.  There's a little more information here:

   http://pmuellr.blogspot.com/2009/06/debugger-friendly.html

As noted, FireBug also supports this technique, and I haven't seen anything else like this in practice, so it seems like the best way to go.

[Pavel Feldman]

Summary of what has been discussed on the IRC:

1) There is a workaround (that could be used for workers):  iframe.contentWindow.eval() in combination with sourceURL should do the trick. I think we should do that to fork the efforts.

2) We'd like to address the issue described. Distinguishing between documents created as a result of resource loading vs documents created from within document.write sounds reasonable. Please proceed with the patch and add olliej as a reviewer. He is the right person to review script-related WebCore parts as well as JSC code that carries script type information along with its url and lines.

[Brian Burg]

In current inspector, anything given a source map will get a menu item, otherwise it won't have one.