The UploadServer requires html output from the InputFileRenderer, in the last lifecycle, after the file has completed uploading. Currently, this html output is stored in the session, along with some other InputFile parameters, which need to be in the session as well. When there's an IntervalRenderer going, it causes lifecycles to occur, which causes the InputFile parameters to be stored into the session. Except that those ones do not contain the html output. There's a polling loop in the UploadServer that looks for the html output. This html is what's returned to the browser. When it's not returned, the inputFile component appears to the user to have disappeared.

The real solution will involve not storing the html output in the session, but instead using a ThreadLocal field to capture it, and return it to the UploadServer. Then, any interleaved lifecycles unrelated to the file upload, can't interfere with the UploadServer response.

For ICEfaces 1.8 DR#3, because of a tight timeframe, I've just increase the polling frequency, so that the UploadServer is less likely to miss the html output, before the IntervalRenderer stomps it over.

Subversion 18104
icefaces\core\src\com\icesoft\faces\webapp\http\core\UploadServer.java

Instead of storing the iframe html content in the session, which provides a race condition, of server push renders putting their own results in the session, we now put it into the passed-in UploadStateHolder, which the UploadServer can hold onto, and use to directly retrieve the response html.

Also made some adjustments to the test application, since I think there were two problems with it.

Subversion 18190
icefaces\component\src\com\icesoft\faces\component\inputfile\InputFile.java
icefaces\component\src\com\icesoft\faces\component\inputfile\InputFileRenderer.java
icefaces\core\src\com\icesoft\faces\component\inputfile\UploadConfig.java
icefaces\core\src\com\icesoft\faces\component\inputfile\UploadStateHolder.java
icefaces\core\src\com\icesoft\faces\webapp\http\core\UploadServer.java

Subversion 18715
qa\Regression\acegi-fileupload\web\secure\main.jspx
qa\Regression\acegi-fileupload\web\WEB-INF\web.xml

I removed the polling frequency work-around, since it's no longer necessary.

This issue doesn't appear to be fixed. I'm using 1.8.0 and I'm seeing the inputFile html disappear. It doesn't happen all the time, but seems to happen almost always when the method that does the upload takes 30 seconds or more to complete.

Chad, which browser and version are you using? Is you internet connection stalling, or is the file just really large?

Thanks for the quick response Mark. The file is actually fairly small. But once I upload the file I run a process on it that takes about 30 seconds right after. The html seems to disappear about 2-5 seconds into the process (again not always, but most of the time; probably 3 out of 4 times). It happens in both firefox 3.0.10 and IE 8. Looking at the resulting html using firebug when the upload widget disappears I can see that the iframe that contains the component's contents no longer contains the html that it did before it disappeared.

Just another note: the progress indicator correctly shows that the file was uploaded fine once the method completes, its just the inputFile component that completely disappears.

As this JIRA is closed since it shipped with 1.8.0, please use the new follow-up JIRA issue that I created for future comments and tracking: ICE-4474.