Dies ist ein bisschen eine theoretische versuchte Antwort, da ich noch keinen Code geschrieben habe, um diese Idee zu testen.
Im Protokoll befindet sich die Domäne Target, die Worker-Ereignisse behandeln soll. Ich brauchte eine Weile, um es herauszufinden. Ich bemerkte eine old fork der Chrome Debugging Protocol Viewer, die eine Worker Domäne hatte, aber es ist nicht in der Live-eins. Ich fand später in der commits, dass es in die Domain Target zusammengeführt worden war, die für mich nicht sofort offensichtlich war.
Das Ereignis targetCreated ist wahrscheinlich das Ereignis, das auf neue Worker-Instanzen wartet. Dies stellt das TargetInfo Objekt in seinem Callback bereit, das die targetId, und eine type hat, mit einem Wert, der wahrscheinlich in etwa wie 'Web Worker' oder 'Worker' aussieht (insgesamt aber raten).
Sie können dann an den Worker-Prozess mit der attachToTarget-Methode anhängen und die targetId bereitstellen. Bei einer erfolgreichen Verbindung können Sie dann Nachrichten an sie senden. In Ihrem Fall könnten Sie einen Befehl senden, der auf das scriptParsed-Ereignis wartet, wobei der Rückruf der Debugger.setScriptSource ist.
Ich bin nicht sicher über das Timing all dieser Ereignisse. Es ist durchaus möglich, dass all dies zu spät geschieht, aber die Idee ist einen Versuch wert.
Ich werde ein Spiel mit diesem wenn ich einen Moment habe. Wenn es funktioniert, werde ich etwas darüber veröffentlichen. Wenn nicht, wird weiter untersucht.
Dies sollte die richtige Antwort sein, leider kann ich es nicht mit Chrome 53 arbeiten lassen (muss Electron verwenden). Ich habe Target.enable und Target.setDiscoverTargets et al. Ausprobiert, aber keine Events bekommen. Vielleicht funktioniert eine neuere Chrome-Version, die ich noch nicht testen konnte. Der Mangel an Dokumentation ist jedoch etwas seltsam, da das Protokoll und sein Viewer auf einer JSON-Spezifikation basieren sollten. Wenn das Feature vorhanden ist, sieht es nicht produktionsbereit aus. – Pat