Simplify targetFilter

[stristr]

For background, see conversation beneath #623, which was merged and then reverted via 7c1865b.

Although a more robust configuration-based option whitelisting target types is a valid approach, I did note that:

• Since we already pass falsy "type" through the filter, we aren't being very strict about this field to begin with.
• Imitating the chrome://inspect/#devices tab feels most correct—if there is a webSocketDebuggerUrl available, then we can attach, and if there isn't, then we can't. This has the added benefit of not showing targets that already have a debugger attached (an improvement over chrome://inspect/#devices IMO, which provides a link to "inspect" which doesn't work if there is already a debugger attached).

(I encountered this problem trying to debug Electron <webview>s, which have "type": "webview" in the debugger manifest, but #623 has some other good examples.)

[msftclas]

All CLA requirements met.

[roblourens]

This doesn't help the basic issue, which is that this extension is optimized for debugging Chrome, and 99% of users need to attach to a page. With this change, lots of people will end up attached to
a random extension background page or service worker which is not what they want. I'm open to allowing advanced users to set up a config to attach to other types of targets, but I don't want to compromise the core experience.

[stristr]

Hey @roblourens, thanks for the quick feedback—I booted into the core experience, and yeah, agree it's a bit much when you have a couple of browser extensions.

As an alternative to an advanced config, did you consider whitelisting more types?

I was thinking:

• "app"
• "iframe"
• "page"
• "webview"

This wouldn't exactly help users who want to debug browser extensions, but it would probably fix things for 90% of the 1% of us who are trying to attach to something other than a page without accidentally picking up browser extensions.

I'm willing to PR the more advanced config if you feel like it's necessary…just seemed like a lot of overhead for something that just works in IntelliJ.

[roblourens]

I would be ok with a list of extra allowed types in the launch config. This is what #623 tried to do, it just didn't work.

[roblourens]

How does IntelliJ work with multiple targets?

[stristr]

Re: IntelliJ, configuration looks like this, and when activated you're presented with a picker like this. Not saying this is a great UX either—but it does take the route of presenting everything that the user might want to debug and letting them choose. (I have always figured developers who even know what a debugger is and how to use one as power users.)

Re: my suggestion, to be clear, I was proposing a broader set of sensible default debug targets to whitelist, separate from the proposal to let the user change those defaults with a launch config option. (Mainly because changing the defaults is a one-line change, and adding a config option requires two dependent PRs in vscode-chrome-debug and vscode-chrome-debug-core.)

[roblourens]

Thanks, I feel like going through a picker like IntelliJ's every time I want to start debugging is a mess. 99% of users will just want to attach to their page.

I understand the suggestion, I still don't want to change the defaults away from the one common case that I'm optimizing for.

[stristr]

K, got it. Will take a stab at the more flexible solution when time permits.