FCS stopper, increasing to P1.

100% reproducible on projects with some html files.

The problem seems to be in parsing.api where JsRefactoringPlugin:236 does:

if (resultIterator.getSnapshot().getMimeType().equals(JsTokenId.JAVASCRIPT_MIME_TYPE)) {
    //only JsParserResult should get here,
    //but the sometimes the parser result instance is HtmlParserResult
    //which then causes the assertion in AstUtilities
}

I tried resultIterator.getParserResult().getSnapshot().getMimeType() with the same result.

In the worst case if the fix in parsing.api is risky for 6.7 I could fix this particular by 

if(result instanceof JsParserResult) {
  //process ...
}

but this is a hack and noone can be sure where else the same problem can appear.

I would propose to fix this properly and for 6.7.

After discussin with editor team I am attaching a simple patch which workarounds the problem on javascript refactoring
side. 

Vito, please verify the fix and put it to trunk and release67 as we agreed.

Also please add the trunk changeset of the CSL parser factories registrations as we agreed on to this issue so I can
look how it works after that. Thanks!

There is nothing wrong on Parsing API side. GSFParserFactory returns some parser instance for given set of Sources, so
it should be able to parse them all.

Created attachment 82863 [details]
The patch

I didn't say the problem is parsing.api, although ... :-)

reassigning to Vita, keeping javascript component to make Hanz happy.

Ok, thanks for the patch Marku, it looks ok. It's now in jet-main as http://hg.netbeans.org/jet-main/rev/e9009c5103e7.
Jirko could you please retest this?

Integrated into 'main-golden', will be available in build *200905280201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/e9009c5103e7
User: Marek Fukala <mfukala@netbeans.org>
Log: #166032: going file by file when refactoring multiple sources in order to avoid mixing up different file types when calling ParserManager.parse

The AE looks fixed but the rename still does not work when is invoked at function call statement.

to reproduce:
-------------
1) have a .js like (| represents the cursor):
  function hello() {}
  he|llo();
2) invoke Rename [Ctrl + R]
3) choose Preview

ERROR: Rename found 0 occurrences. 

vstejskal, 
please transplant your part of code into release67 today (before 10pm CEST), mschovanek will report separate issue for
Rename case -> we'll track that issue as a stopper for FCS not for RC1

I have tested the behaviour: it is different whether you invoke the rename on invocation place (doesn't work) or on
definition place (works).

The newly created issue migth be even P3 since the rename works - from the place where I would invoke it (function
definition) ;-)

"rename still does not work" - This is probably unrelated to the AE. It does not work in 6.5 either. I looked in the
JsRenameHandler and it treats the function references as variables, which is of course wrong.

This seems to be poorly implemented anyway, just add to your example 'var hello;' and see what happens. The function
reference hello(); is colored as a variable (green in the default scheme). When the rename refactoring is initiated
either on var hello; it will rename just the variable declaration. If it's initiated on the function declaration it will
rename both the function declaration and the function call. If it's initiated on the function call, it will again rename
only the variable declaration. This all was tested in Nb6.5 and I assume 6.7 behaves the same.

Anyway, since you confirmed that the AE is fixed, I'll transplant the fix to release67 clone and close this issue as
FIXED. I'll then either find an existing issue describing the broken rename or file a new one.

I created a separate issue for the broken Rename case. See issue #166203. 

Good, thanks. The fix was transplanted to release67 as http://hg.netbeans.org/release67/rev/1a9a7e848e72.

Verified in release67 by QE.

v.