Hi Adnan,

I can't find that revision. The last revision I can find is 18493.

Hi,

We're using Icefaces 1.7.0. Will there be a patch that fixes this issue for 1.7.x? Or will the fix be just for 1.8? I'm afraid I'm not familiar with the way Icefaces operates in these cases (current stable is 1.7.x, current RC is 1.8).

I agree with Alfredo. We are using 1.7.2 SP1. I tried out of curiosity our portlets (liferay) with 1.8 RC1. It didn't even render I get an exception(below).

Are there any plans for 1.7 SP2? I don't think at this point in the project we can switch to 1.8 even if the fix is already in the trunk

21:02:43,281 ERROR [jsp] org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to insert a node where it is not permitted.
at com.icesoft.faces.context.DOMContext.setRootNode(DOMContext.java:288)
at com.icesoft.faces.renderkit.dom_html_basic.FormRenderer.encodeBegin(FormRenderer.java:95)
at com.icesoft.faces.component.ext.renderkit.FormRenderer.encodeBegin(FormRenderer.java:53)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:813)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:514)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:522)
at com.icesoft.faces.application.D2DViewHandler.renderResponse(D2DViewHandler.java:522)
at com.icesoft.faces.facelets.D2DFaceletViewHandler.renderResponse(D2DFaceletViewHandler.java:282)
at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:153)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor.apply(JsfLifecycleExecutor.java:17)
at com.icesoft.faces.context.View$2$1.respond(View.java:47)
at com.icesoft.faces.webapp.http.servlet.ServletRequestResponse.respondWith(ServletRequestResponse.java:167)
at com.icesoft.faces.webapp.http.servlet.ThreadBlockingAdaptingServlet$ThreadBlockingRequestResponse.respondWith(ThreadBlockingAdaptingServlet.java:36)
at com.icesoft.faces.context.View$2.serve(View.java:72)
at com.icesoft.faces.context.View.servePage(View.java:129)
at com.icesoft.faces.webapp.http.core.MultiViewServer.service(MultiViewServer.java:53)
at com.icesoft.faces.webapp.http.common.ServerProxy.service(ServerProxy.java:11)

There is a problem with the original test case, fileUploadDemo.zip. The failing case fails on IE (& elsewhere) because there's basically a typo in the javascript – the action references "upload.html" instead of "uploadComplete.html". The "fileUploadDemo2.zip" attachment has that fixed.

BTW, the test case also fails on Safari 4 beta for Windows.

On Opera (9.64), there's a twist – the test case works if served up from a webserver, but fails if you just open the page from disk. In the failing case the error console says "Network - file://localhost/C:/TEMP/bugtest/uploadComplete.html The loading of the URL has been blocked for security reasons."

I'm going to add this test case to the bugzilla entry at https://bugzilla.mozilla.org/show_bug.cgi?id=481647, as the Mozilla folks might fix it there.

I am also using this control in my application. I have complain from users using Fire Fox browser. Please let me know if there is any work around to problem.