It is unclear whether telemetry/protocol is the best way of testing these. We might want another type of the browser perf tests for testing "interactive browser resize", "open/close browser windows" and "tab dragging".

I share the same sentiment with Pavel in #2. Before jumping into a specific method of benchmarking these, we should discuss all the options & their cons & pros.

For interactive browser resize (and the other ones you mention): is the concern that these tests would need to interact with the system in a way that doesn't allow running multiple tests at the same time (because the tests depend on system focus/capture etc.)? i.e. that these tests would need to run essentially as interactive tests? Because if that is the concern, then I think, at least on chromeos (where we want this to work first), it wouldn't be problematic.

We discussed offline with pfeldman@ and dgozman@. I believe we agreed on the following:
 . Since we are trying to test chrome-specific features, we want to start with an API that makes it obvious. So it needs to be difficult to accidentally use the API (e.g. the API should be behind a flag, etc.). And the protocol should not live in browser_protocol.json in WebKit.

 . It's better to have more generic API, than very specific APIs. Telemetry tests are run on ToT builds, and on stable builds. So the API would need to backwards compatible to at least one stable version. The more generic the API is, the easier it is going to be to maintain.

 . It would be possible for the telemetry test to communicate directly to the mus-ws process. But, to start off, this is going to go through the browser process (which, in turn, would be responsible for communicating as appropriate with mus-ws).

 . Use existing telemetry API where possible (e.g. there's existing API for creating/closing/selecting new tabs, so we should use those instead of introducing new ones).

+1 to making a single generic browser API that can simulate many different browser UI gestures. 

Once that exists, you can add add many Telemetry API (or reuse existing ones) that you like, e.g: browser.CreateNewTab, browser.ResizeWindow,...

We want to start with a chrome-specific API, so that we can experiment with what works best for us, before working on a generic browser API that covers all the cases. We understand that it means we need to keep the API backward-compatible to the stable-branch, and we are willing to do that. Does that sound reasonable?

Is there any kind of design doc around this? (Also, adding Elly for Mac)

There's no design-doc, but there were some initial implementations [1, 2] that we didn't end up upstreaming (for a lack of resources). There's also the proposal to use native-tests for performance work [3].

[1] https://chromium-review.googlesource.com/c/catapult/+/1000173
[2] https://chromium-review.googlesource.com/c/chromium/src/+/984858
[3] https://docs.google.com/document/d/1Ar8JZjJH5KU-Zodcz0Rtthhi9cGmi0NKI0ZQVobGZvg/edit

To note here, the current devtools api does not provide a way for catapult to determine the browser window ids. Which would be needed to properly link [1] & [2] in #19