Try to select a form input element that would be outside the dialog area when the dialog resizes to accommodate the virtual keyboard.
Observe: the keyboard is not open but the dialog resizes as if it were, and the selected form element is no longer focused or in view.
The main part of this problem happens because activationTracker works on pointerdown, so the dialog resizes etc. before the click can complete, and thus before the <input> actually gets focus.
However, simply changing activationTracker to work on the click event rather than pointerdown will cause problems for widgets like Checkbox or Slider that extend FormValueWidget. FormValueWidget has code to only report change and input events for when the user changes the value, not when the value is changed programatically. Currently, it achieves that by saving the widget's "initial" value when the widget is activated (either by focus or pointerdown). The "initial" value must be saved before the value is changed, in some cases before the click event finishes, or perhaps when there isn't a click event at all.
Steps to reproduce:
Observe: the keyboard is not open but the dialog resizes as if it were, and the selected form element is no longer focused or in view.
The main part of this problem happens because activationTracker works on
pointerdown, so the dialog resizes etc. before the click can complete, and thus before the<input>actually gets focus.However, simply changing activationTracker to work on the
clickevent rather thanpointerdownwill cause problems for widgets like Checkbox or Slider that extend FormValueWidget. FormValueWidget has code to only reportchangeandinputevents for when the user changes the value, not when the value is changed programatically. Currently, it achieves that by saving the widget's "initial" value when the widget is activated (either by focus or pointerdown). The "initial" value must be saved before the value is changed, in some cases before theclickevent finishes, or perhaps when there isn't aclickevent at all.