bug(web): HTMLElement.focus() lacks proper touch-oriented handling.

[jahorton]

KMW presently relies entirely upon the touchstart event for touch-based control focusing, which can present an issue to pages wishing to use the HTMLElement.focus() function to focus a given control programatically.

Discovered during work on the engine tester PR, #585.

[jahorton]

This gets a bit tricky because of various design decisions, some of which aren't ours. It's not too bad with current functionality, but becomes very tricky should we ever wish to extend what controls we can alias for mobile devices.

Cases:

• Base element is either <input> or <textarea>
  • When .disabled is set to true, the elements cannot receive focus events. (We currently set this on the base element.)
  • However, .readonly allows focus events; just not editing. Setting .tabIndex=-1 will prevent tabs from focusing the base .readonly control.
• Base element is .contentEditable
  • This element can only receive focus events when .contentEditable = true, so disabling it on the base element would be no help.
  • .contentEditable = true completely ignores any .disabled and .readonly settings on the element. It would require careful event management of the control to prevent edits to the 'base' rather than the 'alias.'

There is one alternative that allows elements to receive focus, according to online docs: https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onfocus. The problem - this opens the elements up to receiving focus via 'tab'.

[jahorton]

As of #7343, we've now laid touch-alias elements to rest. As a result... we no longer need to disable the 'base' elements, removing this issue entirely.