Bugzilla

Uhm, this is a different issue than the patch solved (and it was already there with the first version of the test):

- those failures seem to happen only on `macosx`
- from the log it seems we do never get notified that the content process has launched such that we do not even enter the inner function of `withNewTab` (there is no `TEST-PASS | dom/ipc/tests/browser_content_shutdown_with_endless_js.js | Content process created.` for the `HANG_PAGE`) 
- there is always a `TEST-UNEXPECTED-FAIL | dom/ipc/tests/browser_content_shutdown_with_endless_js.js | waiting for vsync to be disabled - timed out after 50 tries. - false == true - JS frame :: chrome://mochikit/content/browser-test.js :: ensureVsyncDisabled :: line 575` nearby (which [has been introduced only a few days ago](https://bugzilla.mozilla.org/show_bug.cgi?id=1742842))

So it looks as if there was a problem with `BrowserTestUtils.withNewTab` (with this patch) and/or `BrowserTestUtils.openNewForegroundTab` (previous version of the test) that might be visible only if the content process is 100% busy with JS on load?

Florian, do you have any hint how to proceed here? From bug 1782559 it seems that this is not the only test that experiences this.

There might be a chance that we just need to wait running the JS loop in the content process until things settle and then send a message to the parent that we are ready for shutdown before entering the blocking loop?

Uhm, this is a different issue than the patch solved (and it was already there with the first version of the test):

- those failures seem to happen only on `macosx` (so far)
- from the log it seems we do never get notified that the content process has launched such that we do not even enter the inner function of `withNewTab` (there is no `TEST-PASS | dom/ipc/tests/browser_content_shutdown_with_endless_js.js | Content process created.` for the `HANG_PAGE`) 
- there is always a `TEST-UNEXPECTED-FAIL | dom/ipc/tests/browser_content_shutdown_with_endless_js.js | waiting for vsync to be disabled - timed out after 50 tries. - false == true - JS frame :: chrome://mochikit/content/browser-test.js :: ensureVsyncDisabled :: line 575` nearby (which [has been introduced only a few days ago](https://bugzilla.mozilla.org/show_bug.cgi?id=1742842))

So it looks as if there was a problem with `BrowserTestUtils.withNewTab` (with this patch) and/or `BrowserTestUtils.openNewForegroundTab` (previous version of the test) that might be visible only if the content process is 100% busy with JS on load?

Florian, do you have any hint how to proceed here? From bug 1782559 it seems that this is not the only test that experiences this.

There might be a chance that we just need to wait running the JS loop in the content process until things settle and then send a message to the parent that we are ready for shutdown before entering the blocking loop?