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

RESOLVED FIXED

Status

()

Firefox
Developer Tools: Debugger
P3
normal
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: mkelly, Unassigned)

Tracking

15 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 1

5 years ago
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
(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?
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.
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

5 years ago
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.
OS: Mac OS X → All
Hardware: x86 → All

Comment 6

5 years ago
I should've mentioned this in comment 5: none of the scrips are displayed in the dropdown (It shows "No scripts.").
Duplicate of this bug: 765927
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.
It should be noted that in my bug it it also fails from viewing from a server.
Priority: -- → P3
Duplicate of this bug: 767396

Comment 11

5 years ago
(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

5 years ago
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.
(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.
(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.
Bug 783393 should fix this one, too.
Depends on: 783393
Verified that the patch in bug 783393 fixes this.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.