page_load_progress doesn't respect form validation

Thanks, confirmed. For site admins, it's possible to kill the throbber by pressing the ESC key, but end users wouldn't know and would simply be stuck.

As a workaround, you can decide to exclude page_load_progress from being triggered on the page causing the issue. You can do so from within the visibility conditions section under /admin/config/user-interface/page-load-progress - E.g. by adding /contact/contact_us if that was the relative path to your custom contact form. Do not forget the prefixing slash.

Have you determined -- or do you have an opinion -- as to whether (or not) you will fix this validation issue?

Haven't yet, as I need to dive into the JS validation issue first. Definitely something I'm willing to fix one way or another. Stay tuned.

So, we sat down with Dom. to discuss the issue and here's what's happening:

• The form validation is coming from the browser via HTML5
• If we were to change the JS to check the parent form, this would need adding an external library (most likely jQuery Validation). Not really an option, is it?
• One good option we have is to check on form submit only and thus not give the flexibility to have page_load_progress be triggered on any arbitrary CSS class or ID
• On the plus side, this would make things much simpler. We have yet to see a valid use case making use of anything different than .form-submit for page_load_progress

Here's a sample implementation:

// Add the screen lock behavior for each configured element.
for (var i in exit_elements) {
  var form = $(exit_elements[i]).parents('form');
  form.submit(function () {
    setTimeout(lockScreen, delay);
  });
}

So, we think the best path forward is likely to restrict the module to .form-submit only. The reason is it's very low-level and if you want to override it you really, really have to put efforts into not using it. Also, allowing any CSS class or ID might be us over-engineering the real-life use cases people actually have. We'd rather keep things simple for 99% of our user base and explore edge cases on a case-by-case basis.

So we'll proceed with this plan. This will quite significantly reduce the module complexity.

Linked to #2883036: Explore supporting only .form-submit or add a new class for exploring options.

The patch in #2883036: Explore supporting only .form-submit or add a new class should fix the issue since we've now changed the JS behavior to account for HTML 5 validation. Please follow the other issue. It'll soon be committed to dev and I'll tag a new release next.

And it's in the new release https://www.drupal.org/project/page_load_progress/releases/8.x-1.2