Details
-
Type: Bug
-
Status: Closed
-
Priority: Minor
-
Resolution: Won't Fix
-
Affects Version/s: EE-4.0.0.GA, EE-3.3.0.GA_P03
-
Fix Version/s: EE-4.1.0.GA, EE-3.3.0.GA_P04
-
Component/s: Framework
-
Labels:None
-
Environment:All, ACE, MOBI
-
Assignee Priority:P1
-
Support Case References:Support Case #13629 - https://icesoft.my.salesforce.com/5007000001VfqUz
-
Workaround Exists:Yes
Description
The button uses an ajax tag with the following set (bodyTextarea is the id of the input field):
execute="@this" render="bodyTextarea"
On click of button any text entered into the field should be cleared out but the field is not being rendered in the update.
This issue is reproducible with the mobi:commandButton/mobi:ajax, h:commandButton/f:ajax and ace:pushButton/ace:ajax components.
When testing the same code in a pure JSF sample (no ICEfaces), the input field gets cleared out correctly.
-
Hide
- Case13629Example.war
- 8.82 MB
- Arran Mccullough
-
- META-INF/MANIFEST.MF 0.1 kB
- META-INF/context.xml 0.1 kB
- WEB-INF/classes/.../support/TestBean.class 1 kB
- WEB-INF/lib/icefaces-ace.jar 5.64 MB
- WEB-INF/lib/icefaces.jar 642 kB
- WEB-INF/lib/javax.faces.jar 2.55 MB
- WEB-INF/web.xml 2 kB
- index.xhtml 0.5 kB
- welcomeICEfaces.xhtml 2 kB
-
- Case13629Example.zip
- 20 kB
- Arran Mccullough
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Verified ICEfaces 4 trunk, EE- 3.3.0 maintenance branch r46964. Tomcat 8, FF 43, Chrome 47, IE 11.
When testing with IE 10/9 (EE -3.3) IE 9 (IF4) a popup error occurs before the page loads. After dismissing the popup the demo functions as expected.
Webpage error details User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET4.0C; .NET CLR 3.0.30729; .NET4.0E) Timestamp: Tue, 12 Jan 2016 21:09:02 UTC Message: Object doesn't support property or method 'info' Line: 17 Char: 265 Code: 0 URI: http://10.18.39.134:8080/ICE-10879/javax.faces.resource/icepush.js.jsf?ln=ice.push&v=4_1_0_160112
When testing the EE-3.3.0 maintenance branch with IE 8/7 the following popup error message appears. After dismissing the popup the demo functions as expected (IE 8 only).
Webpage error details User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET4.0C; .NET CLR 3.0.30729) Timestamp: Tue, 12 Jan 2016 21:50:07 UTC Message: 'instanceTag' is null or not an object Line: 118 Char: 9 Code: 0 URI: http://10.18.39.134:8080/ICE-10879/faces/javax.faces.resource/icepush.uncompressed.js?ln=ice.push&v=3_3_0_160112
New QA test applications at:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Manual/ICE-10879
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Manual/ICE-10879
I managed to run the IE4 test case but I could not reproduce the issue.
As for the EE- 3.3.0 maintenance branch test case I could not run it at all. There is no 'submit' button to update the bean value to later on clear it when testing.
Please advise.
The error are caused by the redirection strategy used in EE-3.3.0 test case. Some parts of the JS bridge are initialised only on page load. Since the redirection occurs while the body is loading the some of the objects are not there when the page unloads just before the redirect.
Applied fix that modifies the index page to execute the redirection only after the page is fully loaded.
Although the test works now the redirection strategy where a JSP index page is used for redirection would be recommended.
Verified ICEfaces 4 trunk r46970. Not able to reproduce issue with IF4 trunk. Modified EE-3.3.0 test app as suggested.
Tested with ICEfaces 4 trunk r46976.
The showcase ace:dataTable > Dynamic Columns, demo fails when selecting a checkbox. I traced this back to the commits made for ICE-10879 at r46955, 46956. The showcase ace:dataTable > Paginator demo also fails in the same manner (java.lang.IllegalArgumentException) when dynamically changing the paginator position. There could be additional demos failing.
Server log when Dynamic Columns demo fails:
14-Jan-2016 15:18:36.934 INFO [http-apr-8080-exec-5] com.sun.faces.application.v iew.ViewScopeManager.<init> CDI @ViewScoped bean functionality unavailable java.lang.IllegalArgumentException: checkbox at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.j ava:651) at org.icefaces.impl.context.DOMPartialViewContext.normaliseToClientIds( DOMPartialViewContext.java:337) at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPar tialViewContext.java:151) at javax.faces.context.PartialViewContextWrapper.processPartial(PartialV iewContextWrapper.java:219) at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:1004) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1856) at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView (FaceletViewHandlingStrategy.java:432) at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewH andler.java:134) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrap per.java:337) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha se.java:120) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52 ) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:219) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAcce ssLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:537) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp 11Processor.java:1085) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process( AbstractProtocol.java:658) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.pr ocess(Http11AprProtocol.java:277) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpo int.java:2407) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoin t.java:2396) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskTh read.java:61) at java.lang.Thread.run(Thread.java:745) 14-Jan-2016 15:18:56.605 SEVERE [http-apr-8080-exec-8] com.sun.faces.application .view.FaceletViewHandlingStrategy.handleRenderException Error Rendering View[/sh owcase.xhtml] java.lang.IllegalArgumentException: checkbox at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.j ava:651) at org.icefaces.impl.context.DOMPartialViewContext.normaliseToClientIds( DOMPartialViewContext.java:337) at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPar tialViewContext.java:151) at javax.faces.context.PartialViewContextWrapper.processPartial(PartialV iewContextWrapper.java:219) at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:1004) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1856) at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView (FaceletViewHandlingStrategy.java:432) at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewH andler.java:134) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrap per.java:337) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha se.java:120) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52 ) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:219) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAcce ssLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:537) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp 11Processor.java:1085) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process( AbstractProtocol.java:658) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.pr ocess(Http11AprProtocol.java:277) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpo int.java:2407) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoin t.java:2396) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskTh read.java:61) at java.lang.Thread.run(Thread.java:745) 14-Jan-2016 15:18:56.615 SEVERE [http-apr-8080-exec-8] null.null java.lang.Illeg alArgumentException: checkbox at javax.faces.component.UIComponentBase.findComponent(UIComponentBase.j ava:651) at org.icefaces.impl.context.DOMPartialViewContext.normaliseToClientIds( DOMPartialViewContext.java:337) at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPar tialViewContext.java:151) at javax.faces.context.PartialViewContextWrapper.processPartial(PartialV iewContextWrapper.java:219) at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:1004) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1856) at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView (FaceletViewHandlingStrategy.java:432) at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewH andler.java:134) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrap per.java:337) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePha se.java:120) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:291) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52 ) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:219) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:501) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAcce ssLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:537) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp 11Processor.java:1085) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process( AbstractProtocol.java:658) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.pr ocess(Http11AprProtocol.java:277) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpo int.java:2407) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoin t.java:2396) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskTh read.java:61) at java.lang.Thread.run(Thread.java:745)
Additional showcase demos failing in the same manner with java.lang.IllegalArgumentException:
ace:ajax > Advanced
ace:contextMenu > Effect
ace:dynamicResource > Overview
ace:menuBar > click to Display
all showcase dataExporter demos
Introduced a more resilient method that finds components by their client ID without looking at the ID's formatting (unlike UIViewRoot.findComponent). The IllegalArgumentException was thrown when the type of ID search for was not generated by a NamingContainer.
Verified ICEfaces 4 trunk, EE-3.3.0 maintenance branch r46988, Tomcat 8, IE 11, 10, 9, 8, 7, Chrome 47, FF 43.
Both myself and the customer is still seeing this issue. The only way I can get the input field to be cleared out is to submit the input field and then click the button. This wasn't described as a step in the initial report.
I will upload my sample and a set of steps to reproduce.
Attached test case and source code for reproducing the issue.
Steps:
- Load welcomeICEfaces.jsf
- Enter in some text into the input field.
- Click on one of the Clear buttons, doesn't matter which one, they both don't clear out the input field.
- If I enter in some text and click the enter key, there by updating the server, the value us cleared out on click of the buttons.
- Oddly enough when I test with the standard EE 3.3.0 P03 release, the values get cleared out without the need to submit the field.
- I have also cleared by browser cache in between tests as well.
Arran, if you want the buttons to clear up the text entry you need to add the text entry's ID to the list of executed components. By doing so the text entry component will get updated. When the text entry is not executed both corresponding input elements in the old and new DOM hold an empty string and thus no update will be generated.
Created ICE-10936 for the Fedex issue.
Is this an ICEfaces requirement then? My main cause of confusion was that this isn't required in a basic JSF only (No ICEfaces) sample. The input field is cleared without the need to include the id of the component in the f:ajax execute tag.
I would argue that ICEfaces is doing the right thing here while with just Mojarra you get the reset of the component as a side effect because the Mojarra updates are not so granular.
Re-opened for the regressions this commit has caused that are noted in ICE-10937.
I revisited the initial issue and also ran the attached test case and the one QA has created. Both of these tests are working fine with the code we had before any of the fixes were applied. This issue was created with the assumption that the behaviour of the updates should match what Mojarra does when running without ICEfaces. Also there was the confusion (on my part) on what are the exact steps to reproduce.
The difference in behaviour between Mojarra and ICEfaces is explained here http://jira.icesoft.org/browse/ICE-10879?focusedCommentId=62276&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62276 . Also the reason why we do not need to change is here: http://jira.icesoft.org/browse/ICE-10879?focusedCommentId=62290&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62290 .
Also I can confirm now that f:ajax will convert the component IDs to client IDs when the AJAX behaviour JS code is rendered. For some reason I thought that this normalisation is not applied by f:ajax and that is the reason why the fixes were applied.
So really we should just rollback the applied changes . That will also fix the side-effects that Art has discovered.
Rolled back fixes since they are really not necessary (see explanation above).
The issue occurs when the render IDs specified in the f:ajax facet represent component IDs. These IDs need to be translated to client IDs so that the visiting VisitContext for the subtree is receiving the client IDs it expects.
The fix normalises the render and execute IDs to represent only client IDs.