890269 - Frontend should be able to handle duplicate scripts

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

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

In chrome debugging a script can be loaded in more than one compartment, appearing as separate scripts. For instance when using the browser debugger I got 2 instances of promises.js:

{
  "actor": "conn1.source158",
  "url": "resource://gre/modules/commonjs/sdk/core/promise.js",
  "isBlackBoxed": false
},
{
  "actor": "conn1.source258",
  "url": "resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/core/promise.js",
  "isBlackBoxed": false
}

The server is correctly sending both scripts, but the client only displays one due to the unique constraint enforced by the script list widget. The problem is that even though the content of both scripts is the same, the stack frames we get can be from either URL, so that pausing in that script may fail to highlight the right source and line, depending on which script made it into the script list widget and which URL the frame is from.

We should use the relaxed flag on the SideMenuWidget and see if any more fixes are needed in getSourceGroup and getSourceLabel.

Comment 1

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

This is arguably a duplicate of bug 784112, but I think we can easily fix this case without worrying about the broader issue of targeting the debugger to specific iframes that lies in that bug.

Comment 2

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

Mid Air! :)

If we're going to relax the widget, then some special handling should be done to make sure the two sources don't appear under the same label. Currently, the generated label doesn't take the former url part into consideration. [0]

If the contents of the two scripts are the same, another course of action would be to simply handle the two urls as being equivalent (as far as the frontend cares) and select whichever source was accepted [1]. If I'm not mistaken, this should be as simple as just splitting by " -> " whenever handling the url specified by a frame.

[0] http://dxr.mozilla.org/mozilla-central/source/browser/devtools/debugger/debugger-panes.js#l105
[1] http://dxr.mozilla.org/mozilla-central/source/browser/devtools/debugger/debugger-view.js#l327

Comment 3

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

(In reply to Victor Porof [:vp] from comment #2)
> If the contents of the two scripts are the same, another course of action
> would be to simply handle the two urls as being equivalent (as far as the
> frontend cares) and select whichever source was accepted [1]. If I'm not
> mistaken, this should be as simple as just splitting by " -> " whenever
> handling the url specified by a frame.

I thought about that, but forgot to mention that in this case setting breakpoints probably won't work: there is no way to specify the other URL and depending on the case, that may be exactly the one you want to pause in. Some experimentation to validate my assumption is warranted though.

Comment 4

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

(In reply to Panos Astithas [:past] from comment #3)
> I thought about that, but forgot to mention that in this case setting
> breakpoints probably won't work: there is no way to specify the other URL
> and depending on the case, that may be exactly the one you want to pause in.
> Some experimentation to validate my assumption is warranted though.

You're totally right.

Comment 5

[Brandon Benvie [:benvie]]

I think the problem is worse than what is indicated above. It's not just duplicates of the same script, it's any two scripts with the same name, even if they're located in different folders. 

If that is the case, this is causing problems for chrome debugging in remote targets (at least metrofx anyway) since there's multiple chrome scripts named "browser.js". Only the first one (the less important one) shows up in the list, despite them being in different folders. I have confirmed that both of the files are sent in the "sources" array, so it's not a protocol/server issue.

Comment 6

[Brandon Benvie [:benvie]]

I take it back! I found it, it's listed under content/browser.js. False alarm, back to your regularly scheduled bug.

Comment 7

[David Walsh :davidwalsh]

We handle duplicate URLs in the new debugger :)