escaping xml / html in tables

[legatoloco]

I have function that expects a content that looks like

{"xml":"<script><tag>content</tag></script>"}

(as a map)
when building the table for this, it looks like

| check | functionName; | !{xml:<script><tag>content</tag></script>} | output |
This breaks the wiki rendering due to the unescaped <script> element. the function receives a completely broken xml

| check | functionName; | !{xml:!-<script><tag>content</tag></script>-!} | output |
This breaks the function as the xml is never unescaped

I assume that one of !- or !< (which didn't do anything, ended up not interpreting the !< and considering it part of the text) is supposed to

1. escape before rendering
2. unescape when building parameters for the function

Which one should it be? and in all cases, I believe that both are broken.

[amolenaar]

This is kind of a nasty one. The Slim test system runs the HTML, not the wiki text. As a result, elements are passed on the way they are rendered in the HTML page.

Your assumption 1. is true: the !- operator just takes the contents of the "escaped" block and adds it to the page. Seems like '!<' has not done anything for quite a few years (I checked even back to 2012). I'll remove it from the reference guide.

About assumption 2, the map is sent to Slim as a html <table>. We might want to look into unescaping values inside that table (on the slim server side) when it's converted back to a Map. For that we'd need the same logic as being used in fitnesse.testsystems.slim.HtmlTable.

A short-term solution would be to unescape the contents in the fixture (call HtmlUtil.unescapeHtml()).

[amolenaar]

This is kind of a nasty one. The Slim test system runs the HTML, not the wiki text. As a result, elements are passed on the way they are rendered in the HTML page.

Your assumption 1. is true: the !- operator just takes the contents of the "escaped" block and adds it to the page. Seems like '!<' has not done anything for quite a few years (I checked even back to 2012). I'll remove it from the reference guide.

About assumption 2, the map is sent to Slim as a html <table>. We might want to look into unescaping values inside that table (on the slim server side) when it's converted back to a Map. For that we'd need the same logic as being used in fitnesse.testsystems.slim.HtmlTable.

A short-term solution would be to unescape the contents in the fixture (call HtmlUtil.unescapeHtml()).

[amolenaar]

I suppose this is what you're looking for:

The value printed by the SUT on stdout is:

Hash script is <script><b>bold</b></script>

Hence, the hash value is properly unescaped by FitNesse, just like a normal value passed to the SUT.

[amolenaar]

I suppose this is what you're looking for:

The value printed by the SUT on stdout is:

Hash script is <script><b>bold</b></script>

Hence, the hash value is properly unescaped by FitNesse, just like a normal value passed to the SUT.

[legatoloco]

I guess so (unless i miss-understood your example)
This is the java function i'm using:
public String testmap(Map value){
return "something";
}
And these are the two options i have when passing the xml

which gets rendered in view mode as:

and in test mode as

If you debug the code, "value" is equal to:

1. 
2. 

Which shows that if I don't escape the xml myself, i get it escaped <script>
while if i do escape it first, it breaks the rendering in wiki (because now we do get the actual <script>, visible when you view-source) which breaks the html renderer of the browser, and generates the broken (but un-escaped code show in point 2)

Excuse the screenshot, but given that this is an encoding issue, i didn't want to add more confusion due to the github issue editor (which requires it's own escaping)

Related observation (but might require opening a different issue)

Check how the rendering fails differently in view vs edit mode.

Of course, not escaping has a better result when working with strings and not maps (like in the last two screenshots) as the content is sent correctly when not escaped, except that scripts are executes (the reason why the example i sent says "ablert" and not "alert"

[legatoloco]

I guess so (unless i miss-understood your example)
This is the java function i'm using:
public String testmap(Map value){
return "something";
}
And these are the two options i have when passing the xml

which gets rendered in view mode as:

and in test mode as

If you debug the code, "value" is equal to:

1. 
2. 

Which shows that if I don't escape the xml myself, i get it escaped <script>
while if i do escape it first, it breaks the rendering in wiki (because now we do get the actual <script>, visible when you view-source) which breaks the html renderer of the browser, and generates the broken (but un-escaped code show in point 2)

Excuse the screenshot, but given that this is an encoding issue, i didn't want to add more confusion due to the github issue editor (which requires it's own escaping)

Related observation (but might require opening a different issue)

Check how the rendering fails differently in view vs edit mode.

Of course, not escaping has a better result when working with strings and not maps (like in the last two screenshots) as the content is sent correctly when not escaped, except that scripts are executes (the reason why the example i sent says "ablert" and not "alert"

[amolenaar]

And my table looks like this:

| script | hash fixture |
| send | !{script:<script><b>bold</b></script>} | as hash |
| check | hash | script | is | <script><b>bold</b></script> |

So in your example, that would translate to:

| check | testmap; | {code: <script><nested>ablert(1)</nested></script>} | <script><nested>ablert(1)</nested></script> |

Which yields the desired effect, right?

[amolenaar]

And my table looks like this:

| script | hash fixture |
| send | !{script:<script><b>bold</b></script>} | as hash |
| check | hash | script | is | <script><b>bold</b></script> |

So in your example, that would translate to:

| check | testmap; | {code: <script><nested>ablert(1)</nested></script>} | <script><nested>ablert(1)</nested></script> |

Which yields the desired effect, right?

[amolenaar]

Oh no! My "fix" caused nested hash tables to not render properly :(. Back to the drawing board...

[amolenaar]

Oh no! My "fix" caused nested hash tables to not render properly :(. Back to the drawing board...

[amolenaar]

#886 has been merged

[amolenaar]

#886 has been merged