Imho, this is problem of javascript.editor Installer (although I need others to verify that opinion):

    @Override
    public void restored() {
        WindowManager.getDefault().invokeWhenUIReady(new Runnable() {
            public void run() {
                GlobalPathRegistry.getDefault().register(JsClassPathProvider.BOOT_CP, new ClassPath[] { 
JsClassPathProvider.getBootClassPath() });
            }
        });
    }

To reproduce locally get revision ae393e723aa0 or newer, apply following patch and run its test:

diff -r ae393e723aa0 ide.kit/test/qa-functional/src/org/netbeans/test/ide/GeneralSanityTest.java
--- a/ide.kit/test/qa-functional/src/org/netbeans/test/ide/GeneralSanityTest.java       Mon May 25 12:20:32 2009 +0200
+++ b/ide.kit/test/qa-functional/src/org/netbeans/test/ide/GeneralSanityTest.java       Mon May 25 12:23:33 2009 +0200
@@ -81,7 +81,7 @@
             ).gui(true).clusters(".*").enableModules(".*").
             honorAutoloadEager(true).
             addTest(
-//                "testWaitForUIReady",
+                "testWaitForUIReady",
                 "testBlacklistedClassesHandler",
                 "testOrgOpenideOptionsIsDisabledAutoload",
                 "testOrgNetBeansModulesLanguagesIsDisabledAutoload",

I think Jarda's analysis is correct. Javascript needs to register its classpath with jsstubs.zip, but it does not have a
project to do so. That's why it's done in module install. Maybe we could move it somewhere else (eg. to JsLanguage)...

Actually, according to Vita, this problem also causes another bad effect, which is more user-visible: right after
startup, there is a "Scanning projects..." progress bar going on for several seconds (which parses JavaScript stubs),
and this looks awkward and creates a bad user experience ("why is the IDE scanning projects when I have no projects open?").

So I reset the target milestone, please reevaluate whether this issue could/should be fixed for 6.7. Thanks.

Also cc'ing Ludo who brought up this issue yesterday.

fixed in web-main#fedf7afc9fc4 by moving the classpath initialization from the module installer to the JsLanguage
constructor.

The JsLanguage instance is created when a project with js file is opened or without project (in favourites) when a
javascript file is selected in the explorer. BTW the user may think "why the IDE scans projects if I just opened a file
from the explorer?" ;-) But of course such scenario is far less often than just running a fresh ide and getting the scan
after that.

The CP initialization is done lazily so if a hypothetic code requires the classpath registered just after the language
creation it simply won't get it.

I have fixed the code in trunk which I consider fine with a small risk of potential regressions. Since I am not that
familiar with the javascript code to be sure the change is safe, I won't recommend the fix to be put in 6.7. The added
value of the fix doesn't compensate the risk at all IMHO. If Vita or someone else "signs" that the change is safe, then
go ahead and do what you think is right to do ;-)

Please also enable the testWaitForUIReady mentioned above to verify that your fix prevents loading of these classes on 
start forever. 

The original problem is fixed, so reopening is not appropriate. If an additional test is requested, then a separate task
should be filed.

Integrated into 'main-golden', will be available in build *200905291401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/fedf7afc9fc4
User: Marek Fukala <mfukala@netbeans.org>
Log: #165915 - JsLanguage and JsParser loaded on start

the test is reenabled in web-main#53bb02208479 and passes.

I am sorry, but the way to reproduce original problem is to run the test. Until the test is known to pass, the issue 
is not fixed imho and definitely cannot be verified.

Perfect, thanks for the test.

Build without your changes failed:
http://hudson.apidesign.org/hudson/job/netigso/168/
As soon as I merged your fix, the test passed:
http://hudson.apidesign.org/hudson/job/netigso/169/

Thanks.

we'll try to test it today, just to confirm that there is no regression ... I would vote for fixing this one into
release67 (this is the most visible and the most senseless scan during the IDE session).

mschovanek, 
have you had a chance to test it ? Could you please verify this fix in trunk ? Thanks in advance.

Verified in trunk build by QE, please transplant into release67.

Transplanted to release67: http://hg.netbeans.org/release67/rev/d85b6b2e3517.

v.

Integrated into 'main-golden', will be available in build *201001131418* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/b9bc77139a60
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: After fix of #165915 the JsParse* classes shall no longer be loaded