-
-
Notifications
You must be signed in to change notification settings - Fork 135
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
Network.loadingFailed error preventing file from downloading #413
Comments
I assume you are opening file directly with |
@route Yes, to the |
I'm not 100% sure if I see the same issue. When updating to On GitHub Actions we now have a test consistently failing, although I'm having a hard time reproducing it locally. It is failing here: visit download_file_fixture_path(file) with:
EDIT: Interestingly I can reproduce it on my x86 MacBook Pro 🤔 |
@tisba I'm pretty sure you started to use new Chrome 119 which broke something. Check your logs before on the successful build and after it started to fail for Chrome version. |
Good point, I totally forgot about Chrome itself 🤦♂️ Can't access my M1 MacBook Pro right now to check the version where it worked. On my x86 MacBook Pro (using Docker) I can reproduce the issue with:
Downgrading to I can find references to |
Maybe there is an issue with Chrome versions, but this feels more related to upgrading |
I doubt that because you can see latest builds of ferrum https://github.com/rubycdp/ferrum/commits/main |
Need some more time building a simplified example. At least in our case, the issue is not occuring when staying at ferrum 0.13 and cuprite 0.14.3, both locally on my MacBook Pro (x86) as well as on GitHub Actions 🤷 |
@nickhammond can you tell me your Chrome version? |
@route I'll have to test again to ensure it's still happening since I ended up patching and pointing to my own fork. Chrome: 118.0.5993.70 |
Chrome 119 started to send: {"method":"Page.frameStoppedLoading","params":{"frameId":"69FE7B40C52D828E8A4681686395EAC8"}} for the main request which was always missing before. In fact Chrome was always returning an error for the main request:
but was missing to send I believe it works like this because it downloads file in the subprocess, and it doesn't make sense for it to continue main request since it's the same file, so it always cancels main request and starts subprocess to download file. When download is finished the browser gets notification or in case of headless instance
/cc @tisba @nickhammond |
@route Nice digging, appreciate the context! Yah, when I was looking through that network log I wasn't entirely sure what looked normal and what didn't. |
@route Nice work! I'll update our app to point to this version. |
Started seeing a weird network/download issue with Ferrum and ended up pinpointing it to the
Network.loadingFailed
event but weirdly I'm not seeing anything get aborted in the network activity tab.I'm seeing this
Network.loadingFailed
event which mentions that it was cancelled, could it be cancelled because a download was triggered?It looks like the go_to method initially was listening to network level errors like DNS and connectivity.
9217224#diff-2f9537c613f48bed5ff6ca273e2dac28886a32fe78dcd2dc7c7c798c891434d3R78 but was changed to just listen to any error coming back.
Since the browser most recently saw a
Network.loadingFailed
event but not a subsequentNetwork.loadingFinished
or any other network event, just page and browser events, theresponse["errorText"]
is still set even though the download has already started and is in progress. https://github.com/rubycdp/ferrum/blob/main/lib/ferrum/network.rb#L414This causes the aborted error to be raised even though the download continues to go through and complete.
The text was updated successfully, but these errors were encountered: