Fix integration test "Stamp Editor Copy/paste from a tab to an other" #18318
Assignees
Labels
Comments
|
Hopefully Fluent itself can be updated to address what at least I consider a bug, as discussed in #18313 (comment), by changing https://github.com/projectfluent/fluent.js/blob/fee2242049010f314345a7c3b7b91600df3a05fe/fluent-dom/src/dom_localization.js#L171-L172 into e.g. this.windowElement?.cancelAnimationFrame(this.pendingrAF);
this.windowElement = null;
this.pendingrAF = null;since that'd allow us to remove our |
timvandermeij
added a commit
to timvandermeij/pdf.js
that referenced
this issue
Jun 23, 2024
…test This integration test contains three issues: - The `page.bringToFront()` calls is not awaited, even though it returns a promise (see https://pptr.dev/api/puppeteer.page.bringtofront). Note that in other tests we do this correctly already. - The `page.waitForSelector()` call at the end is unnecessary because that exact condition is already checked at the end of the `waitForImage` function we call just before this line; see https://github.com/mozilla/pdf.js/blob/master/test/integration/stamp_editor_spec.mjs#L74. - The pages should be closed in reversed order; please refer to the description in mozilla#18318 for more details. Fixes mozilla#18318.
timvandermeij
added a commit
to timvandermeij/pdf.js
that referenced
this issue
Jun 23, 2024
…test This integration test contains three issues: - The `page.bringToFront()` call is not awaited, even though it returns a promise (see https://pptr.dev/api/puppeteer.page.bringtofront). Note that in other tests we do this correctly already. - The `page.waitForSelector()` call at the end is unnecessary because that exact condition is already checked at the end of the `waitForImage` function we call just before this line; see https://github.com/mozilla/pdf.js/blob/master/test/integration/stamp_editor_spec.mjs#L74. - The pages should be closed in reversed order; please refer to the description in mozilla#18318 for more details. Fixes mozilla#18318.
Yes, I agree. For now we can work around this (fortunately in an easy manner; see the PR above) until Fluent implements this functionality, but it's indeed extra reason to implement this upstream in Fluent and not the projects using it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The integration test runs currently contain the following traceback in the logs:
I have bisected this to #18313, and only now noticed that this was actually already present in the integration test run logs at http://54.241.84.105:8877/ae7a2979558207a/output.txt and http://54.193.163.58:8877/5ae7c79b8bea53b/output.txt in that PR. However, sadly this didn't actually make the integration tests fail, and this bug is filed separately in #18319.
The problem is that this test opens two pages, whereas the other tests always open just one. The test copies the image from page 1 to page 2 and then stops. This means that at the end of the test page 2 has focus, but in the
afterAllhandler we close page 1 before page 2, in other words: we attempt to close the page first that doesn't have focus.Before this PR that wouldn't have been an issue, but now that the L10n logic waits for
requestAnimationFramethat hangs page 1's tab because, until there is actually focus, no new request animation frame will come. This in turn causes the test to hang in theafterAllhandler until the timeout happens, or if the user manually clicks the first tab in the browser.One could argue that this is an issue in the PR, but on the other hand it was done like that for good reason and I also don't really see a better way. It seems easier to just change the test, since there is only one that actually suffers from this, to close the pages in reverse order so that we always close the tab with focus first, after which the other tab will automatically get focus and close too.
The text was updated successfully, but these errors were encountered: