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.

Sign up for GitHub

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

Jump to bottom

[Bug]: Focus event is not fired using the launch option headless: new #10350

Closed
2 tasks
koddsson opened this issue Jun 8, 2023 · 6 comments
Closed
2 tasks

[Bug]: Focus event is not fired using the launch option headless: new #10350

koddsson opened this issue Jun 8, 2023 · 6 comments
Labels
bug confirmed new-headless

Comments

@koddsson
Copy link

koddsson commented Jun 8, 2023 •
edited
Loading

Bug expectation

I expected the @web/test-runner-chrome focus tests to run green after we started using the new headless option. They started failing after setting this option and the minimal reproduction posted here seems to validate that test failure.

Bug behavior

  • Flaky
  • PDF

Minimal, reproducible example

const puppeteer = require('puppeteer');

class AssertionError extends Error {}

(async () => {
  const browser = await puppeteer.launch({headless: 'new'});
  const page = await browser.newPage();

  await page.goto('https://koddsson.com');
  await page.waitForSelector('title');

  const firedEvent = await page.evaluate(async () => {
    const input = document.createElement('input');
    document.body.appendChild(input);
    
    let firedEvent = false;
    input.addEventListener('focus', () => {
      firedEvent = true;
    });
    input.focus();

    // await 2 frames for IE11
    await new Promise(requestAnimationFrame);
    await new Promise(requestAnimationFrame);
    return firedEvent;
  });

  if (firedEvent !== true) {
    throw new AssertionError('Expected focus event to have been fired!');
  }

  await browser.close();
})();

Error string

AssertionError: Expected focus event to have been fired!

Puppeteer configuration

No response

Puppeteer version

20.5.0

Node version

18.16.0

Package manager

npm

Package manager version

9.6.4

Operating system

macOS
@koddsson koddsson added the bug label Jun 8, 2023
@koddsson koddsson mentioned this issue Jun 8, 2023
Merged
@github-actions
Copy link

github-actions bot commented Jun 8, 2023 •
edited
Loading

The issue has been labeled as confirmed by the automatic analyser.
Someone from the Puppeteer team will take a look soon!

Analyzer run

@Lightning00Blade
Copy link
Collaborator

Thank you for reporting.
I can see that the same behaviors is observed with headless: false, I will check with the team if we should change this.
In the mean time a workaround for anyone needing this is to use await page.bringToFront();.

@OrKoN
Copy link
Collaborator

OrKoN commented Jun 12, 2023

I am not sure it is working as expected. I would expect a new page to be at the front by default. @Lightning00Blade could you report it to crbug.com?

@Lightning00Blade
Copy link
Collaborator

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1454012

@tmsns
Copy link

tmsns commented Jul 5, 2023

User of @web/test-runner here. 👋

We experienced similar failures when running the tests of our project. More specifically, the failures were timeouts. After some debugging we found that tests were waiting on code that needed to run using window.requestAnimationFrame(callback) and window.requestIdleCallback(callback). The callbacks never seemed to be called.

Some observations we had:

  • the tests did also fail when using the headfull mode ({headless: false})
  • the tests didn't fail with the old headless option (using {headless: true})
  • the tests didn't fail with the new headless option when the concurrency option of @web/test-runner was set to 1. This makes all the tests run in the same tab (and thus in the foreground) as opposed to multiple tabs (8).

As a workaround we override the behaviour of window.requestAnimationFrame(callback) and window.requestIdleCallback(callback) in the browser, by replacing their implementation with window.setTimeout(callback, ms). In our case, this is working fine.

As the test of @koddsson is also using requestAnimationFrame, our problem might be related. I briefly talked to @koddsson earlier today, and we will check if we can create a workaround in @web/test-runner. The idea would be to override window.requestAnimationFrame(callback) and window.requestIdleCallback(callback) in the browser as well, but then to connects back to puppeteer to run a await page.bringToFront() (as suggested by @Lightning00Blade). Let's hope that works 😃

@tmsns tmsns mentioned this issue Jul 6, 2023
Merged
@43081j 43081j mentioned this issue Aug 29, 2023
Merged
@OrKoN
Copy link
Collaborator

OrKoN commented May 16, 2024

I believe the upstream issue has been fixed.

@OrKoN OrKoN closed this as completed May 16, 2024
@westonruter westonruter mentioned this issue Mar 19, 2025
Open
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug confirmed new-headless
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@koddsson @OrKoN @tmsns @Lightning00Blade