[Puppeteer] Unit test "Page.waitForNetworkIdle" fails because timers are throttled when run in a background tab
Categories
(Remote Protocol :: WebDriver BiDi, defect)
Tracking
(Not tracked)
People
(Reporter: alexrudenko, Unassigned)
References
Details
Attachments
(1 file)
48.37 KB,
text/plain
|
Details |
Steps to reproduce:
This bug is reproducible by Puppeteer's test Page Page.waitForNetworkIdle should work
. The test verifies that network idleness is detected as follows:
describe('Page.waitForNetworkIdle', function () {
it('should work', async () => {
const {page, server} = await getTestState();
await page.goto(server.EMPTY_PAGE);
let res;
const [t1, t2] = await Promise.all([
page.waitForNetworkIdle().then(r => {
res = r;
return Date.now();
}),
page
.evaluate(() => {
return (async () => {
await Promise.all([
fetch('/digits/1.png'),
fetch('/digits/2.png'),
]);
await new Promise(resolve => {
return setTimeout(resolve, 200);
});
await fetch('/digits/3.png');
await new Promise(resolve => {
return setTimeout(resolve, 200);
});
await fetch('/digits/4.png');
})();
})
.then(() => {
return Date.now();
}),
]);
expect(res).toBe(undefined);
expect(t1).toBeGreaterThan(t2);
expect(t1 - t2).toBeGreaterThanOrEqual(400);
});
});
Actual results:
The test fails. What happens seems to be that there is 2+ seconds delay between the first pair requests and the second pair of requests, therefore, the idleness is detected at the time when it should not be. Note that the response completed events for the first pair of requests come without delay and there is no other activity on the protocol before the 3.png request is sent. Overall, the evaluate call should take a bit more than 400ms but it appears to be requiring a couple of seconds.
Expected results:
The test should pass (passes with chromium).
Comment 1•1 year ago
|
||
Alex, you are running this test in a new tab and given that browsingContext.create
doesn't automatically focus that newly opened tab, it will stay as background tab. But that means that any timer for code as run via script.evaluate
will be throttled to at minimum 1s. As such you see these delays here.
The Firefox preference dom.min_background_timeout_value
actually controls this and by default is set to 1000
.
So basically we seem to have to wait for browsingContext.activate
to be implemented on bug 1841004.
Nevertheless this isn't a bug in our implementation and throttling is not high on the priority list. As such I'm going to close this bug as invalid given that it lacks code in Puppeteer.
Updated•1 year ago
|
Description
•