When you hover a node in the editor, you get a nice HTML-formatted tooltip with the properties of the node. Or when there is an error on the line, you get a tooltip with just the error.

In both cases the strings are not properly escaped.

For example, NaBL code with a string in a property:

of str "Test string with angled brackets: 'List<String>'."

Will display in the tooltip:

str: Test string with angled brackets: ‘List’.

Or this TS code with an error message:

else error $[Test string with angled brackets: 'List<String>'.] on expr

Will display in the tooltip error:

Test string with angled brackets: ‘List’.

---

A workaround would be to manually escape < by < and > by >, but I’m not sure if these escapes will show up somewhere in a non-HTML context.

Submitted by D. Pelsmaeker on 19 June 2014 at 11:53

The hover is indeed html, the properties view is not html.

Can you verify that the properties view shows 'List<String>'.

You can build a html-char-escape for the tooltips.
I can build a hook in the properties-pretty printer, but I do not have access to the warnings.
We could do auto escape, but that would disallow all kinds of other html features (like newlines and bold) in hover.

This requires some design decisions. What is the result of the hover strategy? If it is a string, HTML should be auto-escaped. If it is a HTML fragment, the user should escape it herself (or library strategies, which provide hover information, need to take care of it). Same holds for all kind of views.

I assume shared strategies for property tool tips, error messages, and property views are part of the confusion here.

As far as I can tell the result of the hover strategy is a HTML fragment. However, the user shouldn’t have to concern himself with the string representation, the library strategies should take care of this.

The properties-to-html strategy in runtime/editor/properties.str should escape strings. As for errors, warnings and notes: I’m not sure where they are formatted for the tooltip.

@Daco: The properties view correctly shows List<String>.

I agree on the properties-to-html strategy. Can you fix this strategy and submit a pull request?

For tool tips in general, there might be cases where the user wants to use HTML to have full control over the output. In these cases, she should do escaping on her own. But library strategies which are used to feed the tool tips might have HTML variants.

@Daniel: are you fixing the properties-to-html strategy and submitting a pull request?

I believe this has been fixed by pull request #12 on master:metaborg/runtime-libraries.

Ok, confirmed. closing issue.