It was “growing” problem, and now it is worse indeed. It is related to how long it takes to template HTML in inspector. I will be looking into that, to make sure we do something clever there, trying reuse and/or create only necessary DOM elements.
Reason why it takes much longer in Firefox, is that it is much slower in creating elements.
Why is then that when opening Code Editor through somescript.js->Edit and then opening DevTools inside of the spawned window the lag increases?
Note that there is no additional lag when I copy the URL of the Code Editor (or the Launch), manually open a new browser tab/window with that URL and then open DevTools inside of that.
When you open links from one page to another, even if they are new tab, but same domain, browsers tend to share JS thread between them. This leads to shared JS execution cursor, and as JS being single-threaded in a core, this leads of polluting performance for other tabs that share that thread. There is an opener attribute been added to links, and is supported in Chrome, that can “notify” that new tab should be independent, but this is down to browsers to follow on that rules. I’ve added it in few places, but will check as probably missed in few others.
Interestingly, if you open Launch, and then start profiling your game, in profiling stats you will see Editor’s stuff too. This I think have been improved using this opener attribute. I will consider adding it to all other links too.
Even breakpoints are shared between shared context, so previously in Chrome if you breakpoint in Launcher, it would freeze Editor too. Now it should be all ok due to opener = null trick.
Odd, I’m not seeing this problem at all. Chrome 56 Mac, both windows visible with the editor in one and the launch window with devtools in the other. Which browser are you running in? Is this happening on one specific project or all of them?