Bug 147069 - Add an option to run-webkit-tests to wait for a connected remote inspector frontend before running
Summary: Add an option to run-webkit-tests to wait for a connected remote inspector fr...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on: 147068
Blocks: InspectorDebug
  Show dependency treegraph
Reported: 2015-07-18 14:00 PDT by Brian Burg
Modified: 2017-01-18 23:38 PST (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Brian Burg 2015-07-18 14:00:53 PDT
This bug is too big for one patch, but I'll put all my notes here until I actually start making progress.


Everyone wastes a lot of time adding logging to layout tests to debug what's going on. Simply using the web inspector would make simple mistakes very obvious and save unnecessary logging. Debugging a layout test in this way should be as simple as passing an extra flag to run-webkit-tests to make the test runner hold off until an inspector is attached by the developer.

Even if a test page under WebKitTestRunner can be remote inspected, it won't be much good unless a developer can attach the Web Inspector before the test() method starts to run. This is typically attached to the test page's "load" event.

To do this in WKTR, there needs to be some sort of notification available to its InjectedBundle that an inspector frontend has been connected or not, and whether its local (part of the test) or remote (developer-initiated).

Connecting the frontend is performed in the various InspectorController classes. These connection events are not currently propagated up into WK2, but it would be easy to do so using InspectorClient. Similarly, there are no relevant events in any bundle client, so these events would need to be added to a new or existing bundle client so WKTR can get at them.

Inspecting a layout test that uses the web inspector will be a bit more complicated, because there is only a single FrontendConnection per inspected page. We would need to add a second 'diagnostic' frontend connection and revisit code that assumes there's only one frontend open at a time. For the most part, it seems that events would be duplicated to all frontends and command responses would be threaded to the originating connection.