Wait time for live development to start is too short

[njx]

I've been using Live Development on a page that includes images from lorempixel.com/placekitten.com/placedog.com. Live Development often times out when loading this page (with an "Unable to load Live Development page" error), even though the page eventually loads successfully in the browser. I think this is because it's waiting for all the images to finish loading before deciding that the connection is okay.

It seems like we should either have a more generous timeout, or perhaps not wait for all the images to load before letting Live Development decide it's connected (though the latter seems dangerous and I don't know how we would do it).

Another option might be to change the timeout dialog to something with a message that says something like "Live Development wasn't able to connect. Would you like to wait longer for the page to finish loading?", with a "Retry" button that would let it keep waiting. (We'd probably need better wording than that.)

[FezVrasta]

I've faced the same problem using Lorempixel. On my side this bug is confirmed.

[jasonsanjose]

@njx can you still reproduce this? It seems safe enough to change RemoteAgent to use frameNavigated instead of loadEventFired. Waiting for those resources to load buys us nothing. RemoteAgent is just waiting for the interstitial page to be navigated to the user's desired file so we can inject our RemoteFunctions via eval.

[jasonsanjose]

I submitted a PR to try #6997.

[njx]

I can't reproduce it easily because it seems like those sites have gotten faster :) I could construct a fake test case if it would help, though.

I guess one issue with using frameNavigated is that it means we might inject our code before or between the web page's own scripts. I suppose if there's some conflict between our code and the loaded code that would be a problem in any case, but I wonder if there's some way in which the fact that the order of our script loading vs. theirs being non-deterministic might bite us.

[njx]

(As a possibly relevant point, I found when investigating #6275 that delaying all the agents until frameStoppedLoading seemed to fix that particular problem...but of course that would make this problem even worse.)

[jasonsanjose]

Ah. You're right. Using frameNavigated in #6997 can still randomly cause web fonts to stop working.

[njx]

I don't think that's necessarily an argument against using frameNavigated in the sense that it wouldn't necessarily be more broken than it is today...but since we don't know what the right solution is for #6997 we might want to wait until we've gotten into that issue more to figure out if there's some other workaround that wouldn't involve delaying until frameStoppedLoading.

[jasonsanjose]

@njx did you mean "the right solution for #6275" (web fonts) in your previous comment?

I'm leaning towards fixing this latency problem with frameNavigated in the interim. This helps us narrow down actual Chrome or live preview connection bugs separate from network latency or just plain invalid URLs.

I did a simple test with just an invalid script URL that causes the "unable to load" error dialog. The loadEvent Fired event still fires, but much later, after our connection timeout, therefore causing the error dialog. I think bad URLs and typos can happen pretty frequently, causing these "false" dialogs.

What do you think?

[njx]

Er, yes, I meant #6275. And yes, I don't think that needs to block switching to frameNavigated if it seems clear that it will fix a large class of other issues.