Major Advanced File Uploader Bug - doesn't work on Mac OS & Safari

[black-eye]

What Version Of Caldera Forms, WordPress and PHP Are You Using?

WordPress Version: 4.9.5PHP Version: 7.1.17MySQL Version: 10.1.26Caldera Forms Version: 1.6.1.1WP_DEBUG:

What Is The Unexpected Behaviour?

When my client (on Mac OS & Safari) tried to send the form here: https://www.humangarden.com/test-web/obsazovane-pozice/, form get stucked after submitting. It happened just in Safari, in Chrome it was OK. When I switched the field to simple (non advanced) uploader, it was OK.

On the other hand, while using simple uploader I'm unable to send multiple files, even though this option is checked.

What PHP Errors Have You Logged While Reproducing This Bug?

Unfortunately I'm on Windows and client is unable to provide this info.

What JavaScript Errors Have You Seen While Reproducing This Bug?

Unfortunately I'm on Windows and client is unable to provide this info.

[black-eye]

UPDATE:
To isolate the problem to its core, I created a clean WP install just to test the upload form, here it is: https://www.humangarden.com/prac/caldera-upload/

Just WP 4.9.5, Twenty Seventeen Theme and Caldera 1.6.1.1. nothing else. Problem stays.

Please make a repair ASAP. It makes the forms with advanced upload fields unusable on Mac.
Important note: the form isn't submitted even though, you haven't upload any file - the problem is the pure presence of the field in the form.

And it's not just UI problem, the data aren't submitted either.
Big thanks.

[Shelob9]

Thanks for the details. Looks like the file upload request works fine, but then Safari is getting a 400 error from nginx (on your test site and in my local test environment) for the form submit request. It's never gets to WordPress at all when making the request to upload.

This is probably going to require rewriting form submission from scratch. Fuck.

[black-eye]

Ouch, sounds like bad news. :(
I suppose this will take some time to figure it out.

As a workaround, I would be fine using the simple uploader, but it has it's own bug too. It won't allow selecting multiple files. Even though I check corresponding option, the attribute "multiple" is not added to the input tag code.

And one more question concerning simple uploader - what is the real purpose of the extra button "Add Files", which is added, when selecting Multiple?

Thanks

[chemann]

Same major problem with WP 4.9.6. Caldera Forms 1.6.3. Not possible to use advanced file upload from Chrome nor FireFox. Some of help? Only simple file upload works.

Worried about new customers arriving to the web, not proper image of our enterprise and possible leads missing...

[Shelob9]

I am done with GDPR stuff and back to this.

Here is what I know

• By design, an advanced file field makes 1 or more AJAX requests to upload the form to the endpoint (created using rewrites API, not REST API) /cf-api/<form-id>/upload, then the rest of the data is submitted to /cf-api/<form-id>
• This works fine in Chrome
• If there is no file field in the form, the form submits to /cf-api/<form-id> and everything is fine, in Safari/Chrome/etc.
• In Safari, the AJAX request to upload the files work fine.
• In Safari, the request to process the form does not ever get to WordPress. I get an nginx 400 error. In my local and on test site and on @black-eye test site. http://dev-caldera-testing.pantheonsite.io/file-test-simple/
• Eventually there is a JavaScript error because the JavaScript for the AJAX is not written to handle a 400 (that could be improved but doesn't solve the fact that there should not be a 400 error) TypeError: undefined is not an object (evaluating 'obj.jqxhr.responseJSON.data')
• This form generates no errors in the log or New Relic when submitted on Safari: http://dev-caldera-testing.pantheonsite.io/file-test-simple/

Theories

If a file upload field is in the form we create a new XMLHttpRequest object, and then modify it and that should not_ effect how other HTTP requests works, but clearly something is.

This least invasive fix would be to change how that works. Also:

We have var xhr = new window.XMLHttpRequest();

But in the docs for Safari they say to do var myRequest = new XMLHttpRequest(); and note that's not IE compatible. we've come full circle.

[Shelob9]

Notes on my call with Bluma:

• In Bluma's VM with Safari, we can not reproduce this. Does that tell us something about the event bindings? It must because a remote desktop controlling a VM is simulating click events.
• In Chrome and Safari, the form submit request is sending an octet stream for the file field. That's wrong, and is likely why the server is rejecting the form submit request.
• We wrote a hack solution to jQuery.remove() the file field (its wrapper and everything inside) after it is uploaded. that made the submission complete, but the the file field was not associated with the submission, even though it was saved. This is because removing the DOM node lost the control key that links the two submissions.

Proposed solution:
Just removing the DOM node isn't acceptable. If there is a validation error, the file field has to still be there for re-submit. Also, we loose the link for submissions.

I need to either modify how formData is created or how the file field changes after submission. Goal is to prevent uploading octet stream again, but to keep control linked.

Content-Disposition: form-data; name="fld_2747627"; filename=""
Content-Type: application/octet-stream


------WebKitFormBoundaryoPc5IcFYLyQ4Q98l
Content-Disposition: form-data; name="fld_2747627"

trupl5b17fdd4b8aee
------WebKitFormBoundaryoPc5IcFYLyQ4Q98l

[Shelob9]

Both the hidden field with control (bottom) and the file field with the file have the same name. 87% sure that's the issue

Possible places I broke this:

• Ensure entry ID is set, especially when doing file uploads #2343
• Use the correct form ID for file fields #2106
• a3d3218da104298dcd23b2dde66da0c7R57 !!!!
• !!!! Advanced file field required option doesn't block users to click and go to next page #2021 !!!!

[Shelob9]

So, the actual problem is that in the request to submit the form sends in POST request for that field the file (not needed) and the control ID we need for this to actually work. That's bad, Chrome handles it in a way that nGinx can make sense of the way we want it to, and the way Safari and Edge send it, shit goes wrong.

I hate how simple the solution I have is. But, once the file is uploaded we don't need it anyway, even if the validation fails, because the data is already on the server. We need to clear the file field out before form serialization happens. So, once the file is pushed into the upload, we can turn the hidden file field that advanced file upload UI is wrapped around into a hidden field, and empty it's value.

NOTE TO FUTURE SELF: Always use jQuery.val('') to empty a field fields value before setting it to anything else.

[Shelob9]

🌋 This should be fixed via #2588 🌋

[Shelob9]

🔥 🌋 Close via #2588