Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Regression]: Tracefile is missing actions in traceviewer although size of trace and length of recording in metadata suggests complete trace #31535

Closed
TBRSAFA opened this issue Jul 3, 2024 · 14 comments
Assignees
Labels

Comments

@TBRSAFA
Copy link

TBRSAFA commented Jul 3, 2024

Last Good Version

1.44.1

First Bad Version

1.45.0

Steps to reproduce

Unfortunately I can't provide a repo with reproduction since the AUT is an internal app and I can't easily strip our node project down to the bare minimum. When you need to know certain options/settings I can provide them ofcourse.

The described problem is always reproducable in 1.45.0 (and 1.45.1) regardless of the following conditions/settings:
headless: true/false
browser: chrome/safari
trace options:

  • screenshots: true/false
  • snapshots: true/false
  • name: undefined/"foo"

See attached tracefiles for a (minimal) example in 1.44.1 en 1.45.1.

Expected behavior

Tracefile shows all actions during test.

Actual behavior

Tracefile doesnt show all actions during test.

Additional context

see attached tracefiles
1.44.1.zip
1.45.1.zip

Environment

System:
    OS: Windows 11 10.0.22631
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i7-12800H
    Memory: 16.43 GB / 31.68 GB
  Binaries:
    Node: 20.12.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.22 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 10.5.2 - C:\Program Files\nodejs\npm.CMD
  IDEs:
    VSCode: 1.90.2 - C:\Users\TBR\AppData\Local\Programs\Microsoft VS Code\bin\code.CMD
@TBRSAFA
Copy link
Author

TBRSAFA commented Jul 3, 2024

We start the trace using this snippet:
await context.browserContext.tracing.start({
screenshots: true,
snapshots: true,
sources: false,
title: description,
});

where browserContext is of type BrowserContext and created as thus:
const config: BrowserContextOptions = {
bypassCSP: true,
viewport: null,
reducedMotion: "reduce",
acceptDownloads: true,
ignoreHTTPSErrors: true,
};
await context.browser.newContext(config);

@mxschmitt
Copy link
Member

We unfortunately need a reproduction in order to triage issues / regressions. We can keep this issue open for a few days - but without a reproduction, we can't act on it. Thanks for your understanding.

@mxschmitt
Copy link
Member

Update: We received similar issues the past 48 hours and it seems like there is a regression. I'll keep it open until the fix is confirmed, but it looks like #31541.

@mxschmitt mxschmitt added the v1.45 label Jul 4, 2024
dgozman added a commit that referenced this issue Jul 6, 2024
Retaining traces in the following scenarios:
- browser crash;
- manual `browser.close()`;
- implicit `browser.close()` from the `browser` fixture upon test end.

This does not affect the library, where `browser.close()` will not
retain the trace and will close the browser as fast as possible.

References #31541, #31535, #31537.
@diffusi-on
Copy link

Having the same issues, starting from version 1.45.0 probably. It's the same on 1.45.1: 60Mb+ traces have only 5-7 visible actions. Actually, they should contain thousands of them according to our logs and the actual work done.

I have a related question: we have an important trace that was recorded on the broken version of PW 1.45.1. How can we fix this specific trace? It should contain all the required data according to its size.

@mxschmitt
Copy link
Member

@diffusi-on could you please verify if it also happens on Canary? https://playwright.dev/docs/canary-releases

@diffusi-on
Copy link

@mxschmitt I'm not sure it will be easy to test since we are not using @playwright/test. We use Playwright more for RPA rather than testing.

The project is deployed under Docker, so we are using the Docker image mcr.microsoft.com/playwright:v1.45.1 as the base.

Should we add something like this to Dockerfile?
RUN npx -y playwright@next install --with-deps

@mxschmitt
Copy link
Member

RUN npm i -D playwright@next
RUN npx playwright install --with-deps

This should do it.

@diffusi-on
Copy link

@mxschmitt "playwright": "^1.46.0-alpha-2024-07-10" - traces are still broken

Can't provide the full trace, but can show a screenshot. For example, at this stage, the RPA filled the company search field, then clicked the company name. It was done, but not shown in the trace along with many (99% ? :) other actions.
Screenshot 2024-07-10 at 12 20 59

@mxschmitt
Copy link
Member

mxschmitt commented Jul 16, 2024

We unfortunately need something which we can run locally in order to act on it. Our canary received some more fixes, so maybe you could re-check again? If you are using playwight or playwright-core etc. make also sure to use @next for them.

npm install @playwright/test@next

@deputat1000
Copy link

deputat1000 commented Jul 16, 2024

Hi! I experiencing the same problem on 1.45.0-1.45.2. And on 1.46.0-alpha-2024-07-16 it's still reproduced - most of the actions are not displayed in the Trace Viewer.

@dgozman
Copy link
Contributor

dgozman commented Jul 17, 2024

@deputat1000 Could you please share a repro with us so we can debug the problem?

@deputat1000
Copy link

deputat1000 commented Jul 19, 2024

@dgozman sure

import { chromium } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext();
const page = await context.newPage();

await context.tracing.start();

await page.goto('https://playwright.dev/');
await page.locator('//img[@alt="Playwright logo"]').waitFor({ state: 'visible' });
await page.locator('//button[@aria-label="Search"]').click();
await page.locator('//input[@type="search"]').waitFor({ state: 'visible' });

await context.tracing.stop();

So, there are 4 actions.

In trace 1.44.1 there will be the same 4 actions:
1 44 1

But in 1.45.2 - 1 is lost, 3 actions are displayed:
1 45 2

trace-1.44.1.zip
trace-1.45.2.zip

@dgozman
Copy link
Contributor

dgozman commented Jul 19, 2024

@deputat1000 Thank you for the repro! I believe this is similar to #31764, which will be fixed shortly. Please follow that issue for now.

@dgozman dgozman self-assigned this Jul 19, 2024
@dgozman dgozman added the v1.46 label Jul 19, 2024
@mxschmitt
Copy link
Member

Fixed in #31764 and released in v1.45.3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants