Status

For bugs in Firefox DevTools, the developer tools within the Firefox web browser. This includes issues about the user interface of the toolbox, special pages such as about:debugging and about:devtools, and developer-related APIs.

Security

(public)

User Story

We should support eval'd scripts marked with //@ sourceURL in the Debugger.
e.g.,
function someFunc() {
debugger;
}
//@ derp.js
would appear as derp.js in the debugger's script drop-down if added via window.eval() or some other mechanism.

This is a little tricky because we notify the frontend of the source's existence before we ever have the contents of the source. We don't want to wait for the source contents to load before we send newSource packets. As far as I can tell, we have three options:
* Have SourceActors grab their contents immediately when they are created, and then if there is a sourceURL annotation, send an unsolicited "renameSource" packet.
* Wait until we can use Debugger.Source, in which case we can check the source contents immediately.
* Got distracted and forgot what the third option was :-/

(In reply to Nick Fitzgerald [:fitzgen] from comment #4)
> * Wait until we can use Debugger.Source, in which case we can check the
> source contents immediately.
I was going to suggest this as well. I would have done it already, if we weren't trying to temporarily minimize the pain for backporting to the mozilla-b2g18 branch.

After re-thinking this, I think this should be done during parsing. Otherwise we would have to crappily re-implement a parser so we could be sure that the directive was indeed happening in a comment and not a string because the script was going to eval something and add the comment itself or whatever.

Are there any plans for when this problem is going to be solved? In a JS framework that manages modules and stores them in LocalStorage/IndexedDb for offline use, this capability is a must have. My team is behind such a framework and we struggle as Firefox debugging tools fell greatly behind Chrome. We are desperately trying to optimize our framework for Firefox OS and Firefox for Android and it seems that we are forced to postpone the Gecko-tuned release a month after month after month. And before anyone asks, Firebug is not an answer for remote debugging on mobiles.

I believe it's at least partially working on desktop. That is, with Firefox 26, debugging at http://gwtproject.org/ sometimes works. We sometimes use eval() to install code in GWT, and use //# sourceURL annotations.
So, it's probably worth testing and reporting what you find on mobile.

(In reply to gene.vayngrib from comment #8)
> Are there any plans for when this problem is going to be solved?
Not at the moment. I unassigned myself because my focus for the next while is going to be memory tooling, which is another very highly requested feature.
Patches are always welcome, of course, and if you want to give it a go, I can mentor you and provide guidance when possible.

(In reply to gene.vayngrib from comment #8)
> Are there any plans for when this problem is going to be solved? In a JS
> framework that manages modules and stores them in LocalStorage/IndexedDb for
> offline use, this capability is a must have.
If you're already using LocalStorage/IndexedDB, you should be able to use createObjectURL and then create a <script> tag with the src to that URL to load the given scripts instead of using window.eval(). That will likely be faster, as well as should make all this already work.

jlongster is doing a big refactoring of the way that the debugger deals with sources in bug 905700 and this should be pretty easy after that lands (and while it would be possible to do it before then, I don't think we should).

I think this will be pretty easy to solve now. In fact I added some really basic support in my D.Source patch already but I just noticed it's buggy; it doesn't fetch the source contents correctly. Will fix next week.
Why am I on bugzilla on Thanksgiving...

Hey @jlongster I'm also seeing a few issues surrounding this:
1. The evaled scripts show up as: foo.js -> eval where foo.js is the script that evaled them.
2. The contents just contain the name (for example evaling jQuery shows the contents as being the string "jQuery").
3. For the project I'm working on I would expect like 50 evaled scripts but only see 5. Is there a limit being set?
Are these related to this or should I file a separate issue?

(In reply to Matthew Phillips from comment #16)
> Hey @jlongster I'm also seeing a few issues surrounding this:
>
> 1. The evaled scripts show up as: foo.js -> eval where foo.js is the script
> that evaled them.
> 2. The contents just contain the name (for example evaling jQuery shows the
> contents as being the string "jQuery").
> 3. For the project I'm working on I would expect like 50 evaled scripts but
> only see 5. Is there a limit being set?
>
> Are these related to this or should I file a separate issue?
These are all related and easily fixed now that Debugger.Source has landed. Sorry didn't see your comment until now, and I forgot about this, so I already filed another one. Those will all be fixed when bug 1107541 lands.
Not sure about you only seeing 5 when there should be 50. Can you post a test case? We don't show eval scripts that come from an inline script in an HTML page, are you doing that? That will be fixed eventually, but for now there are a few problems with that.

Why is this closed with fixed? It still does not work. For Example look at https://shop.polymer-project.org/ with current Firefox. You will see in the script debugger when you look at "no domain", there are javascripts with "sourceurls" but that name is not used!