Last modified: 2014-10-14 17:38:08 UTC
Intention: Delete a template. Steps to Reproduce: 1. Open an article containing a template. 2. Select the template. 3. Try to press the delete key on the now-non-existent keyboard. Actual Results: The keyboard closes, so you can't delete them. Reproducible: Didn't try
Did you mean the cursor instead of the keyboard? Surely VisualEditor didn't make your physical keyboard dissolve into a pool of molten plastic?
No, I mean the keyboard. It's an iPad without an attached physical keyboard. The keyboard is displayed on the screen, like the one shown in the picture at https://commons.wikimedia.org/wiki/File:Apple_iPad_Event03.jpg (Presumably the same problem happens on any mobile device.)
Aaaah, OK. Updating summary to reflect that.
Can this be rechecked?
Yes, for all block items such as image, reference note, template ,math function: selecting it hides the keyboard.
I've noticed a few bugs coming through related to certain operations hiding the keyboard and then that killing focus and causing selections and menus to disappear. Is there a general problem where losing keyboard focus causes VE to lose state?
(In reply to Brion Vibber from comment #6) > I've noticed a few bugs coming through related to certain operations hiding > the keyboard and then that killing focus and causing selections and menus to > disappear. Is there a general problem where losing keyboard focus causes VE > to lose state? Quite possibly; escalating.
*** Bug 67257 has been marked as a duplicate of this bug. ***
This seems to be because we programmatically move focus from the surface to the pasteTarget, and iOS Safari is very picky about when it allows a programmatic focus move to open the keyboard. Something like, it only works if you do it in direct response to a mouse/touch event. I tried a few solutions I found on the internet but I haven't gotten any of them to work yet.
Change 163662 had a related patch set uploaded by Jforrester: Add a "Remove" context button to all Focussable nodes https://gerrit.wikimedia.org/r/163662
Of course this behaves completely differently in iOS 8 (the keyboard stays up). *sigh*
(In reply to Ed Sanders from comment #11) > Of course this behaves completely differently in iOS 8 (the keyboard stays > up). *sigh* Re-prioritising.