See issue ICE-4138 for same problem in Safari 4 Beta.

This has become somewhat more urgent, as many have Firefox on auto-update and 3.0.6 doesn't seem to be available from mozilla.org any longer.

The reason that inputFile component is not working with FF 3.0.7 is that the "action" attribute of the upload form is being set to the web context based URI. Changing the URI to fully specify URL fixes the problem.
After debugging it came across that FF made some intentional changes (for security purpose) or a regression that if you create dynamic contents to the iframe, then any form inside must use fully specify URL to the form action.

The problem can be seen using the plain html test case attached as fileuploadDemo.zip

Hi Adnan,

Is it possible to change the URI by setting some XML attributes on a file input element, or what's the easiest way of applying your workaround?

Silvano

Hi Silvano,

It isn't possible to change the URI by XML. However the fix will be in upcoming release, which is pretty soon.

Adnan

Mircea's suggested patch applied, where contents of the Iframe served by the Resource API:

Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\inputfile\InputFileRenderer.java
Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\inputfile\InputFileRenderer.java
Completed: At revision: 18507

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.