Closed Bug 833744 Opened 12 years ago Closed 10 years ago

Support sourceURL pragmas in eval scripts

Categories

(DevTools :: Debugger, defect, P2)

Product:
DevTools
Component:
Debugger
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1107541

People

(Reporter: rcampbell, Assigned: jlong)

References

Details

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.
Depends on: 583083
Priority: -- → P3
s/@/#/ as per discussion in dev-js-sourcemap. See also, http://www.softwareishard.com/blog/firebug/firebug-tip-label-dynamic-scripts-with-sourceurl-directive/ which has a nice little regexp for us.
Summary: support //@ sourceURL annotations in eval'd scripts in Debugger → support //# sourceURL annotations in eval'd scripts in Debugger
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.
Depends on: 904144
Assignee: nobody → nfitzgerald
Priority: P3 → P2
No longer depends on: 583083
I'm unassigning myself because I won't be working on this anytime soon.
Assignee: nfitzgerald → nobody
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.
Summary: support //# sourceURL annotations in eval'd scripts in Debugger → Support sourceURL pragmas in eval scripts
See Also: → 583083
Hey Nick, any chance to prioritize this now? The usage that prompts this bug is surprisingly popular so any improvement here is highly appreciated!
Flags: needinfo?(nfitzgerald)
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).
Flags: needinfo?(nfitzgerald)
Thanks a lot! Adding as dep so we know when things can move along.
Depends on: dbg-source
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...
Assignee: nobody → jlong
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Product: Firefox → DevTools
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!
I don't know why this one was closed (before my time on source maps) but you might want to CC yourself on bug#1400856 or bug#1224078, or even bug#1339970 (the source-map tracking bug).
You need to log in before you can comment on or make changes to this bug.