Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: EE-3.3.0.GA_P01
-
Fix Version/s: EE-3.3.0.GA_P02, 4.0
-
Component/s: ACE-Components
-
Labels:None
-
Environment:Jenkins EE 3 trunk Build #424
Server: WildFly 8 (not an issue on Tomcat7)
Browsers: all except Safari.
-
Assignee Priority:P2
Description
1) showcase > ace:selectMenu > all demos:
Component renders as in attached screen shot (capture.PNG).
This issue can be reproduced also with QA test application for selectMenu, if installed on WildFly8.
2) Ace:selectMenu inside ice:panelTabSet (tabSet.PNG).
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
After a lot of investigation, the only likely cause of this behaviour is the document type declaration in WildFly8. In tomcat, the document type declaration that gets rendered in the pages tested is this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Which is the same doctype declaration specified in all the xhtml pages tested. In contrast, in WildFly8, the doctype declaration that gets rendered is always this:
<!DOCTYPE HTML>
There doesn't seem to be any other cause/difference but this one. The rest of the rendered HTML is identical between tomcat and WildFly8. I verified all the applied CSS styles of several elements that compose the ace:selectMenu and ice:panelTabSet components, and all of them are exactly the same. The only difference is seen in the computed style.
I also tried removing CSS class names from the elements that compose these components as well as removing entire CSS style sheets and specific definitions, and none of that improved the issue.
Custom application CSS styles don't have anything to do either. The issue was still seen using a simple test page like the following:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:ace="http://www.icefaces.org/icefaces/components"> <h:head> <title></title> </h:head> <h:body> <h:form> <ace:selectMenu> <f:selectItem itemValue="test" itemLabel="test" /> </ace:selectMenu> </h:form> </h:body> </html>
Moreover, the ace:selectMenu component doesn't have a CSS file of it's own, and the issue with ice:panelTabset also failed when using a different componen such as ace:comboBox or a simple h:outputText, instead.
It seems that the issue doesn't have to do with CSS, but with the way that elements are arranged, while being under the effects of certain doctype declaration.
I could come up with a simple fix for the ace:selectMenu component, which consists in specifically setting the height of the container to that of the down arrow button. This works well on Tomcat as well. It hasn't been committed yet.
Try a simple non-ICEfaces application with a facelet page with custom doctype.
Using the test page above and changing the doctype declaration to <!DOCTYPE HTML> and deploying on Tomcat reproduced the same issue seen on WildFly8. So, we can confirm that the doctype declaration has something to do with this issue.
The code used was the following:
<!DOCTYPE HTML> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:ace="http://www.icefaces.org/icefaces/components"> <h:head> <title></title> </h:head> <h:body> <h:form> <ace:selectMenu> <f:selectItem itemValue="test" itemLabel="test" /> </ace:selectMenu> </h:form> </h:body> </html>
I made another test with plain HTML markup. I copied the HTML markup rendered by the component, removed the scripts, and removed everything else that ICEfaces renders. The end result was this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head> <title></title> </head> <body> <div class="ui-selectmenu " id="j_idt5:_t6"> <span class="ui-widget ui-corner-all ui-state-default ui-selectmenu-value " role="select" style="display: inline-block; width: 200px;" tabindex="0"> <span class="ui-inputfield ui-state-default ui-corner-left ui-state-optional" style="; display: inline-block; overflow: hidden; border-top:0;border-bottom:0;border-left:0;"></span> <div class="ui-state-default ui-corner-right" style="float:right; width:17px; border:0;"> <div></div> <div class="ui-icon ui-icon-triangle-1-s"></div> </div> </span> <input autocomplete="off" name="j_idt5:_t6_input" type="hidden" /> <div class="ui-widget ui-widget-content ui-corner-all ui-selectmenu-list" id="j_idt5:_t6_div" style="display:none;z-index:500;"></div> </div> </body> </html>
Since all the CSS stylesheets are not included, the page looks blank. However, you can still inspect the elements in the Chrome developer tools window and notice that the height of the first span (that with class ui-selectmenu-value, corresponding to the area that displays the value of the component) is 0, when using the transitional doctype declaration, which is normal. Then, after changing the doctype declaration to <!DOCTYPE HTML>, if you inspect that same span element, it will show a height of 18 pixels in Chrome. So, the doctype declaration definitely plays a role in how components look to the user.
Please also try a non-ICEfaces test with the Transitional doctype and an h:outputText to see if WildFly mangles the doctype even when ICEfaces is not present.
After creating a plain JSF application, and using the following facelet...
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <HTML xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns:ui="http://java.sun.com/jsf/facelets"> <h:head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title></title> </h:head> <h:body> <h:outputText id="test" value="test"/> </h:body> </HTML>
...WildFly 8 still used <!DOCTYPE HTML> as the doctype declaration. The whole HTML rendered was this:
<!DOCTYPE HTML> <HTML xmlns="http://www.w3.org/1999/xhtml"><head id="j_idt2"> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <title></title></head><body><span id="test">test</span></body> </HTML>
This apparently is a JSF 2.2 feature:
http://jsflive.wordpress.com/2013/08/08/jsf22-html5/
By default, JSF 2.2 always renders the HTML5 doctype <!DOCTYPE html> regardless of what is set in the source xhtml file. If you need the old JSF 2.1 behavior (passing through the doctype from the source) you have to change the way xhtml files are processed in the faces-config.xml like this (the complete list of processing modes can be found in the spec):
<faces-config-extension>
<facelets-processing>
<file-extension>.xhtml</file-extension>
<process-as>xhtml</process-as>
</facelets-processing>
</faces-config-extension>
Or use the h:doctype tag:
http://docs.oracle.com/javaee/7/javaserverfaces/2.2/vdldocs/facelets/h/doctype.html
Covered by JSF 2.2 Specification:
1.1.1.1 The facelets-processing element
http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html
When JSF 2.2 is used on Tomcat, does the same behaviour occur?
The most important outcome of this issue is for ICEfaces to generate HTML5-compliant markup.
This makes sense, except that this issue is being reported against EE 3.3 P02 which should be using JSF 2.1, not JSF 2.2?
For this test, the JSF version used was WildFly8 server's default v. 2.1.2.
This extra spacing is a known issue with HTML5. There are a number of possible solutions described on various sites...
http://www.emailonacid.com/blog/details/C13/12_fixes_for_the_image_spacing_in_html_emails
http://www.andymatthews.net/read/2011/01/02/Resolving-gaps-and-spaces-in-table-cells-when-using-the-HTML-5-doctype
http://bytes.com/topic/html-css/answers/943492-background-leaksbelow-image-table-cell-html5
As for the ice:panelTabSet issue. The extra spacing is simply caused by having an <img> element inside a <td> element, even if the <img> element has no source image. This can be fixed by adding line-height:0; to the <td> element. This fix doesn't break things with HTML4.
As for the ace:selectMenu issue, the fix seems more complex because of some other markup involved. So the fix could be the one reported above, done with Javascript.
Committed fixes to 3.3 EE maintenance branch at revision 41258 and to the P02 tag at revision 41260. Added specific fixes for the spacing issues in ice:panelTabSet and ace:selectMenu. The fixes for ice:panelTabSet involve using style="line-height:0;" on the <td> elements that compose the tab and also adding align="left" on the spacer <img> elements. The fix for ace:selectMenu consists in adjusting the height of the value field, as it is routinely done for the down arrow button.
Fix confirmed with EE 3.3.0_P02 Build9 / EE-3.3.0-maintenance branch rev. 41277 in showcase and selectMenu QA test app in IE10, Chrome35 and FF 29 on WildFly 8/ with Mojarra 2.1.28.
These issues are not dependent on the icefaces-ee-ext.jar being included or not in showcase.war file.