|Summary:||Web Inspector: support workers inspection|
|Product:||WebKit||Reporter:||Yury Semikhatsky <yurys>|
|Component:||Web Inspector (Deprecated)||Assignee:||Yury Semikhatsky <yurys>|
|Severity:||Normal||CC:||apavlov, bburg, bweinstein, dimich, joepeck, keishi, loislo, mike, pfeldman, pmuellr, rik, yurys|
|Version:||528+ (Nightly build)|
|Bug Depends on:||58552, 58668, 59320, 59323, 60159, 60267, 61853, 62019, 63258, 63942, 64519, 70815, 73019, 73069, 73070|
Description Yury Semikhatsky 2011-04-14 07:33:30 PDT
Web Inspector now supports fake workers that allow to execute worker scripts in iframes inside the inspected page. This enables debugging of worker scripts using existing inspector infrastructure. Although fake workers work well in many cases we still need to support inspection of native workers. This is supposed to be an umbrella bug for workers inspector. Current plan is the following: Each worker context will have its own WorkerInspectorController that will hold a set of agents suitable for the worker inspection. We should reuse as much of the page inspector agents as possible but not all of the existing agents are applicable to the web workers(e.g. there is no DOM tree in worker so it's no use creating InspectorDOMAgent for it). WorkerInspectorController will be a counterpart of InspectorController used for Page inspection and will communicate with the corresponding InspectorController in the Page that has created the worker(it's a bit more complicated for shared workers). As a first step we are going to have one Web Inspector window per inspected worker. From the user stand point it should be like this: Web Inspector enumerates all existing workers and allows to open inspector on each of them. Also it should be possible to pause newly created workers to allow user to decide whether to open inspector for it or no. This is needed to support debugging from very beginning of the worker script execution. When user selects which worker to inspect the front-end opens another Web Inspector window for the inspected worker. Under the hood the Page's inspector front-end sends a command to its backend to start inspecting the worker. Then the backend's InspectorController handles the command and notifies corresponding WorkerInspectorController that it should activate its agents and start communicating with the InspectorController. After that all messages from WorkerInspectorController will be forwarded to the Page's inspector front-end that in turn will forward them to the corresponding worker front-end window. As a second step we are going refactor current inspector front-end to accommodate inspected workers along with the inspected page.