[jboss-jira] [JBoss JIRA] (WFLY-11151) Wildfly 14 mixes up HTML response in JSF applications

[Tamás Ábele (Jira)]

    [ https://issues.jboss.org/browse/WFLY-11151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13687539#comment-13687539 ] 

Tamás Ábele commented on WFLY-11151:
------------------------------------

When I opened the issue and wrote about it, I did not identified the root cause. 
But now we are planning to patch the wildfly server, so I have more information about it.
The elementNames stack which is used for HTML tag renaming seems to be part of the Passthru Elements implementation. The first problem with the implementation was the 
"f:selectItems with value of type Map not working with HTML5 friendly Markup" issue
(https://github.com/javaserverfaces/mojarra/issues/3138)

It was solved with the followings:

* git log
!fix-1.png|thumbnail!

* git diff
!fix-1b.png|thumbnail!

Unfortunately this fix caused another problem. The issue is titled "Wrong ending tag when an "option" element is rendered after a pass-through element" and can be found: https://github.com/javaserverfaces/mojarra/issues/3727

It was solved with the followings:

* git log
!fix-2.png|thumbnail! 

*  git diff
!fix-2b.png|thumbnail! 

With the modifications above a problem which affected just Passthru Elements, now became a more common problem. If an option element (rendered by a JSF component) is on the page with a JSF component which does not close HTML tags right, than the JSF runtime will MIX up things.  Because we do not use Passthru Elements the problems started here and with wildfly 14. 

I do not like the 

{code:java}
if (original.equals("option"))
{code}

code in the HtmlResponseWriter class at all. The HtmlResponseWriter should not know that an option TAG name exists. It is wrong approach. 
But it is very hard to fix things now in a right way, so in our environment we are planning a patch which will make wildfly 14 as stable as wildfly 10 and a little bit even more. For this we are planning to do the following:

1)First we do not start using the elementNames stack when an option tag found. We use it only when the renaming is necessary. So in the com.sun.faces.renderkit.html_basic.HtmlResponseWriter class instead of this:

{code:java}
if (original.equals("option")) {
    if(elementNames == null) {
        elementNames = new LinkedList<>();
    }
    elementNames.push(original);
    return original;
}
{code}

we are planing to use this:

{code:java}
if (original.equals("option")) {
    if( (elementNames != null) && (elementNames.size()>0) ) {
        elementNames.push(original);
    }
    return original;
}
{code}

2)Secondly we do not want to use the elementNames stack after the tag was closed which needed the renaming. This will reduce the risk of an error. To do this we are planning to replace this:

{code:java}
if(!original.equals(name) || elementNames != null) {
    if(elementNames == null) {
        elementNames = new LinkedList<>();
    }
    elementNames.push(name);
}
{code}

with this:

{code:java}
if( (!original.equals(name)) || ( (elementNames!=null) && (elementNames.size()>0) ) ) {
    if(elementNames == null) {
        elementNames = new LinkedList<>();
    }
    elementNames.push(name);
}
{code}



> Wildfly 14 mixes up HTML response in JSF applications
> -----------------------------------------------------
>
>                 Key: WFLY-11151
>                 URL: https://issues.jboss.org/browse/WFLY-11151
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 14.0.0.Final
>            Reporter: Tamás Ábele
>            Assignee: Farah Juma
>            Priority: Major
>         Attachments: fix-1.png, fix-1b.png, fix-2.png, fix-2b.png
>
>
> Introduced in wildfly 14 we receive a new JSF implementation (developed years ago), which is based on mojarra 2.3.5. In certain circumstances this JSF runtime hides the real problem, and makes from an invalid HTML a valid one, and spoils it somewhere else you would never guess, or produces an invalid partial response. Anything can happen, and the real problem will be really hard to find. This behavior led to a more severe error than the original one in two reported cases at github.
> I opened an issue ([eclipse-ee4j/mojarra#4488|https://github.com/eclipse-ee4j/mojarra/issues/4488]) about this, but the mojarra development team closed this issue without solving it. Now a lot of teams starting to move towards wildfly 14. They are likely to face similar magical errors like us. In the other case ([jboss/mojarra#21|https://github.com/jboss/mojarra/issues/21]) the developer team switched back to JSF 2.2. I’m also worried to change to wildfly 14, because of the future magical errors it will cause in our systems.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)