[CLOSED] Startup sequence feels muddled, misleading

[core-ai-bot]

Issue by peterflynn
Thursday Oct 25, 2012 at 20:53 GMT
Originally opened as adobe/brackets#1951

---

The sequence of operations during Brackets startup is a little confusing. It's poorly documented and feels somewhat error prone... and in at least a few cases, there may already be issues as a result:

• The last stage of project loading (restoring the working set) happens in parallel with loading extensions, which seems somewhat fragile.
• APP_READY usually fires after the working set is fully restored, but is not guaranteed to. But because in most cases it does happen later, people often rely on it despite being not guaranteed (e.g. [CLOSED] "Live File Preview" menu item should be checked when connected #1526 was closed despite not being truly fixed; pull [CLOSED] Load extensions from the application support directory #1880 relies on it always being fixed).
• Our "Application Startup" performance metric stops timing before any extensions have been loaded (including core, aka default extensions).

It seems like some of the weirdness is due to loading extensions after (mostly) opening the initial project. It would be cleaner if we load all extensions first, then load the initial project. But that runs afoul of #968 -- a problem loading extensions would prevent Brackets from loading the initial project, which at least in the past left it pretty much hosed. However, there are some ways we could address that: catch exception errors more robustly (see early work and later suggestions); or add a timeout (#1029) to ensure the next phase of startup always runs; or make Brackets robust to launching with no initially-open project.

Another thing we could do to help here is improve documentation, both on the wiki and in brackets.js, to more clearly describe the order of events during startup.

[core-ai-bot]

Comment by DennisKehrig
Saturday Oct 27, 2012 at 22:46 GMT

---

There is something to be said for first restoring the project, etc., and then loading the extensions (it just feels safest).

But there's indeed also something to be said for loading the extensions first, since then we can potentially influence more fundamental parts of Brackets. For instance, my whitespace extension monkey-patches CodeMirror and then triggers a refresh in visible editors, causing a visible delay between displaying the file and highlighting the whitespace in it. If I could patch CodeMirror before it was first use, it would look less like a hack.

[core-ai-bot]

Comment by pthiess
Monday Oct 29, 2012 at 18:35 GMT

---

Reviewed,@jasonsanjose we should document

• and later move the other improvement stuff to the backlog to be prioritized.

[core-ai-bot]

Comment by peterflynn
Friday Nov 02, 2012 at 00:32 GMT

---

Re "runs afoul of #968": due to pull #1968, we can now be much more robust to errors that occur during extension loading. That frees our hand to make extensions load sooner, if we so desire.

[core-ai-bot]

Comment by DennisKehrig
Monday Jan 07, 2013 at 18:10 GMT

---

Please see commits e29110345ac2aab0430904a622f50cc8cf96621e and 15fa7bb0782c4e5382cd6f8241df74ac7703395c in the dk/less-refactoring branch.

[core-ai-bot]

Comment by dangoor
Monday Jan 14, 2013 at 19:38 GMT

---

Is there anything left for this bug, or are we done here?

[core-ai-bot]

Comment by DennisKehrig
Monday Jan 14, 2013 at 19:52 GMT

---

Haven't tested this, but since my two commits are in there, a careful go from me.

[core-ai-bot]

Comment by jasonsanjose
Monday Jan 14, 2013 at 21:25 GMT

---

FBNC@peterflynn. I've also updated the wiki page with the latest sequence https://github.com/adobe/brackets/wiki/Brackets-Development-How-Tos.

[core-ai-bot]

Comment by peterflynn
Saturday Jan 19, 2013 at 01:57 GMT

---

Looks great! Thanks for updating the wiki too.

[core-ai-bot]

Comment by njx
Friday Jul 19, 2013 at 22:28 GMT

---

Removing "for release note" label from this old bug.