Comment 12 for bug 1415023

1. Okay, so to reword in reference to the pressed control: If you press on a control where dragging does nothing, it should not take focus unless you also release over it. Dragging does nothing for buttons, checkboxes, and switches, so they shouldn't take focus until release. Dragging does something for combo boxes and text fields, so they should take focus on press. This is one of probably many subtleties we will discover where traditional PC behavior needs tweaking to accommodate touchscreens and/or the OSK.

2. I explained why I don't want the dialog recentered when the OSK disappears: because repeated recentering would be unpleasant. Ideally, a dialog would stay out of the way of the OSK if it was *ever* going to contain a text field, but I realize "will this dialog ever contain a text field" is equivalent to the Halting Problem. The next best solution is for a dialog to move by itself a maximum of once in its lifetime. (If "Dialog pushed out of the screen" is not hyperbole, it is a bug that would be fixed by implementing the Dialog section of the toolkit spec.)