DWR

Change line 1485 of engine.js from

batch.iframe = batch.document.getElementById(idname);

to

batch.iframe = batch.div.firstChild;

The form is posted to a new tab though

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.

Let's hope...

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!

I have the same exact bug right now with Chrome 5.0.375.29 beta (on linux) and DWR RC1 (build 116)
Is there a way to work around this bug while waiting for RC2 to come out ?
Is there planning on RC2 release ?

Get the latest dev build from http://ci.directwebremoting.org/bamboo/ to sort this out.
Hopefully we will get RC2 out soon.

Could anyone give me the engine.js file updated solving this issue?

Get the latest trunk build artifacts from here:
http://ci.directwebremoting.org/bamboo/

I tried but I don't know how to do it, I don't see the links to download the files, I just get the file names.

That is because a build was active. You would need to go to the history during an active build. Anyway the build is done now:

http://ci.directwebremoting.org/bamboo/browse/DWRTRUNK-ALL-171/artifact

Thank you. I downloaded the dwr.jar file, but now, my AJAX functionality is not working.
With the normal DWR version 3.0.rc1, I just need to upload pictures with browsers as Safari and Chrome, due to in Firefox and IE It works properly.

Hope you can help me.

1) You need to ask a question on the mailing list, this is not the proper place to ask questions.
2) You also need to provide more information, as "not working" doesn't help anyone (always helps to do some debugging on your own as well).

I will try to help find this out. Thank you very much for your help.

After downloading the 171 artifact, when I use a DWR Object, I receive the next javascript error:

"FormBeansDWR" is undefined.

I am using the next DWR.xml in my prroject:

<!DOCTYPE dwr PUBLIC
"-//GetAhead Limited//DTD Direct Web Remoting 3.0//EN"
"http://getahead.org/dwr//dwr30.dtd">
<dwr>
<allow>
<create creator="new" javascript="FormBeansDWR">
<param name="class" value="com.miramiobra.dwr.FormBeansDWR"/>
</create>
<create creator="new" javascript="UtilidadesDWR">
<param name="class" value="com.miramiobra.dwr.UtilidadesDWR"/>
</create>
<convert converter="bean" match="com.miramiobra.dwr.bean.*"/>
</allow>
</dwr>

Hope you can help me. Thanks.

I told you to post your question on the users mailing list:
http://java.net/projects/dwr/lists/users/archive

You should probably create an account and subscribe to the list.

I recommend looking at the troubleshooting page before posting as this is something you should not have to ask about:
http://directwebremoting.org/dwr/support/common_problems.html

I also recommend looking at the log files.

Also, the build you downloaded is working fine. I deployed it to our server and it is currently running the demos without issue:
http://directwebremoting.org/dwr-demo/

We have the same build version deployed and everything works fine (I just tested the file upload demo in both Firefox and Chrome):
http://directwebremoting.org/dwr-demo/simple/upload.html

I told you several times to ask your questions on the mailing list. I am not sure why you refuse to follow simple directions.

Sorry David if I didn't open the question in the mailing list.

The trouble was the cache in the browser. I delete everything and now AJAX DWR is working perfectly (uploading functionality works fine in the browsers...)

Thank you very much for your help. I appreciate so much your help.

try this jar file to make the upload work on crome, IE,mozilla etc.....

This problem has been fixed in trunk for upcoming RC2, are you saying it is not working there?

Thanks Pakaj. But as Mike mentioned this has been fixed and has been in a fixed status for sometime.

You can get the latest development build which contains the fixes here - http://ci.directwebremoting.org/bamboo/browse/DWRTRUNK-ALL-250/artifact.

I have been testing for the upcoming release and the upload works in the latest version of all major browsers (chrome, ie, firefox, opera).