[Dialog] if keyboard is present, buttons and derivatives have to be pressed twice

[Dave Morley]

STEPS:
Setup:
1 phone + one locked sim

1. Open system settings
2. Goto Security
3. Goto Sim Pin
4. Tap on unlock
5. Type in the pin
6. Tap the green confirm button

EXPECTED:
I expect the dialog to be dismissed and the keyboard and sim be unlocked

ACTUAL:
The keyboard is dismissed but the dialog box remains.

A recent change has effected this.

[Jonas G. Drange (jonas-drange)]

I am able to reproduce this outside Ubuntu System Settings with the following code [1].

[1] http://pastebin.ubuntu.com/9899906/

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Pat McGowan (pat-mcgowan)]

Depending on the fix may backport to rtm

[Zsombor Egri (zsombi)]

In the sample posted by Jonas I do not see any command to dismiss the dialog when the button is pressed. A call to PopupUtils.close(dialogue) - (or depending on the code a dialogue.hide()) should be there, otherwise the Dialog won't know when to close.

[Zsombor Egri (zsombi)]

If you had this in the system settings, then it's bad, and I am wondering how this worked so far. If it ever did work properly. See https://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.Components.Popups.Dialog/

[Pat McGowan (pat-mcgowan)]

zsombi is correct, the cancel button has a call to close but the change button does not

[Jonas G. Drange (jonas-drange)]

The issue is not that the Dialogue does not close, it's that you have to press a button twice to if the OSK is shown. It seems like the first press on a button never 'reaches' the button and that the press event is suppressed by the action that hides the OSK.

This is a more detailed way of reproducing:
1. Run [1]
2. Press the text field to spawn the OSK
3. Press any button once (they all close the dialog)

What happens:
The dialog does not close, the button is not clicked

What should have happened:
The dialog should close

[1] http://pastebin.ubuntu.com/10773120/

[Zsombor Egri (zsombi)]

It seems the button is getting the pressed signal, which removes the OSK. That one triggers the dialog to be grabbed to the centre of the screen, and therefore the release event happens outside the button.

[Jonas G. Drange (jonas-drange)]

16:37 < Elleo> jgdx, zsombi: okay, what seems to happen is that the button is *pressed* but it's not *clicked*, which I suspect happens because the button moves (due to the keyboard being dismissed), so the touch release event
               is no longer happening on the button's mousearea
16:38 < zsombi> [DARN]!
16:38 < Elleo> jgdx, zsombi: if you add a little debugging to AbstractButton.qml to print something onPressed you can see this happening (whereas onClicked doesn't fire)
16:38 < zsombi> Elleo: nice finding, dude!!!
16:38 < Elleo> zsombi: thanks :)
16:38 < zsombi> and that's bad
16:40 < zsombi> Elleo: I don't think we can really do much about that...
16:41 < Elleo> zsombi: yeah, my only idea would be to have "activeFocusOnPress: false" and take focus manually as part of the onClicked and onPressAndHold handlers, but that wouldn't be backward compatible for apps deliberately
               disabling activeFocusOnPress themselves (there'd have to be some other property to let them do that)

[Matthew Paul Thomas (mpt)]

I was directed to this bug report by Jonas in <https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/allow-insecure-hotspot/+merge/269671>, where "activeFocusOnPress: false" is added to a checkbox because it happens to be in the same dialog as a text field. If approved, that will be the 11th place in ubuntu-system-settings where this bug is being worked around, and probably there are more in indicators.

I think there are two bugs here. Fixing either of them would resolve the reported symptom, but really, both should be fixed.

1. A text field should not lose focus every time you press elsewhere. It should lose focus when you press *and* release on a control that can take focus, or when you press on a control where dragging is meaningful. Try this in the browser you're using right now: focus the address field, press on a built-in toolbar button -- for example, the Downloads button in Firefox, or the Home button in Chromium/Chrome -- and drag out of it to cancel before releasing. The text field doesn't lose focus. But if you do the same with another text field -- such as the search field in Firefox -- or with a bookmark, which is draggable, the address field does lose focus immediately. A button is not in the category of controls where dragging is meaningful, therefore -- whether or not it takes focus itself -- it should not cause the field to lose focus. (Eventually we should have this spelled out in the toolkit spec.)

2. Dismissing the OSK should not cause a dialog to be recentered on the screen. You might focus another field in the dialog a second or two later, and repeated recentering would be unpleasant.

[Zsombor Egri (zsombi)]

1. The text field looses focus due to the fact that someone else is getting focused. The same behaviour happens on every control, not only on TextField. Now, the question is whether do we want to do slightly different focusing behaviour on different controls, i.e. on desktop when focusing a Button, a CheckBox, a Switch, a ComboBox or other, those gain the focus when pressed, no matter if the previous focus control was a text input. You can see this in System Settings GTK app, by pressing either of the controls, move the mouse and release outside of the control. You will see the focus outline on each. However, we could treat text inputs separately, so if the current focus is a text input, the input would lose focus only when a click happens, except if the next focusable item is also a text input.

2. OSK is hidden only if the next focused control is not a text input. When OSK hides, Dialog is re-centered, as OSK appearance is causing Dialog content to be shifted out. I don't get why you want to keep Dialog pushed out of the screen when OSK gets hidden...

I do not see two bugs here, only one, which is the text input losing focus slightly differently than the others. Dialog should be placed back to the original position when OSK disappears.

[Matthew Paul Thomas (mpt)]

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.)

[Zsombor Egri (zsombi)]

1. Much better :)

2. Unsure whether the Ubuntu Touch System Settings -> Wi-Fi ->Connect to hidden network Dialog's two text inputs are handling the OSK differently, but atm focusing the other text input while the first one is focus doesn't pull out the OSK and then back. If they did a workaround, then we need to fix this. However AFAIK this is solved by the focusing mechanism itself upstream. Then to keep the dialog away once it had been pushed out by OSK is a bad UX. Dialogs on a phone layout should have as less content as possible especially due to the OSK behaviour. The entire surface is pushed out, and if it'd stay there, there would be some content which is not accessible anymore after being pushed out. Resizing is also a bad UX, a shrunken dialog would look clumsy.

[Matthew Paul Thomas (mpt)]

1. I've put an equivalent statement into the toolkit spec, subject to approval from Femma.

2. "Some content which is not accessible" should never be the case, whether the OSK is visible or not. That would be awful! As I mentioned, that could be fixed by implementing the Dialog section of the toolkit spec -- particularly the part where the body area scrolls if necessary. (Of course scrolling is bad, but it's better than the alternative.)

[Cris Dywan (kalikiana)]

Just to update on #2, dialogs do scroll. There used to be a bug where the margin used for it was incorrect and as of recently all dialogs are again fully scrollable relative to the OSK limiting available space.