Antibot blocks multistep webform submission if user fails to move mouse pointer

I noticed a comment typo in the first patch uploaded. Here's another one.

I also didn't explain all the changes I have made in this patch.

The original JS had event listeners to detect humans for mousemove, touchmove and keydown (with a further check that key pressed was tab or enter). The patch changes mousemove to pointermove and adds an additional listener for pointerdown so that if a user clicks submit without mouse movement, the mouse click is detected and antibot protection on the form is unlocked and submission proceeds.

Pointermove and pointerdown events cover both mouse and touch input events. So there is no need for a separate touchmove event listener and it is removed.

In relation to the keydown event, I have removed the check for tab or enter keys because it is possible for keyboard users to use space to activate a button. I then thought why not allow any key press to detect a human?

I have added an additional check for all event listeners to check the Event.isTrusted property is set to true. The browser sets this when an event is triggered by a user as opposed to being triggered programmatically by Javascript. In theory, I was thinking this would be a good extra check to prevent form submissions by more sophisticated bots using a headless browser (with Javascript enabled) to simulate mouse, touch or keyboard events. I have not tested this theory though ...

I found additional problems that block disabled users, stemming from the same cause.

1. Screen readers are not reliably detected. Screen reader users can navigate without using the Tab key, and several navigation methods throw no JS events at all. So only meta keys may be received, or it's possible NOTHING will be received before other than a click on the "next page" button.
2. Voice control (dictation) users are not detected at all. The first event their browser fires is "click" on the submit button.

I pulled your patch into an issue fork and added some more:

1. Simple click detection to permit users relying on assistive technologies to submit the form. It's the only event that some browsers are going to fire I'm afraid.
2. Config settings to make the error messages customizable, so that real human users who are blocked for any reason can be given a fallback contact method, such as email or phone.

Another way to address the accessibility issue may be to have some sort of "are you a human" field that a user can interact with, and disabling the submit button until the user has passed any tests.

Another way to address the accessibility issue may be to have some sort of "are you a human" field that a user can interact with

This is just captcha though, right? The idea is to avoid having to interact.

I'm adding the target tag to track this one, and I think if we can't resolve it we'll remove the module from Drupal CMS until a solution can be found. It seems like a edge case but it renders the form unusable so it's fairly serious.

Tagging this as a Drupal CMS dependency critical, because it is severe enough that we need to remove Antibot from our dependencies, for now (see 📌 Remove Antibot module because of unaddressed accessibility issues Active ) until this issue is fixed and in a tagged release of Antibot. :(

@glugmeister @itmaybejj Thanks for using Antibot and working on this issue. Are you still able to reproduce the issue with the latest 2.0.4 release? I created a multi-step web form, followed the steps mentioned in the issue and then used Apple voiceover to make submission and it was not blocked by Antibot. Possible to share any other inputs that might help others reproduce the issue? Thanks.

jan kellermann → made their first commit to this issue’s fork.

The solution of allowing clicks and querying the isTrusted attribute can significantly reduce the effectiveness of the module. We have therefore created a new merge request that adds an adjustable time component (default 5 seconds) to the click event.

Please review / feedback.

I tested the original bug regarding the mouse pointer and I got the same error:

I had some issues applying the patch # 3, but It seemed to fix the issue

$ patch -p1 < antibot-issue-3406484-2.patch 
patching file js/antibot.js
Hunk #2 succeeded at 19 (offset 2 lines).
Hunk #3 FAILED at 46.
1 out of 3 hunks FAILED -- saving rejects to file js/antibot.js.rej

I'll look into the accessbility issues now.

I'm using Linux here and the default screen reader that comes with it (Orca) is just a nightmare and I can't submit/navigate the form unless I use the tab and hit enter to submit the form, I believe JAWS has the option to navigate the webform without the tab, I'll ask one of my colleagues who uses Windows if he can do some tests with JAWS.

gaurav.kapoor → changed the visibility of the branch 3406484-antibot-blocks-multistep to hidden.

@danrod: Thank you for testing. The patch antibot-issue-3406484-2.patch you used is almot 13 months old. Please test with current issue fork.

I changed the test to fill in the form data via JS instead of using Mink because Mink simulates the keystroke events.

In general the scope of this issue moved. The webform-bug seems to be fixed without this issue.

Interesting is comment #5 🐛 Antibot blocks multistep webform submission if user fails to move mouse pointer Active where several new a11y problems are mentioned that call into question the functioning of the module in general for accessibility reasons.

The MR!23 tries to solve this problems and attempts to balance accessibility and spam protection.

For testing you can use the /user/password page without further config (only enable antibot) and I uploaded webform.webform.test_3406484.yml → which you may import and use for multi-page webform tests.

I agree the scope has changed somewhat.

I retested the issue after comment #17 and was not able to reproduce the issue with the latest 2.0.4 release using a keyboard only. I haven't been able to test with no keyboard, no mouse movements except a submit button click as my testing screen doesn't support that, I'll try on a larger screen asap.

I will also try to test the MR additions. Thank you

Hello @jan kellermann can you share with me how to use Mink to test this MR? I'm not familiar with Mink and I'ld like to help on this.

Behat/Mink is predefined in Drupals PHPunit-Config. For local testing you need a chromium. We are running this via docker, see here → .
See also this pipeline (line 68ff)
See also this commit.

Based on the discussion around the issue during the contribution event, the change can have a major impact on the accessibility, security, and overall working of the module so it will be better to have a separate release at the moment. This will help in gathering more feedback and based on that in the future we can either have one release or multiple releases maintained in parallel. Congratulation

Thank you @gaurav.kapoor , It is a shame that I wasn't able to work on this issue closely, I had some work commitments on the side, but I'll look into the other issues from time to time.

Will the 3.0.x branch have the release with the accessbility features/fixes?

@danrod, no worries, I can take up this one. Plan at the moment is to have fixes from this issue in 3.0.x and a release after some more testing. But we continue to maintain 2.0.x and have a release as well with some of the recent fixes. In future, we can let again switch to a single supported release and active development branch.