[CLOSED] Wait time for live development to start is too short

[core-ai-bot]

Issue by njx
Wednesday Nov 27, 2013 at 01:46 GMT
Originally opened as adobe/brackets#6122

---

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.)

[core-ai-bot]

Comment by FezVrasta
Wednesday Nov 27, 2013 at 10:51 GMT

---

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

[core-ai-bot]

Comment by jasonsanjose
Monday Feb 24, 2014 at 21:58 GMT

---

@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.

[core-ai-bot]

Comment by jasonsanjose
Monday Feb 24, 2014 at 22:41 GMT

---

I submitted a PR to try adobe/brackets#6997.

[core-ai-bot]

Comment by njx
Monday Feb 24, 2014 at 23:22 GMT

---

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.

[core-ai-bot]

Comment by njx
Monday Feb 24, 2014 at 23:24 GMT

---

(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.)

[core-ai-bot]

Comment by jasonsanjose
Tuesday Feb 25, 2014 at 17:41 GMT

---

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

[core-ai-bot]

Comment by njx
Tuesday Feb 25, 2014 at 17:46 GMT

---

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.

[core-ai-bot]

Comment by jasonsanjose
Thursday Feb 27, 2014 at 18:18 GMT

---

@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?

[core-ai-bot]

Comment by njx
Thursday Feb 27, 2014 at 22:34 GMT

---

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.

[core-ai-bot]

Comment by jasonsanjose
Friday Feb 28, 2014 at 21:12 GMT

---

FBNC@njx. Instead of a longer timeout, we use frameNavigated as discussed here.

[core-ai-bot]

Comment by redmunds
Friday Feb 28, 2014 at 21:33 GMT

---

@jasonsanjose I should have mentioned this before I merged the frameNavigated PR, but I noticed a case where I think we still might need a longer timeout. In the case mentioned here on Win7 (HD) I see the Relaunch dialog every time I switch pages. The pages are simple with only 1 related file (which is shared/cached), so I think the delay is due to complexity of processing the CSS (as opposed to downloading the CSS).

[core-ai-bot]

Comment by jasonsanjose
Tuesday Mar 04, 2014 at 23:46 GMT

---

I think a longer timeout may not be the right fix though. In the case of switching documents, it's about the race conditions around reconnect and the whole teardown/setup process.

I'll take a new look at #6889 since it looks like #7008 will land soon.

[core-ai-bot]

Comment by redmunds
Friday Mar 07, 2014 at 22:44 GMT

---

@njx FBNC - does this help the problem you were seeing?

[core-ai-bot]

Comment by njx
Friday Mar 14, 2014 at 23:30 GMT

---

I can't easily reproduce the original problem anymore, but it seems likely that the fix would have addressed it. Closing.