[Bug]: context.tracing() breaks Inspector
Playwright version
1.14.1
Operating system
Windows
What browsers are you seeing the problem on?
No response
Other information
No response
What happened? / Describe the bug
Having context.tracing() and page.pause() in the same test breaks the inspector.
- Record doesn't work
- "step over" is not consistent with end result when the test run finishes - Inspector's console says "element does receive pointer events" (first click), however, the test still fails with "element doesn't receive pointer events" seconds later
To reproduce:
- Run the code example below, wait until the inspect comes up
- Hit "Record" and click around - no code gets generated
- Step over - see Inspector log say "element does receive pointer events", but the test will fail with "element doesn't receive pointer events"
Note: this has only been reproduced in Java, not sure if the same behaviour can be observed in other language bindings.
Code snippet to reproduce your bug
public class _2TraceViewer {
Playwright pw;
Browser browser;
@Test
public void traceViewerDemo() {
pw = Playwright.create();
browser = pw.chromium().launch(new BrowserType.LaunchOptions().setHeadless(false).setSlowMo(1000));
BrowserContext context = browser.newContext();
// Start tracing before creating / navigating a page.
context.tracing().start(new Tracing.StartOptions()
.setScreenshots(true)
.setSnapshots(true));
Page page = context.newPage();
page.setDefaultTimeout(8_000);
page.navigate("https://playwright.dev/java/");
page.pause();
page.click("text=Get Started");
page.click("text=Guides");
page.click("text=Trace Viewer");
Assertions.assertTrue(page.isVisible("text=Recording a trace"));
// Stop tracing and export it into a zip archive.
context.tracing().stop(new Tracing.StopOptions()
.setPath(Paths.get("trace.zip")));
}
@AfterEach
public void cleanup() {
browser.close();
pw.close();
}
}
Relevant log output
No response
I cannot reproduce it, hitting Record while paused does start recording. If I click around and get the page into a different state the test will fail after resuming (which is expected). The only problem that I see is that if you click Record while paused then clicking 'Step over' will continue execution of the script, is that the issue? What is the behavior you expect to see?
Closing since it seems stale, please create a new issue with a repro and more information.
It is still reproducible on my machine (Windows 10, JDK 14) with the provided code. Tried different Java language levels and other options - I could not find an alternative where it would NOT be reproducible.
@yury-s - which OS, JDK, IDE, language level of Java, and Playwright version did you try?
@yury-s - which OS, JDK, IDE, language level of Java, and Playwright version did you try?
I tied with 1.14.1 and openjdk version "1.8.0_292" Linux, also tried on macOS before but I don't think the platform matters. Could you answer my questions above about your expectations?
The expectation is simply to have a working inspector (clicking generates code) when there's also context.tracing() in the code as in the provided example. It's not a blocker, of course, so if it's not reproducible by anyone else, I'm happy to close it or rephrase the issue to focus on the issue that you do see - "if you click Record while paused then clicking 'Step over' will continue execution of the script".
I think I've run into the same problem. Maybe you need to say how you execute the repro. I my case it was with the IntelliJ JUnit runner, and no PWDEBUG set (can't remember which way the headless setting was).
At the page.pause(); line, the execution will stop, and the inspector will open, but using record from there will not generate any code. I just chalked it up to some weird bug and just stopped using pause, since I didn't really need it.
I don't have time to reproduce it anymore or to try different conditions (since it's not an important feature for me), but just putting a "me too" here, if anybody is interested.
Why was this issue closed?
Thank you for your involvement. This issue was closed due to limited engagement (upvotes/activity), lack of recent activity, and insufficient actionability. To maintain a manageable database, we prioritize issues based on these factors.
If you disagree with this closure, please open a new issue and reference this one. More support or clarity on its necessity may prompt a review. Your understanding and cooperation are appreciated.