Should be fixed for FCS => P1.

fixed in web-main#79c2d727c412

The are multiple problems related to this issue. The first one is that we allow to generate a virtual source for
javascript in more ways than just one. There is JSP/PHP/RHTML/GSP/HTML -> JavaScript embedding provider and also
JSP/PHP/RHTML/GSP->HTML embedding provider. So there are two ways of generating JS: 1) JSP->HTML->JS and JSP->JS; The
only direct JSP->JS is the correct one, but the parsing api generates virtual sources for all branches recursivelly. I
have fixed this problem in JsEmbeddingProvider by checking the mimePath of the given snapshot. If the mimePath contains
embedded html like text/x-jsp/text/html we won't create an instance of embedding provider.

So now we have just one javascript virtual source, but there is another problem. The method
ResultIterator.getParserResult(offset) returns just one ParserResult, where the algorithm is to return the parser result
of the deepest embedding on the offset. However now we have two virtual source (embedding) overlapping each other. For a
JSP file there are text/x-jsp/text/html and text/x-jsp/text/javascript embedding. The embedding level is the same (=2)
and since they may overlap the RI.getParserResult(offset) can return just one. Currently it returns the html parser
result which EmbeddingProvider$Factory is registered first in the layer. This however breaks many features in CSL since
they depend on proper identification of parser language based on given offset. For example code completion in <script>
tag in JSP doesn't work since the CSL tries to use HTML code completer.

There seems to be more ways of fixing this problem:
1) use only transitive virtual sources generation/do not use the direct ones (JSP->JS). 
2) do not allow the virtual sources on the same embedding level to overlap
3) use the same marks (currently __UNKNOWN__ for Javascript; @@@ for HTML) for templating language pieces for all
embedded languages
4) specify the order of the embedding provider factories in the layes so the javascript one is before the JSP/PHP/...->HTML

#1 seems to be the correct one, but we need some support from the parsing.api to be able to pass metadata between the
providers
#2 complicated since I would have to combine logic of more languages in one provider. JSP->HTML embedding provider is
now simply returning HTML embeddings for all html tokens. If fixed this way, I would have to find javascript in these
pieces and strip the content.
#3 possible, but hacky
#4 possible, easy and seems safe as a workaround assuming the order of the embedding providers and subsequently of the
parser results from (resultIterator.getParserResult(offset) is guaranteed and follows the order of the factories
registrations in the layer.

I made the #4 fix for now.

Hanzi, please verify, especially whether the #4 assumption is true.

I reverted the fix since it was incorrect

fixed in web-main#ba38be332857

After agreement with Hanz I made a workaround in parsing api which resorts the TaskFactories obtained from mime lookup
so the JsEmbeddingProvider$Factory is the first one in the list.

This issue needs to be fixed properly later.

I would like to ask Hanz for review of the code change and Martin to verify the bahaviour. Thanks

FYI, I have filed a new issue 163208 - "Remove fix of issue #162990 and fix the issue properly"

Fix is OK.

Verified by QE in: web-main-433-on-090421

Integrated into 'main-golden', will be available in build *200904220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/79c2d727c412
User: Marek Fukala <mfukala@netbeans.org>
Log: #162990 - Scriplet element in onclick attr breaks JavaScript CC

fixed in release65_beta#76cd0074fd03

Verified in Nb 6.7 Beta (Build 200904230001) by QE.