Bug 77010 - Script pane: Optionally show code included via eval()
Summary: Script pane: Optionally show code included via eval()
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated) (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-25 07:43 PST by Igor Bazarny
Modified: 2014-08-03 18:35 PDT (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Bazarny 2012-01-25 07:43:06 PST
Script panel does not show code requested with XmlHttpRequest and eval()-ed. In my application a great deal of code is handled this way to reduce initial load time. Inability to find code in Script panel makes debugging really complicated. It would be nice to have at least an option to show code imported via eval() so I could be able to find my code
Comment 1 Vsevolod Vlasov 2012-01-25 13:02:13 PST
It is possible to add an option to add these scripts to file selector, but the correct way for you would be to use source URLs. The number of anonymous scripts on the page could be quite big and each console evaluation adds another one. It won't be easy to find the one that you need by opening all of them one by one. Also searching across all scripts can help, we should consider adding an option to search in anonymous scripts.
Please note that anonymous scripts are still shown when they are opened from the call stack when debugger is paused.
Comment 2 Igor Bazarny 2012-01-26 06:12:17 PST
(In reply to comment #1)
> It is possible to add an option to add these scripts to file selector, but the correct way for you would be to use source URLs. 
Ideally, I would like to see scripts loaded via XHR and eval()-d in the list of sources. If that's not possible, I'd like to be able to jump from related entry in the network pane to scripts pane. If that's hard, I'm OK with a need to scan through all eval sources. Yes, that's time consuming but it still leaves some way to debug

> Please note that anonymous scripts are still shown when they are opened from the call stack when debugger is paused.
It means I will need to find not the call I'm interesting in, but also a call from the other script which will help me get to my file. Assume that script is 'compiled' (e.g. with closure compiler) and I don't have an easy access to server which hosts my script so script modification is not easy.
Comment 3 Vsevolod Vlasov 2012-01-26 06:37:28 PST
(In reply to comment #2)
> (In reply to comment #1)
> > It is possible to add an option to add these scripts to file selector, but the correct way for you would be to use source URLs. 
> Ideally, I would like to see scripts loaded via XHR and eval()-d in the list of sources. 
The common way to do that is using source URLs, see http://blog.getfirebug.com/2009/08/11/give-your-eval-a-name-with-sourceurl/ Is there a particular reason why you can not or prefer not to use them? Source URLs could still be added after loading file the from network if you don't have access to the server.
Comment 4 Patrick Mueller 2012-01-26 07:45:52 PST
(In reply to comment #2)
> Ideally, I would like to see scripts loaded via XHR and eval()-d in the
> list of sources. If that's not possible, I'd like to be able to jump from 
> related entry in the network pane to scripts pane. If that's hard, ...

Yeah, I'd say this falls in the "hard" to "not possible" category.

You're suggesting that somehow a magic link be made between an XHR request and an eval().  You could imagine the debugger being super smart, and checking to see if the string being eval()'d is the same string as from an XHR, then you'd know.  

But in general, if you're XHRing the code, you're modifying it.   Because otherwise you could just inject a <script src=> element in your document.  And if you're modifying it, then that magic link disappears, because the string you XHR !== the string your are eval()ing.

Source URL is what you want here, as Vsevolod notes.  It's the only practical thing to do, in my experience. And it works quite well - I make use of it ALL THE TIME.  If your library vendor is XHRing and eval()ing under the covers for you, then you need to bug your vendor to add the source URL comment to the XHR result they are eval()ing.  It's very easy to do.