feature(trace-viewer): embedded mode support PoC #30885

ruifigueira · 2024-05-18T00:46:14Z

Companion PR of microsoft/playwright-vscode#483

pavelfeldman · 2024-05-21T19:11:46Z

I'm supportive for those, let me know when they are no longer drafts!

ruifigueira · 2024-05-21T20:31:24Z

@pavelfeldman I removed the draft, but this is still a very basic implementation just to check if the integration was possible.

I found out some issues with this approach: when the trace viewer iframe gets the focus keyboard shortcuts stop working, and I ned to click outside it to open the command palette for instance.

pavelfeldman · 2024-05-22T23:07:43Z

I found out some issues with this approach: when the trace viewer iframe gets the focus keyboard shortcuts stop working, and I ned to click outside it to open the command palette for instance.

That's unfortunate! I was rendering webviews in vscode w/o such issues. Is iframe w/ snapshot breaking it? How is service worker doing, are snapshots rendered fine?

ruifigueira · 2024-05-22T23:19:43Z

I tried to render the trace viewer html directly without iframe and service worker doesn't work there. Nevertheless, we can just rely on the running server instead of the service worker. The only thing I still need to figure out is on how to make the websocket work, or if not possible, on how to emulate it.

pavelfeldman · 2024-05-23T23:38:37Z

we can just rely on the running server instead of the service worker.

Unfortunately, we can't. It is essential for SW to fulfill all the requests.

ruifigueira · 2024-05-24T00:21:40Z

I am figuring that out the hard way :( I was doing some quick and dirty tests and deactivated the sw to rely on the webserver. I thought it was already handling trace requests as a fallback, but it was not, so I had to copy & paste the service worker logic there with necessary adjustments for it to work, but I stumbled on cross-domain snapshot resources that are handled by the sw and I don't see a way out of that...

I'll go back to the iframe solution and see if there's a workaround for it.

ruifigueira · 2024-05-24T00:56:02Z

Problem explained here, with a workaround proposal:

microsoft/vscode#65452 (comment)

ruifigueira · 2024-05-24T02:06:36Z

That did the trick, key bindings are triggered as expected when trace viewer is focused

packages/playwright-core/src/server/trace/viewer/traceViewer.ts

pavelfeldman · 2024-05-24T19:50:03Z

packages/trace-viewer/src/index.tsx

@@ -39,5 +39,26 @@ import { WorkbenchLoader } from './ui/workbenchLoader';
    setInterval(function() { fetch('ping'); }, 10000);
  }

