Created attachment 258637 [details] Try to tap, scroll, or zoom in the pink square, and the keyboard will deploy when it shouldn't Currently, when a node is focused programmatically (either through element.focus() or the autofocus attribute) and we interact with a region that has touch event handlers (ontouchstart, etc.) the focused node will be refocused and assisted.
<rdar://problem/22204108>
Created attachment 258646 [details] Patch
Comment on attachment 258646 [details] Patch This approach is insufficient. More specifically, it will not handle the case where the developer calls preventDefault() on a touch event but we still want to show the keyboard.
Created attachment 258915 [details] Patch
Comment on attachment 258915 [details] Patch It would be nice to add some manual tests to this patch. It is not possible to have the automatic tests but at least having the manual ones would be helpful. Make sure you test the most popular frameworks that use touch handlers to make sure none of them relies on the wrong behavior we had before.
Got it. I'll try out Sencha touch and fastclick (the two libraries Ben mentioned yesterday) and make sure they still work. Simon also looked at this patch and advised me to leave out the manual tests, since they are ignored most of the time. However, I think it will be nice to still include them, since I'll be working on an automated framework for testing forms on iOS soon, and (at some point) I'll probably go through the manual tests directory and convert as many as I can to automated tests (including this one). It'll be helpful to have them all in one place. In any case, the test case still lives in the Radar, so we can always go back and consult it if necessary!
Committed r188405: <http://trac.webkit.org/changeset/188405>