When uploading files to a webform, the "File upload inprogress. Uploaded file may be lost." alert always displays, it seems the webform-auto-file-uploads property is never set to 0.

Issue must be in webform.element.managed_file.js but I haven't narrowed it down yet.

To replicate:

Use the webform below.
Upload 5 files.
Wait a few seconds and press submit. The dialog should show even though all files have been uploaded correctly.

page_1:
  '#type': wizard_page
  '#title': 'Page 1'
  file:
    '#type': managed_file
    '#title': file
    '#multiple': 10
    '#uri_scheme': public
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DanielVeza created an issue. See original summary.

DanielVeza’s picture

Title: File upload message always displays » File upload in progress alert always displays
luigisa’s picture

Hello,

you can remove the library in your theme (theme.info.yml) as follows

libraries-override:
webform/webform.element.managed_file: false

DanielVeza’s picture

Hmm. That is an interesting idea for a solution. Feels a little brute force, and I would lose the other benefits of that JS.

I've written some JS that disables the buttons until file uploads are complete. I'll trial disabling the library and just relying on this JS until the issue in fixed. I'll leave this issue open since I feel like there is a genuine bug here.

Disable button JS, in case anyone else wants it. (Note it's es6, so you'll need a compiler)

  Drupal.behaviors.fileUploadEnhancements = {
    attach: (context) => {
      const fileUploads = $('.form-item-attach-complaint-documents-and-or-supporting-material .form-type-checkbox', context);
      if (fileUploads.length >= 10) {
        const uploadInput = $('input[id^="edit-attach-complaint-documents-and-or-supporting-material-upload"]');
        if (uploadInput.length > 0) {
          uploadInput.prop('disabled', true);
        }
      }
      const buttons = [
        '.webform-button--next',
        '.webform-button--previous',
        '.webform-button--restart',
      ];
      $(context).ajaxStart(() => {
        for (const index in buttons) {
          if ($(buttons[index]).length > 0) {
            $(buttons[index]).prop('disabled', true);
          }
        }
      });
      $(context).ajaxComplete(() => {
        for (const index in buttons) {
          if ($(buttons[index]).length > 0) {
            $(buttons[index]).prop('disabled', false);
          }
        }
      });
    },
    detach: (context) => {

    },
  };
jrockowitz’s picture

With the attached webform if the uploaded file exceeds the upload limit the warning is always displayed.

DanielVeza’s picture

I've seen the same error happen when you upload ~5 files, even if files are under the limit.

luigisa’s picture

I get the alert even if I attach a 1Kb file

jrockowitz’s picture

Do the files upload? Are you using a custom theme? Can you replicate the issue using https://simplytest.me?

luigisa’s picture

Hello,

I can't try simpletest because I can't activate private files.

Yes I am using a custom theme but the file is attached to drupal and the submission

I attach my yml form

jrockowitz’s picture

I am not able to replicate the issue using the example webform from #9 with the Bartik theme.

Are you able to replicate the problem using the Bartik theme?

luigisa’s picture

With the Bartick theme, it works perfectly for me.

I've already found my problem.

I have removed these lines from my theme.info.yml and it works correctly;

file/drupal.file: false
webform/webform.element.managed_file: false

Thank you very much for your help

PS: comment #1 I don't know if it will have the same problem

jrockowitz’s picture

No problem. I am sure other people might run into the same issue via their custom theme.

jrockowitz’s picture

Status: Active » Postponed (maintainer needs more info)

I am not able to replicate this issue via the Bartik theme using the example I uploaded from #5.

What are the steps required to replicate the problem using the example from #5?

DanielVeza’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Hmm. I can't replicate this on Bartik. It must be a site specific problem. Sorry for the wasted time, I was fairly confident it wasn't an issue with the site!

jorges’s picture

I've just had the same problem and it turned out to be caused by messed up HTML above (forgotten closing tags). So you might check this first.

GuitarKat’s picture

I'm specifically having this issue. I'm running a custom theme.

I would suspect maybe there could be a conflict with another library. I haven't dug into it, but I feel it's above my skill level. I'm using paragraphs, I don't know if anyone else is? On a clean theme, there's a libraries not activated to test off on.

I have used the solution in comment #3 for now @luigisa. I'm going to try #4 later if time permits.

I'm using paragraphs, and I'm wondering if there could be a conflict with that or a different module?

It could also be my code as well, as @jorges also pointed out.

I'm writing this as a record in case someone else has the same issue. :)

asilva3’s picture

I am also getting this "File is still uploading" when uploading multiple files. I found the handler that causes this issue:

modules\contrib\webform\js\webform.element.managed_file.js
line 102:

  /**
   * Block form submit.
   *
   * @param {jQuery} form
   *   A form.
   *
   * @return {boolean}
   *   TRUE if form submit should be blocked.
   */
  function blockSubmit(form) {
    if ($(form).data('webform-auto-file-uploads') < 0) {
      return false;
    }

    var message = Drupal.t('File upload in progress. Uploaded file may be lost.') +
      '\n' +
      Drupal.t('Do you want to continue?');
    var result = !window.confirm(message);

    // If submit once behavior is available, make sure to clear it if the form
    // can be submitted.
    if (result && Drupal.behaviors.webformSubmitOnce) {
      setTimeout(function () {Drupal.behaviors.webformSubmitOnce.clear();});
    }

    return result;
  }

I just comment this out where it is called at (line 22 & line 55) because it is always called if the field has multiple files.

qpro’s picture

I had this issue too but finally find the problem:

TLTR:

Solved adding "client_max_body_size 10M;" in "/etc/nginx/nginx.conf" to increase size limit.

https://www.cyberciti.biz/faq/linux-unix-bsd-nginx-413-request-entity-too-large/

Long versión:

The issue was that when accessing the webform from a mobile device, I could upload a photo from the gallery, but I couldn't upload a photo directly taken with the camera (message "File upload inprogress. Uploaded file may be lost.")

Checking the size of a very similar photo in the Android gallery (photos taken directly with the camera don't get saved in the gallery when there's an error), it occupied 1.5 MB, which is below the 2 MB limit of the website.

Using Chrome's development tools with USB debugging on the mobile device enabled, I encountered the error "413 Payload Too Large." , and in the NGINX logs, there was "client intended to send too large body: 2984188 bytes," which was indeed above the PHP limit.

It seems that the image is optimized when saved on the mobile device but not when sent directly. So, I increased the limit to 10 MB, but the error still persisted.

This article provided me with the hint to make changes in NGINX and also include a larger margin for BASE64 encoding.

https://drupal.stackexchange.com/questions/80809/413-file-entity-too-large-ugly-error