Answers

• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  January 2016

  Interestingly this appears to effect Firefox and IE but not Chrome.

  I will dig into this issue and post back shortly. Likewise it will require a change in Editor to detect such a case.

  Allan
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  January 2016

  Looking into this further, it would appear there there is no good way to handle this in non-Chrome browsers. Ideally a return while the list is closed would submit the form, while a return with the list open would just select an item, but there is no API in the DOM to determine if the list os shown or not (at least not that I can find). A mouse click could be detected, but that is unreliable for keyboard access and also closing the list.

  As such I think the only option is to display the return to submit on select elements altogether (Editor could detect Chrome, and I might yet make it do that, but I feel that it might be better to make it consistent across all browsers). That change will be int eh next release of Editor, which will be towards the end of this month, but if you'd like to make the change immediately, in the Editor source find:

  var returnFriendlyNode = name === 'input' || name === 'select';
  

  and simply change it to be:

  var returnFriendlyNode = name === 'input';
  

  Thanks for the explicit instructions on how to reproduce the issue.

  Regards,
  Allan
• DaveNavarro Posts: 18Questions: 7Answers: 0

  May 2016 edited May 2016

  Hello Allan,

  Did the changes for this issue get released? If so, in which build?

  I'm working on a similar event that's not behaving as I'd expect. So, if I have the correct build then I can rule that out.

  Please let me know and thanks!

  ~ Dave
• allan Posts: 61,972Questions: 1Answers: 10,160 Site admin

  May 2016

  Yes, 1.5.6 considers only input as a "return friendly node".

  Allan