|
Sort Order:
I'm at a bit of a disadvantage with testing on chrome
So we're saying that only chrome fails to find the idname element? Do we know whay that is? Jose - what do you mean by "posted to a new tab". Does that mean that chrome opens a new empty tab for the download? Is that down to the dwr.engine.openInDownload function? Joe. I meant that the submit, for some unknown reason, does not target the hidden iframe and hence opens a new tab/window. There's an added problem because the call response fails with an "Incomplete response from server" message (probably it has something to do with the new opened window). So, the file is posted correctly but if the remote method returns something that will be lost. I'll investigate a little bit more.
Tested under IE7/8, FF3 and Chrome.
It stills fails under Opera but that may very well be resolved under another issue Current code in HEAD fails on all browsers. This patch fixes it and adds (hopefully) chrome support
I'll apply it to HEAD and let you know my findings!
Jose, great fix, I can confirm that file upload now works with:
Google Chrome IE 6 IE 7 Safari 4 Firefox 3 Think this closes quite a few other bugs that are in "Unscheduled" at the minute (I raised one about file upload in general being broken in HEAD) Is this going to make it into HEAD? I applied to patch manually and it worked fine...
This last one seems pretty good. Solves the Opera issues as well
The last patch you attached still works but introduces a bug in non-IE browsers - the batch.div is created but never appended to the document body, this just moves the creation of the batch.div into the IE-only section (which appends it to the document body)
With reference to my last comment, the bug introduced was in the remove function, where batch.div existed but had no parentNode and was erroring:
remove:function(batch) { // TODO: make it so that we don't need these if statements if (batch.div) { batch.div.parentNode.removeChild(batch.div); } ..... Additionally the patch you applied causes a bug in chrome only, such that a file upload causes a new tab to open with a url of dwr/call/htmlcall/<method>. I have reverted back to the 2nd path (fileupload.patch) which for the minute seems to be the best working one.
There is still an outstanding issue here. I just tried the upload demo in the dwr.war in chrome and opera and it locked up both. Everything worked fine in IE and Firefox.
I take that back. I had actually reverted your patch :).
I just added it and re-tested. It works fine in all browsers. I also did not notice any of the issues described by James. James, I have checked in Jose's latest patch if you are interested in grabbing and building from svn. Still get the issue I reported before:
Non-IE bug introduced in the remove function, where batch.div existed but had no parentNode and was erroring: remove:function(batch) { // TODO: make it so that we don't need these if statements if (batch.div) { batch.div.parentNode.removeChild(batch.div); } Additionally can't test the chrome bug right now but i'd imagine it still remains since it's the same patch I applied manually... Jose, I am equally impressed by, and frightened by, the solution to get this working in Chrome etc :-)
I tried out the patch back in April and, as we discussed on the mailing list, getting it to work in Chrome et al seems to depend on creating a totally unrelated DIV before triggering the iframe request. This make me feel that there is something lurking inside the iframe code that will bite us soon again... I know Dojo has an iframe io provider, could you have a look at that and see if they manage without creating such a dummy element? I'm really hoping that you can find an updated solution. That would probably also fix the Opera part of DWR-241. BTW, the current file upload fails in Safari 2. I get an error dialog in the browser and an
INFO UploadDownload.uploadFiles(null, null, "FFFFFF") in the DWR log. Again, Safari 2 seems to be handled by the Dojo code so could be interesting to look at. I'll take a look and see if I find some way to stop that spinning in Chrome 1 and Safari 3...
I have now checked in a fix for getting a clean "iframe close" for Chrome 1 and Safari 3, which gets rid of the endless loading spinner.
Awesome, will give this a check tomorrow and let you know my findings!
|
|||||||||||||||||||||||||||||||||||||
Bug
Resolved
Major
File upload does not work in google chrome
batch.iframe = batch.document.getElementById(idname);
to
batch.iframe = batch.div.firstChild;
The form is posted to a new tab though