Frontend should be able to handle duplicate scripts

NEW
Unassigned

Status

P3
normal
5 years ago
15 days ago

People

(Reporter: past, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [chrome-debug])

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.
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.
See Also: → bug 784112
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
(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.
(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.
Priority: -- → P3
Depends on: 897191
Blocks: 897191
No longer depends on: 897191
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.
Priority: P3 → P1
I take it back! I found it, it's listed under content/browser.js. False alarm, back to your regularly scheduled bug.
Priority: P1 → P3
No longer blocks: 897191

Updated

4 years ago
Summary: Debugger front-end should be able to handle duplicate scripts → Frontend should be able to handle duplicate scripts

Updated

4 years ago
Blocks: 1074592

Updated

4 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.