Don't create an html tag info for an invalid html tag inside a style block or a css file.

[RaymondLim]

This fixes issue #1277.

[peterflynn]

Out of curiosity, how does this square with the change in pull #1268? Why is it bad to filter on mode at the top level but ok to filter on mode at the token level?

[RaymondLim]

Good question!

Well, it may seem like we're removing the mode checking to fix #1268 and now we're putting back the mode checking to prevent us from incorrectly showing tag hints inside a style block. The mode checking we have before fixing #1268 is done too early and becomes too restrictive. It prevents us from inspecting all key strokes when the current context is already in js or css mode. When the user types a right angle bracket (>) to close a script tag or a style tag, the current context is switched to js or css mode right after the keypress event which is triggered before the keyup event. By the time we get the keyup event for ">" character, we're already in js or css mode, and thus the mode checking prevents us from handling the ">" character. This is why we have to remove the mode checking at the top level.

Now we put back the mode checking at the token level because we want to distinguish the state where the current cursor is inside a css block (after the <style> tag) and the state where we're still inside a tag.

[redmunds]

reviewing

[redmunds]

It looks like a good idea to check for this, but it seems like we'd want to check this for all cases. If so, then shouldn't this be the first check in this function?

[RaymondLim]

Agreed. will update soon.

[redmunds]

Why do you need to check for (ctx.token.className === "tag") here? Seems like we would want to bail out whenever (editor.getModeForSelection() !== "html") ?