[jira] [Commented] (TRINIDAD-1811) Tabs in facelets are escaped in the rendered page instead of being passed as is

["Ashish Solia (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925633#comment-13925633 ] 

Ashish Solia commented on TRINIDAD-1811:
----------------------------------------

I have looked into the source of TrinidadImpl and looks like org\apache\myfaces\trinidadinternal\io\XMLEscapes.java is the cause.

Here, we are building an array of characters, that need to be escaped, namely __BASE_ENTITIES

static final String[] __BASE_ENTITIES contains list of characters to be escaped including 	

On changing.
 "	", // invalid HTML/XML character 
to null, 

I don't see the tabs getting escaped, I verified this by doing a view source in my JSF page.

Can somebody analyze this further and provide the fix, as I see quite a few people have reported this.

Regards,
Ashish


> 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
> >>>>> "&#9;" 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 &#9; 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 was sent by Atlassian JIRA
(v6.2#6252)