Tabs in facelets are escaped in the rendered page instead of being passed as is
-------------------------------------------------------------------------------
Key: TRINIDAD-1811
URL: https://issues.apache.org/jira/browse/TRINIDAD-1811
Project: MyFaces Trinidad
Issue Type: Bug
Components: Facelets
Affects Versions: 1.2.13-core
Environment: Running with MyFaces 1.2.8, Facelets 1.1.14 and Tomahawk
1.2.9
Reporter: Stéphane Rondinaud
Attachments: TrinidadFaceletsTest.zip
Following a change from Trinidad 1.2.12 to 1.2.13, the tabs in the facelets of
our project started to appear escaped as "#&9;"in the rendered page, instead of
appearing as tabs as it was the case with the previous version.
The behaviour difference has been tested with a minimal test case for both
1.2.12 and 1.2.13.
What's following is the email exchange on the user mailing-list that lead to
this bug report.
---------------------------------------------------------------------------
Stéphane,
Thanks for verifying the difference in behavior.
You are right - Mojarra and MyFaces allow the tab character to remain
unescaped.
Mojarra in particular allows 4 control characters to appear in the
output: LF, TAB, CR, FF
Trinidad allows only LF and CR. Given that XML spec explicitly allows
the tab character to appear
in the document (http://www.w3.org/TR/REC-xml/ - Legal characters are
tab, carriage return, line feed, and the legal characters of Unicode and
ISO/IEC 10646),
I think we should modify Trinidad to allow TAB characters to remain
unescaped.
Could you file a Trinidad JIRA for this issue? Although the fix would be
trivial, we want to make sure that there
are no objections to the change.
Regards,
Max
Stéphane Rondinaud wrote:
> Hello Max, hello all,
>
> Attached is the tests Max requested. All tests runs with an "mvn
> integration-test".
>
> The archive has 3 directories:
> - JSF RI + Facelets
> - Myfaces + Facelets
> - the same test with Trinidad 1.2.13 as before failing on the
> escaping integration test
>
> The RI/Myfaces + Facelets tests exhibit what I'd consider normal
> behaviour (i.e. tabs getting through as tabs, unescaped), the trinidad
> still escaping them as "	".
>
> Feel free to ask any additional tests you see fit,
>
> Best regards,
>
> Stéphane
>
>
>
>
> Le 17 mai 10 à 21:49, Max Starets a écrit :
>
>>
>> Stéphane,
>>
>> I believe Trinidad was always supposed to escape tab characters.
>>
>> Could you try your sample with MyFaces+Facelets and JSF RI+Facelets
>> without Trinidad?
>>
>> Thanks,
>> Max
>>
>> Stéphane Rondinaud wrote:
>>> Hello Max,
>>>
>>> The trouble when using a handful of framework is that when something
>>> breaks, the question is always to "which one is broken?". If I
>>> posted here, it's because Trinidad was the only framework that
>>> changed when the problem happened.
>>>
>>> You'll find attached a lightly modified version of the test case.
>>> It's a maven project again, and the integration test is illustrating
>>> the problem. It expects a trinidadRelease parameter as follow:
>>>
>>> mvn -DtrinidadRelease=12 integration-test
>>>
>>> => this results in no problem on the integration test
>>>
>>> mvn -DtrinidadRelease=13 integration-test
>>>
>>> => this results in a failure of the test checking the presence of
>>> "	" in the output page
>>>
>>> Now it could be that up to and excluding release 13, Trinidad was
>>> incorrectly dealing with the tabs by passing them as is to the
>>> output page. Thus we'd have built our application on a false
>>> premise, thus the current problem?
>>>
>>> I suspect a little regression though: the revision I indicated in my
>>> previous post was modifying a serious bit of code in files named
>>> HtmlEscapes/XmlEscapes or something similar. I've got had time yet
>>> to delve into Trinidad code but the fact that between release 12 and
>>> 13 the behaviour changed strikes me as a more than probable cause of
>>> the problem.
>>>
>>> Best regards,
>>>
>>> Stéphane Rondinaud
>>>
>>> Le 17 mai 10 à 17:12, Max Starets a écrit :
>>>
>>>>
>>>> Hi Stéphane,
>>>>
>>>> I was able to reproduce your problem, but I believe this is more of
>>>> a Facelets issue.
>>>> The Facelets engine is using ResponseWriter.writeText() to render
>>>> all text between the tags
>>>> including the white space. Since the tab character is not a valid
>>>> HTML/XML character, Trinidad
>>>> is escaping it, as I believe it should given that it is being asked
>>>> to write text.
>>>>
>>>> Note that you would get ResponseWriter.write() being called if you
>>>> had a JSPX document.
>>>> I think your only choice is to replace the tab characters with
>>>> space characters.
>>>>
>>>> Is it only me, or do you guys think that Facelets/JSF2 should be
>>>> exposing SKIP_WHITE_SPACE context
>>>> parameter just like it does with SKIP_COMMENTS ?
>>>>
>>>> Max
>>>>
>>>> Stéphane Rondinaud wrote:
>>>>> Hello all,
>>>>>
>>>>> I needed to update to 1.2.13 to solve a problem with search engine
>>>>> bots generation NPEs, and just after the switch, I realized that
>>>>> some tabs present in the different facelets pages were getting
>>>>> through to the output page escaped as "	", ruining my attempt
>>>>> at having conforming webpages - the tabs being in the
>>>>> <head></head>, the validation fails...
>>>>>
>>>>> I traced back the problem to commit 886958 related to bug
>>>>> TRINIDAD-1655. What's bothering me is that I seem to be the only
>>>>> one to have this problem as I couldn't find any post on the
>>>>> mailing list about such a problem.
>>>>>
>>>>> You'll find attached a minimal maven project illustrating the
>>>>> problem. Launching it by "mvn jetty:run" and browsing to
>>>>> http://localhost:8080/TrinidadTest/ will return a page with some
>>>>> "	" in place of regular tabs.
>>>>>
>>>>> One last thing: I tried to use a Selenium test to track the
>>>>> problem but it seems that the "getHtmlSource()" method replaces
>>>>> automatically the 	 with regular tabs, thus rendering the test
>>>>> useless.
>>>>>
>>>>> Please feel free to request anything that could help finding the
>>>>> cause of the issue,
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Stéphane Rondinaud
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