+  if (window.parent !== window && new URL(window.location.href).searchParams.has('embedded')) {


Can we do this when we are building the content for the trace viewer instead in the extension instead?

Unfortunatelly no, because this code must run inside the iframe. But maybe create an embedded.html / embedded.tsx, similar to index.tsx and uiMode.tsx, we can just drop this code there as well as instanciating the parameterized WorkbenchLoader

Unfortunatelly no, because this code must run inside the iframe.

I understand that the snapshot renderer should run in an iframe, but the app itself does not have to. Are you doing this for convenience?

The app depends on the SW, and for that reason there's no easy way to render it without the iframe because webviews don't support SW

packages/trace-viewer/src/ui/workbenchLoader.tsx

ruifigueira · 2024-05-25T13:12:06Z

The snapshot popout link is not working (window.open doesn't work in vscode). Using vscode.env.openExternalUrl does not work either because it won't share the sw.

We can either disable it (it will still work on non-embedded mode) or delegate it to the server (for instance, it can launch a playwright-controlled browser and inject the trace file for sw to load it before opening the snapshot.html URL).

ruifigueira · 2024-05-27T12:34:11Z

I found out why I thought I needed to inject the trace file before opening snapshot.html. It's a bug: #31033

pavelfeldman · 2024-05-28T19:25:30Z

packages/trace-viewer/src/ui/workbenchLoader.tsx

@@ -24,7 +24,8 @@ import { Workbench } from './workbench';
 import { TestServerConnection } from '@testIsomorphic/testServerConnection';

 export const WorkbenchLoader: React.FunctionComponent<{
-}> = () => {
+  embedded?: boolean


Suggested change

embedded?: boolean

supportTraceDrop?: boolean

embedded mode only hides the trace viewer header, so maybe call it hideHeader instead?

Depends on microsoft/playwright#30885 being merged and @playwright/test being updated

ruifigueira · 2024-06-24T15:11:06Z

Quick status on this:

the implementation with trace viewer rendered in iframe seems stable. and I added some tests on playwright-vscode side
- until now, the only drawback I found was the key binding issue, which I "fixed" with this workaround
I added a setting to enable / disable embedded mode. Besides, embedded mode is only active if playwright version supports it
embedded mode no longer requires that playwright server is launched with 0.0.0.0 when running remotely, because vscode performs local port forwarding
embedded mode also works with devcontainers, remote SSH and codespaces

I also tried once again to implement it without the iframe (the issues I stumbed when I first tried it were mostly caused by #31033. Even if not stable yet, I'm already confident that is possible to do it. It adds some complexity, though, because playwright server needs to serve trace resources just like service worker (we cannot rely on service worker when not rendering the trace viewer on an iframe, as explained before). You can find its current implementation here:

Let me know your thoughts if it's worth to go with this solution, or if the iframe solution is good enough.

chensce · 2024-06-25T03:05:32Z

the iframe solution is good enough

chensce · 2024-06-25T03:06:46Z

look forward for inspect（code gen） embedded mode

chensce · 2024-06-25T03:07:09Z

record embedded mode

ruifigueira · 2024-06-25T08:43:19Z

@chensce this is for trace viewer only, no recorder functionality is covered here, for that you already have the vscode recorder.

pavelfeldman · 2024-06-25T18:16:43Z

Let me know your thoughts if it's worth to go with this solution, or if the iframe solution is good enough.

Ok, let's try the iframe solution.

Looking at the code, I think we can improve the situation via untangling some of the existing complexities. Here is my thinking:

Modern VS Code extension and UI Mode share the same testServer and communicate over the same wire, basically there is a lot of code reuse where either UI Mode or VS Code extension is the front-end working against the same server code.
This server is actually inherited from trace viewer - TestServer.start calls startTraceViewerServer.
When VS Code extension finds a Playwright config, it starts a server for it and uses it to list files, tests, etc. This means that you already have a trace viewer server running that can serve static files and load traces.
The live mode won't work because TraceViewer opened against test server won't have onLoadTraceRequested triggered - that is usually wired via the stdin in a standalone mode. But you can trigger it manually via sending a message to embedded.tsx.
In the longer run, I don't think you should reuse WorkbenchLoader in embedder.tsx and rather use Workbench instead. There will be some code duplication, but it'll make it clear that embedder is using one way to load live traces and the standalone more would use another way. Think about it this way, we'll have:
- UI mode app
- Trace Viewer app
- Trace Viewer with StdIn app (external Trace viewer when used from VS Code extension)
- Embedder app (to use in a web view in VS Code extension)

ruifigueira · 2024-06-25T18:43:20Z

The live mode won't work because TraceViewer opened against test server won't have onLoadTraceRequested triggered - that is usually wired via the stdin in a standalone mode. But you can trigger it manually via sending a message to embedded.tsx.

In the longer run, I don't think you should reuse WorkbenchLoader in embedder.tsx and rather use Workbench instead.

I was already addressing those two points in the EmbeddedWorkbenchLoader in my non-iframe alternative, I'll cherry-pick those changes.

pavelfeldman · 2024-06-25T19:53:19Z

I was already addressing those two points in the EmbeddedWorkbenchLoader in my non-iframe alternative, I'll cherry-pick those changes.

You can keep it as an iframe at first, to make changes more local.

Depends on microsoft/playwright#30885 being merged and @playwright/test being updated

ruifigueira · 2024-06-26T12:20:55Z

I just updated this and vscode PRs to accomodate your suggestions. Reusing the testServer was a great tip, it simplifies a lot and it's one less process to manage.

pavelfeldman

A couple of nits and it is good to go.

packages/trace-viewer/src/embedded.tsx

packages/trace-viewer/src/ui/embeddedWorkbenchLoader.tsx

packages/trace-viewer/src/ui/popout.ts

github-actions · 2024-06-28T01:22:49Z

Test results for "tests 1"

7 flaky

⚠️ [chromium-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [chromium-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [chromium-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [firefox-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [chromium-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [webkit-library] › library/browsercontext-fetch-happy-eyeballs.spec.ts:49:3 › get should work on request fixture
⚠️ [playwright-test] › ui-mode-test-screencast.spec.ts:21:5 › should show screenshots

28400 passed, 655 skipped
✔️✔️✔️

Merge workflow run.

ruifigueira mentioned this pull request May 18, 2024

feature(trace-viewer): embedded mode support PoC microsoft/playwright-vscode#483

Open

ruifigueira force-pushed the feat/embedded-trace-viewer branch from 0556550 to f4181da Compare May 18, 2024 01:36