901930 - DevTools Debugger fails to find sources

Status: VERIFIED FIXED

(DevTools :: Debugger, defect, P2)

Description

[Codacoder]

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.

Comment 1

[[:Aleksej]]

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".

Comment 2

[Simona Badau, Desktop QA]

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.

Comment 3

[Codacoder]

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.

Comment 4

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

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.

Comment 5

[Codacoder]

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.

Comment 6

[Codacoder]

This bug has NOT appeared since updating to firefox 23.0.1

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

Marking as WORKSFORME then based on your last comment. Please reopen if you can reproduce it again.

Comment 8

[Rob Campbell [:rc] (:robcee)]

Russ reporting that this has returned in Fx26, currently in Aurora.

Comment 9

[Rob Campbell [:rc] (:robcee)]

taking this for testing.

Comment 10

[Rob Campbell [:rc] (:robcee)]

Russ, trying to test this but without a url this is not easy.

Are you loading from file: uri by any chance?

Comment 11

[Codacoder]

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

Comment 12

[Rob Campbell [:rc] (:robcee)]

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.

Comment 13

[Rob Campbell [:rc] (:robcee)]

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.

Comment 14

[Codacoder]

> 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.

Comment 15

[Rob Campbell [:rc] (:robcee)]

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.

Comment 16

[Codacoder]

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.

Comment 17

[Codacoder]

"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).

Comment 18

[Luke]

Still happens in 26 at times.

Comment 19

[Codacoder]

And it's still there in 29.0a1(2013-12-19)

Comment 20

[Panos Astithas (he/him) [:past] (please ni?)]

We need some concrete steps to reproduce if we are going to fix this bug.

Comment 21

[Codacoder]

@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. :/

Comment 22

[Codacoder]

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.

Comment 23

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 24

[Codacoder]

I don't think you were referring to C15... not here anyway

Comment 25

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 26

[Codacoder]

ha. got it.

I wish there was a way I could *prove* this suspicion... then I'd be happy to close this bug.

Comment 27

[Patrick Canfield]

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.

Comment 28

[Panos Astithas (he/him) [:past] (please ni?)]

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?

Comment 29

[Patrick Canfield]

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?

Comment 30

[Codacoder]

FWIW, following my (extended) STR in comment 3, I cannot reproduce this bug in FF 27 (current beta)

Comment 31

[Codacoder]

Patrick - see if you can repeat the problem with cnn.com.  It's a pretty heavy user of script.

Comment 32

[Patrick Canfield]

Russ - It's not happening with cnn.com

Comment 33

[Patrick Canfield]

Also, I know that the scripts were being loaded because the components that depend on the scripts were working, and the server log corroborates.

Comment 34

[Codacoder]

Yep - I feel your pain... that's pretty much what I was seeing.

Comment 35

[Luke]

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?

Comment 36

[Panos Astithas (he/him) [:past] (please ni?)]

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.

Comment 37

[Codacoder]

FF29 DevTools debugger > remote debugging on Android: affected

Comment 38

[Luke]

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

Comment 39

[Panos Astithas (he/him) [:past] (please ni?)]

Luke, which version of Firefox is this? Do you get this error on Firefox Nightly?

Comment 41

[Jürgen Ahting]

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>

Comment 42

[Panos Astithas (he/him) [:past] (please ni?)]

Thank you Jürgen, this is definitely a bug!

Comment 43

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: Test page exhibiting the bug

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"
}

Comment 44

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: v1

This patch fixes the problem.

Comment 45

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: v2

Now with test. Try: https://tbpl.mozilla.org/?tree=Try&rev=f8761815ba00

Comment 46

[Codacoder]

@Panos: Shouldn't comment 41 be logged separately? Sounds like a completely different issue, to me.

Comment 47

[Panos Astithas (he/him) [:past] (please ni?)]

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 48

[Victor Porof [:vporof][:vp]]

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).

Comment 49

[Panos Astithas (he/him) [:past] (please ni?)]

Attachment: v3

(In reply to Victor Porof [:vporof][:vp] from comment #48)
> Nit: might want to align the <head> with </head> (or indent using spaces).

Oops!

Comment 50

[Panos Astithas (he/him) [:past] (please ni?)]

Try was green. Landed:
https://hg.mozilla.org/integration/fx-team/rev/9eb23b6b7f4b

Comment 51

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/rev/9eb23b6b7f4b

Comment 52

[radovan.obal]

This is still an issue on 84.0 (64-bit) for Ubuntu

Comment 53

[Marooned]

Windows 7, 84.0.1 (64 bit), the same. No sources in Debugger tab in console.

Comment 54

[Julian Descottes [:jdescottes]]

This bug was closed 7 years ago and the Debugger changed significantly since then.
In general comments on already closed bugs tend to be missed.

radovan.obal, Marooned: A new bug was recently filed about a similar issue: Bug 1687416. Can you comment there with more details about the issue? Especially if you have a publicly accessible page where we can reproduce the issue. If/when you get the issue, could you also open the Browser Console (Tools > Web Developer > Browser Console) and share any errors you might see there.

Thanks.