758663 - Second JS file not shown in debugger dropdown for file:// URL

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[Osmose [:osmose, :mkelly]]

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

[Osmose [:osmose, :mkelly]]

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 (he/him) [:past] (please ni?)]

(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)]

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

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

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

I should've mentioned this in comment 5: none of the scrips are displayed in the dropdown (It shows "No scripts.").

Comment 8

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

Attachment: 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]]

It should be noted that in my bug it it also fails from viewing from a server.

Comment 11

[Jim Blandy :jimb]

(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]

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 (he/him) [:past] (please ni?)]

(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 (he/him) [:past] (please ni?)]

(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 (he/him) [:past] (please ni?)]

Bug 783393 should fix this one, too.

Comment 16

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

Verified that the patch in bug 783393 fixes this.