Hitting 'enter' on any input displays popup calendar

Thanks for the report. It looks like this problem happens in Firefox (didn't try other browsers yet) because hitting the "Enter" key should normally submit the form. By default, hitting enter to submit a form will click the first button element within the form. In the event that you've added a popup date component, the calendar will become the first button in the HTML.

So rather than removing $(this).focus(), I think we need to find a way to make the buttons act in the correct order (perhaps through tabindex, but that seems like it would cause other problems). Or as some have suggested in the past we could prevent the Enter key from submitting the form at all, but that behavior shouldn't be dependent on a Date component being present in the form.

The $(this).focus() means that the Date Popup field takes prominence over any other field that would want to prevent the field from autocompleting when hitting enter - not very egalitarian.

I just hit this problem while doing some heavy webform tweaking (6.x-3.17) to convert textfields into autocomplete fields. With a multiple value user autocomplete, you have to hit enter multiple times in the same field to pull up all the names - super annoying when Date Popup popups up each time just to fill out a single field.

It also looks like this won't be solved on the browser side any time soon. The HTML 4 spec was vague, and the HTML 5 spec says the browser can do pretty much anything it wants. It looks like "First Button" is going to be the rule for years to come. reference

I think for my implementation I'm going to remove $(this).focus() - though because I can't see a reason for it at all, it makes me suspect I'm missing something important. Why is it there in the first place?

EDIT: A bit more information. Many people suggest using input type="button" as opposed to plain input, as it won't be triggered... however the image is required, and input type="image" triggers a submission.

Is it possible instead of the input being of type image, that the input be of type hidden with an img to the right that simply triggeres the popup javascript? EDIT2: This totally breaks the datepicker. I'm going back to just removing focus. It doesn't appear to break anything an any way I can perceive.

Closing for lack of activity and development in this branch. Seems to work fine in 7.x-4.x, at lease in Chrome.

I've created a solution. Patch will follow.

The patch.

Does this problem exist in Webform 7.x-4.x?

Yes this problem exists on 4.16.

Thanks. Please re-roll your patch for 7.x-4.x.

Same patch, re-rolled for 7.x-4.x (with some small updates).

I'm not convinced by the current approach for this issue.

The current solution relies on modifying the structure of the calendar field. However if you were to have overridden the webform-calendar.tpl.php e.g. to set your own calendar logo, you've now introduced a worse bug. As when you now click on your calendar icon you submit the form.

So for a successful roll out of the #5 (and #11) patch every site which has overridden the tpl.php needs to update their templates, possibly including some additional styling since the component's HTML has changed.

Since the original bug is not more than a mild nuisance and the possibly introduced bug is breaking I think we should take a different approach.

The real problem is that the current calendar input gets the "click" event first (when you press enter on another input field), but shouldn't do anything if the original target was not the calendar input. Now we need some way to detect this scenario and in that scenario DON'T do the event.preventDefault().
I've inspected the event properties and discovered that the event's clientX and clientY property are only set to a non zero value if the original target was not the calendar field. So simply checking for a non zero value, we know the calendar is the target and do our thing. As a result we also don't need the focus() call anymore.

Now you can again submit forms when pressing enter in other fields. Tab through the form until the calendar pop up and do your thing, or click on the calendar and do it that way and everything just works.

The same patch but one that applies to 4.16 because I need it. Ignore it for everything else.

Internal testing revealed an issue in Safari (you couldn't click to open the date picker anymore).
Restoring the $(this).focus() solved that problem.

I've also added some comments to explain why this code was needed for future reference.

I've tested it with:

• Chromium 73 on Linux
• Firefox 65 on Linux
• IE 11 on Windows 10
• Safari 12 on Mac Mojave

Chrome and Firefox worked perfectly.

IE 11 has the minor issue that the date picker does still show up when pressing enter on a previous component. But the form is still submitted, so functionally that should not be a problem.

Safari needed special handling as the focus needed to be restored. And pressing enter on a previous component does not submit the form. However this is no different than how it works without this patch.

In conclusion, this patch improves the experience on 3 of the 4 tested browsers. It has no impact on the experience for 1 browser.

See attached patch, note that 1 is for the dev branch and 1 is specifically for 4.16.

I have tested the patch (with Browserstack) and the issue is indeed fixed for Chrome and Firefox.
Unfortunately the patch does not solve the problem for IE11 on Win10 and Safari12 but does not break anything either.

Therefore I change this patch to RBTC because there is an improvement for Chrome and Firefox.

Thanks!