joseph.olstad → credited Glugmeister → .
We have a multi-step webform with ajax enabled. In user testing, a user got the "Oops" error when their device temporarily lost internet connection. With the patch in #6, the user sees no error and has no clue something is wrong. The webform simply doesn't respond. Here is another patch which which shows two different error messages depending on the XMLHttpRequest status:
- Status 0 (request did not complete): "Oops, something went wrong. Check your internet connection and try again."
- All other status codes: "Oops, something went wrong. Contact the administrator."
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 ...
Glugmeister → created an issue.
Second attempt at a patch. In the first attempt, the additional rule for setting box-sizing: border-box did not have enough specificity.
I've had a go at creating a patch for this. Since I'm not sure how to fix postcss processing so that the box-sizing: border-box line following all: initial; is preserved, I've just moved it to a separate rule targeting all off-canvas html elements. I also removed a superflous text-shadow: none; that also followed the all: initial;. The post css processing converts all: initial; into a whole list of individual properties (for browsers that do not support the css 'all' property) and so text-shadow: none; gets set anyway in the generated css.
Glugmeister → created an issue.