Closed Bug 901930 Opened 6 years ago Closed 6 years ago

DevTools Debugger fails to find sources

Categories

(DevTools :: Debugger, defect, P2)

26 Branch
x86_64
Windows 7
defect

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 30

People

(Reporter: codacodercodacoder, Assigned: past)

References

Details

Attachments

(2 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

1 - FF and devtools with WebConsole active
2 - load site under development
3 - switch to Debugger 


Actual results:

"This page has no sources"


Expected results:

Sources (scripts) should be listed.
Note: if in step 1 above the debugger is active, sources are found correctly.
Seems to work for me with http://wikipedia.org in
 firefox-22.0.en-US.linux64,
 2013-08-11-03-02-25-mozilla-central-firefox-26.0a1.en-US.linux-x86_64.
Shortly, "load.php" appears instead of "This page has no sources".
Component: Untriaged → Developer Tools
Mozilla/5.0 (Windows NT 6.1; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130811030225

Russ could you provide the website where you are encountering the described issue?

I managed to see the message that "This page has no sources" but just for a second while I switched to the Debugger and the page was still loading. After the page loaded, all the scripts were listed.
Component: Developer Tools → Developer Tools: Debugger
Sorry, can't provide a URL. My app is a huge ASP.NET/intranet thing...

It seems there are a couple issues at play here - I tried to capture them in my STR but maybe I failed... step 1 maybe the culprit:

1 - FF and devtools with WebConsole active
  - FF remembers which tool was active from the previous session. 
  - Open FF, 
  - Open dev tools, bring console forward, 
  - Close FF completely, 
  - Reopen FF and dev tools.  

Now FF should open with the console active.

I followed these steps then loaded MDN and FAILED to repro the bug.  However these same steps repro the bug EVERY TIME for my site.

Note: There are no errors on my page.

Note 2: If I perform the logical opposite of step 1 (close FF with debugger active and reopen) it works fine; sources are listed one/two seconds after page load.
Can you try and cut down your intranet app bit by bit (binary search?) so you can provide us with a minimal test case that we can reproduce the bug on? We can't fix anything if we can't reproduce the bug. Thanks.
Nick: I'm a big advocate for binary-chop.  However, in this case, I'd elect to leave it as is.  The workaround is trivial and soon becomes automatic (start devtools with debugger forward) and the potential benefit to a fix is hardly worth the potential cost of whittling down the code base to a definitive A/B point.

That said, I'll reply offlist with some other ideas.
This bug has NOT appeared since updating to firefox 23.0.1
Marking as WORKSFORME then based on your last comment. Please reopen if you can reproduce it again.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Russ reporting that this has returned in Fx26, currently in Aurora.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
taking this for testing.
Assignee: nobody → rcampbell
Priority: -- → P2
Version: 22 Branch → 26 Branch
Russ, trying to test this but without a url this is not easy.

Are you loading from file: uri by any chance?
Thanks Rob.

No, http.

Rob, if you want screencaps of the issues...

1  debugger ignoring debugger statements
    var x = 1; debugger;  //  <== ignored
    restart will not cure this.
2  inactive debugger buttons when it hits a breakpoint
    Correct file presented, debugger and app paused, no toolbar (play, step, etc.)
3  active buttons but no file loaded to debug...
    debugger and app paused, toolbar active, no file presented
  
let me know.  Basically, *this* bug has made babies. Yes, that's probably three new bugs but my feeling is, let's get it successfully loading files 100% first.

Re 1: If screen updates/repaint permit, I see the debugger statement hit (toolbar is briefly enabled, line is painted pale blue) then "something" removes it (inactive toolbar, no blue line).  It's almost as if another thread is in play (yikes).

HTH
Ok, I think I understand what's not working.

Loading a basic page (from file: or http:), I'm not seeing the index.html file load into the debugger initially, despite having a couple of buttons with onclick handlers and a loaded script file. The .js file does load and show up however.

If I modify the html page (either through the buttons in the page or by editing it in the inspector), the html page appears.

(In reply to Russ from comment #11)
> Thanks Rob.
> 
> No, http.
> 
> Rob, if you want screencaps of the issues...

Maybe!

> 1  debugger ignoring debugger statements
>     var x = 1; debugger;  //  <== ignored
>     restart will not cure this.

I was able to make this work with a debugger statement in an included js file. But only after a reload and the first time I saw it blow past the debugger statement while the console was loaded.

> 2  inactive debugger buttons when it hits a breakpoint
>     Correct file presented, debugger and app paused, no toolbar (play, step,
> etc.)

that's bizarre. Probably a separate issue, but not good.

> 3  active buttons but no file loaded to debug...
>     debugger and app paused, toolbar active, no file presented
>   
> let me know.  Basically, *this* bug has made babies. Yes, that's probably
> three new bugs but my feeling is, let's get it successfully loading files
> 100% first.
> 
> Re 1: If screen updates/repaint permit, I see the debugger statement hit
> (toolbar is briefly enabled, line is painted pale blue) then "something"
> removes it (inactive toolbar, no blue line).  It's almost as if another
> thread is in play (yikes).

Hard to say what's happening there without knowing more about your app. I'm going to continue testing and try to figure out what's happening.

At the very least, we should always be showing an index.html file if we're loading one, even if it doesn't necessarily have a script in it.
created a small test app here:

http://people.mozilla.org/~rcampbell/901930/

I think the debugger statement on line 15 of cards.js sometimes doesn't hit, but can't seem to reproduce it on subsequent reloads.

Also, the index.html file only appears when one of the buttons gets clicked. Or the events tab in the side panels gets loaded.
> I think the debugger statement on line 15 of cards.js sometimes doesn't hit, but can't seem to reproduce it on subsequent reloads.

Yep - however, it will "always" work if you first CLOSE FF with devtools/debugger active, then reopen both (I use the default page as "home"). Do that and the dbg statement will always work.
so talking to Panos about this earlier, the debugger is currently working as-designed with respect to loading the intro HTML page.

If there are no inlined scripts in the page, the Debugger doesn't know about it until referenced.

There may be a problem in some cases with an initial debugger statement getting missed if it's called very early in a page's lifecycle. This is a bug (and Panos was going to go looking for a dupe of that).

Not much else I can do here without more details, unfortunately.
Assignee: rcampbell → nobody
Last night, late, way later than it should have been due to this set of debugger bugs, I had code like this:

function x(blah) { debugger;
  // do stuff
  debugger;
  // do more stuff
}

This function is attached to a var, Y, hanging of window/global created via an IIFE executed alongside jQuery startup (doc-ready).  Neither dbgr statement was hit.  Other dbgr statements in sibling functions *were* hit.  "do stuff" and "do more stuff" worked (so the code was executed). I set breakpoints set in that function, too - they were missed too.
"This page has no sources" still present in FF25.  Reopen devtools having closed them with debugger forward works (no longer need to close the browser from earlier workarounds).
Still happens in 26 at times.
And it's still there in 29.0a1(2013-12-19)
We need some concrete steps to reproduce if we are going to fix this bug.
@Panos: I know. If you can help me to help you, I'm ready, willing and able.  What I can't provide is a simple case, or a URL.  What seems most clear, this bug is likely not to appear building a trivial web page for Aunt Betty to display her collection of stuffed animals. :/
Panos/Rob:

Having just stumbled across bug 944261 (and the related 944260 and 944258) I'm personally filing this bug as blocked by those.  Having no way to prove the case myself, Panos/Rob I'll leave it to you guys to review and advise...

bug 944261 sounds like it describes so much of the weirdness I see with a script-heavy site.
Bug 944261 is precisely what I had in mind when making the "working as-designed" comment in comment 15. If that is indeed your case, I would recommend resolving this bug, as that is a kind of large-scale change that I don't expect to happen any time soon. But feel free to keep the bug around and mark it as dependent on bug 944261 if you prefer.
I don't think you were referring to C15... not here anyway
I was referring to the discussion I had with Rob that was mentioned here:

(In reply to Rob Campbell [:rc] (:robcee) from comment #15)
> so talking to Panos about this earlier, the debugger is currently working
> as-designed with respect to loading the intro HTML page.
ha. got it.

I wish there was a way I could *prove* this suspicion... then I'd be happy to close this bug.
I'm seeing this issue with Firefox 26.0 while trying to debug a page being served over HTTP from localhost with WEBrick on OSX 10.8.5. This just appeared today and neither refreshing nor restarting Firefox seems to help. However, after restarting my server and closing and reopening the debugger I now see the sources.
That is very odd. Any errors in the browser console perhaps? Could you provide us with a simple version of your page to reproduce it? Do you have that particular page hosted somewhere that we could run some tests for a while?
Unfortunately, I don't think I can provide any code, I'm working on an internal application. I can say that its written using the Rails' asset pipeline (sprockets) to compile coffeescript and WEBrick as the web server. Perhaps you can reproduce with a freshly generated Rails project with some added coffeescript?
FWIW, following my (extended) STR in comment 3, I cannot reproduce this bug in FF 27 (current beta)
Patrick - see if you can repeat the problem with cnn.com.  It's a pretty heavy user of script.
Russ - It's not happening with cnn.com
Also, I know that the scripts were being loaded because the components that depend on the scripts were working, and the server log corroborates.
Yep - I feel your pain... that's pretty much what I was seeing.
This seems to be one of those issues that usually goes away when you reload the page. I have reported similar issues with the debugger that are oddly intermittent, while loading the page (Bug 961437, and Bug 965263, which I've only noticed 2 or 3 times).

I remember when doing a Java network-packet-based project some time ago, it would sometimes fail and give exceptions maybe <10% of the time, and I fixed it with a synchronized() block.

I'm no expert at how the Devtools work internally, but I'd be curious to know if there is somethign similar to how Java and other languages use thread-locks, in Javascript, and is this used in Firefox Devtools?
Flags: needinfo?
Luke, the bugs you mentioned are not related to this bug, one is about the profiler and the other is about pretty-printing. The core issue with the source pane in the debugger coming up empty is the sensitivity of the low-level APIs to GC, as explained in bug 944261. This is the only case I know of that is not properly handled (or, more accurately, handled in an intuitive way), but that is not an easy thing to fix. It should also be easily worked around by reloading the page in most cases while the debugger is open.

Besides comment 27, everything else in this bug can probably be attributed to this GC-sensitive behavior. Thank you all for contributing to this bug report, but unfortunately there is not enough actionable information for us to work with, so unless someone can soon come up with a way to reproduce the bug in a public-facing site (or briefly provide us with access to a restricted site), I'm afraid I will have to close the bug as INCOMPLETE and hope that bug 944261 and related ones will eventually resolve every issue described here.
Flags: needinfo?
FF29 DevTools debugger > remote debugging on Android: affected
Here's a Browser Console stack trace, hope it helps.

error occurred while processing 'attach: TypeError: can't access dead object
Stack: TA__addDebuggees@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:587
TA_findGlobals@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:602
TA_onAttach@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:680
DSC_onPacket@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js:1019
@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/transport.js:258
@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/DevToolsUtils.js:75
 main.js:924

 Server did not specify an actor, dropping packet: {"error":"unknownError","message":"error occurred while processing 'attach: TypeError: can't access dead object\nStack: TA__addDebuggees@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:587\nTA_findGlobals@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:602\nTA_onAttach@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:680\nDSC_onPacket@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js:1019\n@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/transport.js:258\n@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/DevToolsUtils.js:75\n"} dbg-client.jsm:655
Luke, which version of Firefox is this? Do you get this error on Firefox Nightly?
Duplicate of this bug: 969912
Sometimes the source shows up, but breakpoints cannot be set (blue dot - yes; real breakpoint - no).
The problem seems to have to do with special words used as function names. In the following short HTML-page the function name "toString" is the culprit - if changed to e.g. "toStr" everything is o.k. .

<html>
	<head><meta charset="utf-8"></head>
	<body>
		<script>
			console.log( "Error: " + toString( { x: 0, y: 0 } ) );
			function toString(v) { return "[ " + v.x + ", " + v.y + " ]"; }
		</script>
	</body>
</html>
Thank you Jürgen, this is definitely a bug!
Assignee: nobody → past
Status: REOPENED → ASSIGNED
Opening the debugger on this page causes an error somewhere in ThreadActor.prototype.onAttach:

DBG-SERVER: Received packet 5: {
  "to": "conn0.context62",
  "type": "attach",
  "options": {
    "useSourceMaps": true
  }
}
DBG-SERVER: v is undefined:
toString@file:///Users/past/Desktop/toString.html:6

DBG-SERVER: Packet 7 sent from "conn0.context62"
DBG-SERVER: Received packet 6: {
  "to": "conn0.trace32",
  "type": "attach"
}
DBG-SERVER: Packet 8 sent from "conn0.trace32"
DBG-SERVER: Received packet 7: {
  "error": "notAttached",
  "message": "TypeError: v is undefined",
  "from": "conn0.context62"
}
Attached patch v1 (obsolete) — Splinter Review
This patch fixes the problem.
Attached patch v2 (obsolete) — Splinter Review
Now with test. Try: https://tbpl.mozilla.org/?tree=Try&rev=f8761815ba00
Attachment #8376355 - Flags: review?(vporof)
Attachment #8376324 - Attachment is obsolete: true
@Panos: Shouldn't comment 41 be logged separately? Sounds like a completely different issue, to me.
Well, it does result in the same behavior (an empty source list) and it's the only actionable information I've seen in this bug so far. My hope is that it might fix the issues some of the others were experiencing, assuming it's not just a case of bug 944261.
Comment on attachment 8376355 [details] [diff] [review]
v2

Review of attachment 8376355 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM, r+ assuming all other tests still pass.

::: browser/devtools/debugger/test/doc_global-method-override.html
@@ +2,5 @@
> +     http://creativecommons.org/publicdomain/zero/1.0/ -->
> +<!doctype html>
> +
> +<html>
> +	<head>

Nit: might want to align the <head> with </head> (or indent using spaces).
Attachment #8376355 - Flags: review?(vporof) → review+
Attached patch v3Splinter Review
(In reply to Victor Porof [:vporof][:vp] from comment #48)
> Nit: might want to align the <head> with </head> (or indent using spaces).

Oops!
Attachment #8376355 - Attachment is obsolete: true
Try was green. Landed:
https://hg.mozilla.org/integration/fx-team/rev/9eb23b6b7f4b
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/9eb23b6b7f4b
Status: ASSIGNED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 30
Status: RESOLVED → VERIFIED
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.