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
