I've had several cases of drivers just not picking me up. Reading their time to move anywhere at all, driving away and keep getting further and further away, it driving towards me only to turn some other direction. I always just cancel on them and have never had to pay a cancellation fee. I think once or twice they "picked me up" a block away. I'm pretty sure I was able to cancel or end the ride on that too, definitely was never charged though I don't recall if I had to use the support. But I never let it actually complete the trip when I wasn't riding. But I was always very miffed when anything like that happened as I did not appreciate them wasting my time.
Almost every js API for making requests is asynchronous so they do return after the request is made. The exception though is synchronous XHR calls, but I'm not sure if those are still supported
... Anyhow I think it doesn't matter because you can listen for the error/failure of most async requests. Cors errors are equivalent to network errors - the browser tells the js it got stays v code 0 with no further information - but the timing of that could lead to some sort of interference? Hard to say what that would be though. Maybe if you knew the target webserver was slow but would respond to certain requests, a slower failed local request could mean it actually reached a target device.
That said, why not just fire off simple http requests with your intended payload? Abusing the csrf vulnerabilities of local network devices seems far easier than trying to make something out of a timing attack here.
I don't believe this is true? As others have pointed out, preflight options requests only happen for non simple requests. Cors response headers are still required to read a cross domain response, but that is still a huge window for a malicious site to try to send side effectful requests to your local network devices that have some badly implemented web server running.