The default bug view has changed. See this FAQ.

Support sourceURL pragmas in eval scripts

RESOLVED DUPLICATE of bug 1107541

Status

()

Firefox
Developer Tools: Debugger
P2
normal
RESOLVED DUPLICATE of bug 1107541
4 years ago
2 years ago

People

(Reporter: rc, Assigned: jlongster)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
Duplicate of this bug: 833683
See also bug 583083
(Reporter)

Updated

4 years ago
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
Depends on: 914930
No longer depends on: 583083
Depends on: 933460
I'm unassigning myself because I won't be working on this anytime soon.
Assignee: nfitzgerald → nobody

Comment 8

3 years ago
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.

Comment 9

3 years ago
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.
See Also: → bug 1011760

Updated

3 years ago
Blocks: 771597
No longer blocks: 771597

Updated

3 years ago
Summary: support //# sourceURL annotations in eval'd scripts in Debugger → Support sourceURL pragmas in eval scripts

Updated

3 years ago
See Also: → bug 583083

Comment 12

3 years ago
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)

Comment 14

3 years ago
Thanks a lot! Adding as dep so we know when things can move along.
Depends on: 905700
(Assignee)

Comment 15

2 years ago
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)

Updated

2 years ago
Assignee: nobody → jlong

Comment 16

2 years ago
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?
(Assignee)

Comment 17

2 years ago
(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.
(Assignee)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1107541
You need to log in before you can comment on or make changes to this bug.