We have upgraded to GXT 2.5.0, which seems to be the only difference between our two cases. And, to clarify, we are using the GXT FormPanel (in case there is indeed any difference between it and the GWT FormPanel.)

The 'uploader' variable appears to be a Window, or some kind of dialog, or perhaps a progress message?

Here's a modified example, compiled with GWT 2.5.0 and GXT 3.0.3 that doesn not exhibit the behavior you are describing in Chrome 24 for me. Can you run this simple entrypoint and confirm that the bug is not occurring? Assuming so, can you try to make this more like your use case where the bug *is* happening?

I've also attached a zip containing the compiled files so you can test in your own browser, to ensure there isn't some other difference. I've compiled with <collapse-all-properties /> in my module to keep the compiled size down.

// Hook up the underlying iframe's onLoad event when attached to the DOM.
// Making this connection only when attached avoids memory-leak issues.
// The FormPanel cannot use the built-in GWT event-handling mechanism
// because there is no standard onLoad event on iframes that works across
// browsers.
impl.hookEvents(synthesizedFrame, getElement(), this);

If the FormPanel is not attached, it cannot properly submit, nor can it receive events. It sounds like you are telling me that your use case involves showing a window, hiding it, submitting it, and waiting for any updates to occur.

Instead, the FormPanel must* be attached somewhere. Can you try modifying your code to keep it attached (or re-attach it), and see if it solves this issue?

* In truth, it isn't quite as strictly required as I make it sound, but to to properly follow the GWT pattern of attach/detach and cleaning up any possible memory leaks, we need to do cleanup on detach. FormPanel could (possibly, I havent tested) be implemented to work in this way, at the risk of introducing memory leaks into all applications that use it.