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.

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

Handle pending connections losing context on frame navigation #426

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

francisbeaudoin
Copy link
Contributor

@francisbeaudoin francisbeaudoin commented Dec 15, 2023

Details

Similar to what is being proposed in #420, this PR fixes intermittent Ferrum::TimeoutError as the driver awaits for requests to be completed.

What

It was observed that in some scenarios the driver is not always receiving and associated Network.loadingFailed for requests that were in-flight as the main frame navigates. This may be happening with either main frame requests or sub-frame ones.

I'm not sure if this is the right approach, but it appears to be working. Basically, it flags requests which are no longer relevant to the current page context as unknown which are then assumed to be #finished.

Relates to #420

@route
Copy link
Member

route commented Jan 6, 2024

@francisbeaudoin do you have an example of such a page in the public internet? I just want to check the CDP logs to better understand of what's going on. A test describing the issue would be more appropriate though.

@route route added the needs feedback Needs feedback label Jan 6, 2024
@francisbeaudoin
Copy link
Contributor Author

francisbeaudoin commented Jan 9, 2024

@route Thanks for following up.

I spent some time reproducing the issue by using a use case that was causing timeouts at the time, and found something interesting.

By using the headless browser instance opened by ferrum vs using a regular instance ran from the desktop, the network requests were not returning the same status. i.e. (canceled) vs (unknown). As far as I remember, the (unknown) ones were causing the library to raise a timeout as it couldn't infer if a request had completed.

I've identified the different behavior to the disable-site-isolation-trials option. If that option is removed thus enabled, Chrome shows a (unknown) network request as opposed to (canceled) status. In the current library state, the option is disabled (added 4 months ago) so it may not longer be an issue for this specific use case, but I suspect there are other scenarios where requests may end up in an unknown state thereby timing out.

This was reproduced by visiting this example, and toggling the disable-site-isolation-trials option.

With disable-site-isolation-trials
disable-site-isolation-trials

Without disable-site-isolation-trials
with-site-isolation-trials

@route
Copy link
Member

route commented Jan 11, 2024

Hmmmm, nice thank you! Let me experiment a bit with that

@francisbeaudoin
Copy link
Contributor Author

👋 @route By any chance you had time to look into this? I'd love to stop using a forked version in my project.

@route
Copy link
Member

route commented Mar 27, 2024

Sorry not yet, was busy doing other things. Thanks for the reminder I will

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs feedback Needs feedback
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants