(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #9) > On bug 1816538 the unload timeout has been increased to 5000ms. Lets see how this works and if we may still need this patch or not. We had to backout the patch from bug 1816538. We had several issues: - the xpcshell test test_Navigate.js started taking too much time on ccov -> bug 1835796 - many timeouts on Android Debug -> Bug 1835819 - timeouts on seemingly all wdspec tests in Beta simulation -> Bug 1835822 While the first one is not too concerning on its own, the 2 other issues mean that it's quite frequent to call `waitForInitialNavigation` in cases where we are missing the first navigation. Which means that we can't consistently expect to see a navigation in situations where we are using this API. Potential next steps - increase the timeout more conservatively (we used 5000ms, we could stay closer to the current 200ms) - only apply this to BiDi's browsingContext.navigate calls - expose a preference to drive the timeout (this would help for instance with testing this for puppeteer)
Bug 1832891 Comment 10 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #9) > On bug 1816538 the unload timeout has been increased to 5000ms. Lets see how this works and if we may still need this patch or not. We had to backout the patch from bug 1816538. We had several issues: - the xpcshell test test_Navigate.js started taking too much time on ccov -> bug 1835796 - many timeouts on Android Debug -> Bug 1835819 - timeouts on seemingly all wdspec tests in Beta simulation -> Bug 1835822 While the first one is not too concerning on its own, the 2 other issues mean that it's quite frequent to call `waitForInitialNavigation` in cases where we are missing the first navigation. Which means that we can't consistently expect to see a navigation in situations where we are using this API. Potential next steps - increase the timeout more conservatively (we used 5000ms, we could stay closer to the current 200ms) - only apply this to BiDi's browsingContext.create calls - expose a preference to drive the timeout (this would help for instance with testing this for puppeteer)