Input doesn't allow text select when focus is activated through touch - by JunlinZ

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


ID 862999 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 4/28/2014 11:42:14 AM
Access Restriction Public

Description

This bug is filed based on:  https://github.com/IEuserAgents/UAIssueTracker/issues/67

The economist is having some serious issue with their webapp in Windows 8.1, but this is an issue in IE11 (on win8) as well. They have two text inputs (username and password) on the page. You can click on them with a mouse and type into the input, but if you touch the inputs, it receives focus (confirmed with css), but the input doesn't take text input from the keyboard, or allow you to select text. You actually have to touch the page outside the text input, then touch the text input again to be able to add text.
Sign in to post a comment.
Posted by Microsoft on 5/6/2014 at 8:06 AM
Thank you for following up. Based on your message it seems the issue has been resolved. At this time we will close out this feedback item.

Your feedback is very important to us, and it helps us improve the quality of Internet Explorer. We continue to welcome more feedback, so please don't hesitate to report other ways that we can improve Internet Explorer.

Best regards,
The Internet Explorer Team
Posted by George Crawford on 5/3/2014 at 6:09 AM
After lots more investigation, we have narrowed this down to a bug in FTScroller (https://github.com/ftlabs/ftscroller/commit/14f5ac00a63e0f9d0dc9d5c3b13b97193215c10f) which hadn't accounted for un-prefixed transform and pointer events in IE11. Updating the library caused the text input field to gain focus as expected.

Apologies for any wasted time from MS. Thanks for your help!
Posted by George Crawford on 5/1/2014 at 10:20 AM
I've just found another bug report, which could possibly be related: http://connect.microsoft.com/IE/feedback/details/812296/
Posted by George Crawford on 5/1/2014 at 9:34 AM
I've done some research into the events triggered when tapping on the input field. I can't see an obvious cause for the problem, but thought I'd post here in case it was useful.

The following events are fired upon tapping into the username field (which invokes the virtual keyboard) and typing a single letter. NB: I've removed the pointermove and mousemove events from this list, as there's lots of noise.

Buggy - text input is not entered into the field:
pointerover, mouseover, pointerenter, mouseenter, pointerdown, mousedown, beforeactivate, activate, focusin, pointerout, mouseout, pointerleave, mouseleave, focus, input, click, pointerover, mouseover, pointerenter, mouseenter, pointerout, mouseout, pointerleave, mouseleave, keydown, keypress, keyup

OK - text is entered into the field:
pointerover, mouseover, pointerenter, mouseenter, pointerdown, mousedown, beforeactivate, activate, focusin, pointerout, mouseout, pointerleave, mouseleave, focus, input, click, pointerover, mouseover, pointerenter, mouseenter, pointerout, mouseout, pointerleave, mouseleave, keydown, keypress, input, keyup

You'll see the only difference between these logs is the final 'input' event, which is the point at which the text is displayed in the field. For this reason, I'm struggling to find a way to work around the bug.
Posted by boyofgreen on 5/1/2014 at 8:54 AM
Also note, the same code works in IE10, so this seems to be tied to an IE11 change.
Posted by boyofgreen on 5/1/2014 at 7:46 AM
I can confirm this happens on real touch devices as well. I've tried 3 different touch devices that run ie11.
Posted by George Crawford on 5/1/2014 at 4:48 AM
Hi - I'm the originator of this bug report (developer on The Economist's HTML5 app). I'll add some more details from our observations.

We've noticed that input from the touch keyboard is often ignored, with no text caret shown. Tapping out of a text field or textarea to deselect it, then tapping back in, sometimes brings the caret back and allows input, but sometimes not. The hit-rate seems to be about 1 in 4. It seems to affect all text fields indiscriminately.

At the recommendation of Jeff Burtoft (MS devrel) I’ve tried applying "touch-action: none; -ms-touch-action:none” to all elements, and after confirming that the styles are definitely applied to <input> elements, I can report that it doesn’t fix the bug.

Some more observations:

- the ‘X’ close icon in the text field also doesn’t respond to touch input
- if I do manage to type some text in the field, and then blur it, tapping back in the field often places the caret at an unexpected position - e.g. in the middle of a text block, even though I tapped at the end of the block.

I've put a video of the VS simulator here - http://dev.labs.ft.com/george/EconWin8.1touchkeyboard.mp4 - but we've also recreated it with a real touch device.
Posted by Microsoft on 4/28/2014 at 12:42 PM
Thank you for your feedback. We will be investigating this issue further.

Best regards,

The Internet Explorer Team