reproducible

not simple fix, since in the situation when the style attribute value is empty there is no css token so the css
completion is not even called. Probably requires implementation of some internal API to be able to explicitly call
Schlieman't CC in such cases. 

the same applies also for inlined javascript - see issue #99784

*** Issue 99784 has been marked as a duplicate of this issue. ***

*** Issue 121217 has been marked as a duplicate of this issue. ***

still valid in 6.1 using the new GSF infrastructure. This needs to be fixed in 6.1

many duplicates, very visible issue

The reason why the completion of JS and CSS doesn't work in the empty attribute value is that there isn't actually any
token of the JS or CSS language. There is an embedding for the HTML VALUE "" token created but the start and end skip
lenghts are set to 1 to skip the quotation chars so no token is there in fact.

The GSF implementation of CompletionProvider recusrivelly traverse the token hierarchy on given offset, finds instances
of Completer class for the found languages and gets results for them. This however doesn't work for the reported usecase
where the algoritghm doesn't find the JS or CSS language and hence the JS or CSS Completer is not used.

I tried to workaround the problem in the embedding language - HTML - so it's completion provider explicitly lookups the
JS or CSS Completer instance if the completion is invoked in empty value of onxxx or style attribute and gets the
results for the given position. I was able to that but for the price of doing several hacks in gsf module - making some
fields and classes public and exposing **/completion package. However I run into several problems which don't seem to be
elegantly resolvable - under some circumstances I was getting NPEs from GSFCompletionProvider - likely caused by the
fact I used own Source.runUserActionTask() to get and pass CompilationInfo to the completer?!? Since the
CompletionProvider providing the JS and CSS items was in fact the HTMLCompletionProvider there were some problems with
filtering of items as well. So I was able to complete JS in onclick="" and CSS in style="" but too many hacks were done
and some issues were still unresolved. So I decided to throw it away and do it IMHO the right way - extending the GSF
framework to cover this cases.

Currently there is an implementation of Completer bound to a mimetype. Based on the embedded tokens' types on the caret
position the right instances are used.

We need to be able to trigger the Completer-s even if there is no token of its 'native' language. (BTW another case for
this is JSP-HTML completion - we offer both JSP and HTML items even if there is just html token).

IMHO the embedding language should be responsible for this type of binding, not the embedded one. So HTML would bind the
JS and CSS completers to the desired places.

The way how this can be done is to create something similar to EmbeddingModel:

class CompletionResolver {
    public List<Language> resolve(Document doc, int position); 
}

This could be registered in the global lookup the same way as the EmbeddingModel and called on each completion
invocation. The corresponding completers from the returned list of Languages would be triggered then.

The impl. would be registered by the embedding language.

There are plenty of other variants of the API and the registration of the impl (by mimelookup for example or just adding
the method to EmbeddingProvider) but the main idea is clear I hope. Nice think on this variant is that it is compatible,
no need to modify the existing lang. impls.

Can you Tor express your opinion on that? I would like to hear it before implementing it this way. I already lost half
of day trying to do the workaround :-). Thanks.

Hi Marek,
that looks like a good solution, especially for a 6.1 patch since there's no incompatible change anywhere.

I assume that your Language class here is referring to the lexer language, not the GSF registry language (which isn't
part of the GSF API - it would need to be the mimetype instead if not the lexer language).  

Just to be clear: the completion resolver would only be called on languages present in the language hierarchy
surrounding the caret, correct? In other words, in an HTML file with the caret inside an empty JavaScript attribute
value, only the HTML completion resolver would be asked to return additional mimetypes/languages to check. If the
JavaScript attribute value is nonempty, the JavaScript resolver would also be asked. Other possible resolvers, like the
PHP resolver or the CSS resolvers would not be involved here. Correct?

I've added support for this in GSF now (changeset 314c89edcbe2). 

I didn't want to check in anything in the css.editor or html.editor codebases, but I'm attaching a patch which
implements the html+css side of this to actually fix this bug.

The CSS part is trivial; just modify the CSS editor such that it doesn't insist on being invoked on top of a CSS token
sequence. If there is no token sequence for CSS there, or if the prefix is null, it just returns a set of completion
items for the CSS property names.   (JavaScript had the same issue, which I fixed in the above changeset).

The HTML part is slightly more involved. HTML doesn't use a GSF code completion handler. However, the NetBeans editor
completion architecture lets you have multiple completion providers, so I added one - it shouldn't interfere with the
existing one.   What this CompletionProvider does is, return CodeCompletionResult.NONE in almost all cases. This will
have no effect.  However, it looks at the caret, and if it finds that the caret is in a VALUE_JAVASCRIPT token, or if
it's in a VALUE token and the ARGUMENT token was a "style" argument name, it then tells GSF (via the new
"embeddedTypes()" method on CodeCompletionResult) that there are possible additional embedding completion items for
text/x-css or text/javascript.  GSF will then call these completion providers to do their thing.

As you can see, this is slightly different than the global lookup approach.  Here, the embedding language gets to decide
how to handle the embedding scenario as part of its own computation - and it communicates this via the code completion
result. This seemed easier to coordinate than having these code completion providers called in some arbitrary order by
GSF.  And if HTML used a GSF code completion handler for all its completion, the computation with the token hierarchy
would only have to be done once anyway.

Let me know if you have any comments on this.

Created attachment 62291 [details]
Proposed fix

Tor, I think the CodeCompletionHandler's result.setEmbeddedTypes(...) method is enought and covers the described
usecases (supposing the infrastructure handles the case where I also return some items along with setting the embedded
types. Thanks for the patch I'll apply it.

applied 

http://hg.netbeans.org/main/rev/2f6f4db79550

Integrated into 'main-golden', available in NB_Trunk_Production #237 build
Changeset: http://hg.netbeans.org/main/rev/2f6f4db79550
User: Marek Fukala <mfukala@netbeans.org>
Log: #114348 (applied Tor's patch) -[cc] cc doesn't work in inline style or script without a letter suggestion

verified in HTML editor.
NetBeans IDE Dev (Build 200807030102)
the same problem appears in JSP - I've filled different issue about it see #138928

Are you sure this has been fixed? I'm testing NB 6.5 (Build 200811100001) on Vista and the problem is still there.
Actually, *sometimes* it does work, but most of the time it doesn't (at least the way I use the editor), namely:

start typing
<span style=""

most of the time, cc pops up. Ok, pick some style (say color:red). After you arrive at

<span style="color:red; |"

when invoking CC at the cursor position marked with (|) "No suggestions" comes up. Curiously, if you finish the tag and
close the element and return to the same cursor position:

<span style="color:red; |"></span>

it works.

reproducible. It is different issue, but lets keep this open opened.

The usecase with css CC not working inside unclosed html tag works fine in jet-parsing-api builds.

Now it seems the code regressed again in jet-parsing-api.

<div style="|"/>

<div onclick="|"/>

None of the cases above offers completion items on the pipes positions.

fixed.

changeset:   118789:c5afc985594f
tag:         tip
user:        Marek Fukala <mfukala@netbeans.org>
date:        Mon Mar 09 15:20:48 2009 +0100
summary:     CSL completion cleanup - removed CodeCompletionResult.embeddedTypes() since the usecases are seamlessly
covered by parsing API virtual sources.

verified.
NetBeans IDE Dev (090316)