Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Startup sequence feels muddled, misleading #1951

Closed
peterflynn opened this issue Oct 25, 2012 · 9 comments
Closed

Startup sequence feels muddled, misleading #1951

peterflynn opened this issue Oct 25, 2012 · 9 comments

Comments

@peterflynn
Copy link
Member

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. AppInit.appReady fires before document is loaded #1526 was closed despite not being truly fixed; pull Simplified LiveDevelopment/main.js #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.

@DennisKehrig
Copy link
Contributor

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.

@ghost ghost assigned jasonsanjose Oct 29, 2012
@pthiess
Copy link
Contributor

pthiess commented Oct 29, 2012

Reviewed, @jasonsanjose we should document

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

@peterflynn
Copy link
Member Author

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.

@DennisKehrig
Copy link
Contributor

Please see commits e291103 and 15fa7bb in the dk/less-refactoring branch.

@dangoor
Copy link
Contributor

dangoor commented Jan 14, 2013

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

@DennisKehrig
Copy link
Contributor

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

@ghost ghost assigned peterflynn Jan 14, 2013
@jasonsanjose
Copy link
Member

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

@peterflynn
Copy link
Member Author

Looks great! Thanks for updating the wiki too.

@njx
Copy link

njx commented Jul 19, 2013

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants