Last Comment Bug 758663 - Second JS file not shown in debugger dropdown for file:// URL
: Second JS file not shown in debugger dropdown for file:// URL
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Developer Tools: Debugger (show other bugs)
: 15 Branch
: All All
: P3 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 765927 767396 (view as bug list)
Depends on: 783393
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-25 09:10 PDT by Michael Kelly [:mkelly,:Osmose]
Modified: 2012-08-24 02:59 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testfile (197 bytes, text/html)
2012-06-19 00:39 PDT, Panos Astithas [:past]
no flags Details

Description Michael Kelly [:mkelly,:Osmose] 2012-05-25 09:10:27 PDT
Tested on Nightly 15.0a1 (2012-05-25).

Lots of weird things happen with the JS file dropdown in the debugger UI when working on files locally with file:// URLs.

Specifically, the attached page has two external JS files, but only the first one (test1.js) is shown in the dropdown for selecting which file to debug. Both files are shown correctly when tested on a server: see http://people.mozilla.org/~mkelly/debugger/missing_file/

Steps to Replicate:

1. Open index.html locally via a file:// URL.
2. Open the Debugger Panel.
3. Check the JS file dropdown.

Expected:
Both test1.js and test2.js show up in the dropdown.

Actual: Only test1.js shows up.
Comment 1 Michael Kelly [:mkelly,:Osmose] 2012-05-25 09:13:10 PDT
D'oh, can't attach a zip file, but you can download the files at the URL above or via this zip file:

http://people.mozilla.org/~mkelly/debugger/missing_file.zip
Comment 2 Panos Astithas [:past] 2012-05-25 10:51:14 PDT
(In reply to Michael Kelly [:mkelly] from comment #0)
> Actual: Only test1.js shows up.

In my testing, none of the two scripts shows up, locally. This is an extreme corner case, to be fair: these scripts are finished executing before the page even loads. It's a race actually. It seems that after a page reload with the debugger open, they finish even before the debugger can handle the DOMWindowCreated event. In your case the debugger gets a chance to ask for the scripts before one of them is GC'd.

I'm not sure what we could do in this case. Jim, Jason, any ideas?
Comment 3 Rob Campbell [:rc] (:robcee) 2012-05-29 06:41:27 PDT
I'm kind of the opinion that we should retain all scripts in the debugger. Same for evald scripts, if only as a reference and a placeholder for us to set breakpoints after we've reloaded.
Comment 4 Victor Porof [:vporof][:vp] 2012-06-14 09:33:00 PDT
This is pretty weird. In my testing (a while ago), I used to get both of the scripts every time. However, with the latest Aurora (15.0a2 (2012-06-14)), I never get the scripts at all, as Panos mentioned in comment #2. Same happens on the latest fx-team and m-c.
Comment 5 Ioana (away) 2012-06-15 01:19:18 PDT
Also reproducible on the latest Nightly (2012-06-14):
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/16.0 Firefox/16.0a1.
Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/16.0 Firefox/16.0a1

This issue reproduces on all Mac OSs, 32-bit and 64-bit, and also on Ubuntu. I couldn't reproduce it on any Windows platforms though.
Comment 6 Ioana (away) 2012-06-15 01:47:07 PDT
I should've mentioned this in comment 5: none of the scrips are displayed in the dropdown (It shows "No scripts.").
Comment 7 Panos Astithas [:past] 2012-06-19 00:36:58 PDT
*** Bug 765927 has been marked as a duplicate of this bug. ***
Comment 8 Panos Astithas [:past] 2012-06-19 00:39:21 PDT
Created attachment 634313 [details]
testfile

bdahl's test file from bug 765927 is slightly more interesting. His STR:

1) Open debugger
2) Open test file
3) Observe that the scripts drop down is empty.
4) Further observe the debugger line does not trigger a break point.

The issue is the same of course.
Comment 9 Brendan Dahl [:bdahl] 2012-06-19 08:44:32 PDT
It should be noted that in my bug it it also fails from viewing from a server.
Comment 10 Panos Astithas [:past] 2012-07-06 04:27:30 PDT
*** Bug 767396 has been marked as a duplicate of this bug. ***
Comment 11 Jim Blandy :jimb 2012-07-06 14:00:17 PDT
(In reply to Panos Astithas [:past] from comment #2)
> (In reply to Michael Kelly [:mkelly] from comment #0)
> > Actual: Only test1.js shows up.
> 
> In my testing, none of the two scripts shows up, locally. This is an extreme
> corner case, to be fair: these scripts are finished executing before the
> page even loads. It's a race actually. It seems that after a page reload
> with the debugger open, they finish even before the debugger can handle the
> DOMWindowCreated event. In your case the debugger gets a chance to ask for
> the scripts before one of them is GC'd.
> 
> I'm not sure what we could do in this case. Jim, Jason, any ideas?

So, is the story here that a script gets loaded into a page, runs in the page's context, and is GC'd before the debugger gets a chance to see it?

I guess the underlying problem here is that the newScript notification doesn't give the debugger a chance to do anything. It's not a pause.
Comment 12 Jim Blandy :jimb 2012-07-06 15:04:37 PDT
This is kind of interesting. The "scripts" request should probably return all the URLs for all scripts that were ever evaluated on the page --- not just the ones currently live --- because you might want to set a breakpoint on any of them.
Comment 13 Panos Astithas [:past] 2012-07-08 00:32:35 PDT
(In reply to Jim Blandy :jimb from comment #12)
> This is kind of interesting. The "scripts" request should probably return
> all the URLs for all scripts that were ever evaluated on the page --- not
> just the ones currently live --- because you might want to set a breakpoint
> on any of them.

Although making newScript pause the debuggee sounds interesting, I think this would be the best option like Rob suggested in comment 3.
Comment 14 Panos Astithas [:past] 2012-07-08 01:49:32 PDT
(In reply to Panos Astithas [:past] from comment #13)
> (In reply to Jim Blandy :jimb from comment #12)
> > This is kind of interesting. The "scripts" request should probably return
> > all the URLs for all scripts that were ever evaluated on the page --- not
> > just the ones currently live --- because you might want to set a breakpoint
> > on any of them.
> 
> Although making newScript pause the debuggee sounds interesting, I think
> this would be the best option like Rob suggested in comment 3.

On second thought, I'm not sure if this will make a big difference for this problem. Unless the debugger can add the page window as a debuggee before the scripts execute, there is not much that can be done with them, except adding them to the script list. Maybe the previous workaround to the missing findScripts from bug 697040 is all we need.
Comment 15 Panos Astithas [:past] 2012-08-20 04:58:51 PDT
Bug 783393 should fix this one, too.
Comment 16 Panos Astithas [:past] 2012-08-24 02:59:16 PDT
Verified that the patch in bug 783393 fixes this.

Note You need to log in before you can comment on or make changes to this bug.