[osk] Keyboard does not auto-hide when no longer needed

[dobey]

When I have entered the requisite data in a form or text field in an application, and then scroll and click on some other UI element which does not require text entry, the keyboard does not automatically go away. Instead, I must swipe down to close the keyboard, which is very annoying, especially when the keyboard is on top of Flickable elements.

Having the keyboard auto-hide when it is no longer needed would be a great improvement to the user experience, as would possibly an explicit close button visible on the keyboard itself.

----------------------------------------------------------------

Desired solution:

Auto-hide behaviour should be handled by the application as different use cases would require different auto-hide behaviour.

[Launchpad Janitor (janitor)]

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

[Bill Filler (bfiller)]

@zsombi
Is it possible to have a mouse area on the main view that when clicked will request focus and cause focus to be removed on the input field and thus hiding keyboard, or explicitly call QtInputMethod.hide()? This way clicking in any blank area will have the desired behavior. Additionally we should consider doing the same thing in the header - i.e. clicking in the header would dismiss the osk.

[Olga Kemmet (olga-kemmet)]

@Bill & Zsombi
There is one exception: if you click in the header on the search icon, the OSK should remain because of the search field.

[Zsombor Egri (zsombi)]

@bill: MouseAreas are the worst things to use: they capture mouse events and you won't be able to do anything else. Of course, if capturing a press is enough, then it would be OK. However, as Olga said, tapping on a text input would also be an issue, as you would have flickering.

Beside, are we sure that hiding OSK by tapping on an empty area is the desired UX? I'd say tapping on a different component i.e. button, checkbox, etc. should take OSK away, but not tapping on empty area...

[dobey (dobey)]

On Tue, 2014-06-24 at 13:36 +0000, Zsombor Egri wrote:
> Beside, are we sure that hiding OSK by tapping on an empty area is the
> desired UX? I'd say tapping on a different component i.e. button,
> checkbox, etc. should take OSK away, but not tapping on empty area...

If we think implicit closure by tapping on static areas is not
appropriate, then we definitely need an explicit close button on the
keyboard itself, I think.

[Zsombor Egri (zsombi)]

@Rodney: if you take iOS Messaging app for instance, tapping on static areas does not close the OSK. in Calendar, when creating an event, tapping on static area doesn't close the OSK. OTOH, scrolling the screen does close OSK, which ultimately also means taking the focus away from the input. And that is also linked to control (component) focusing.

So I would stay with the idea that tapping on components (non-static areas) should focus the components, which would automatically hide OSK.

[dobey (dobey)]

On Tue, 2014-06-24 at 15:43 +0000, Zsombor Egri wrote:
> @Rodney: if you take iOS Messaging app for instance, tapping on static
> areas does not close the OSK. in Calendar, when creating an event,
> tapping on static area doesn't close the OSK. OTOH, scrolling the screen
> does close OSK, which ultimately also means taking the focus away from
> the input. And that is also linked to control (component) focusing.

Are we talking about iOS or Ubuntu? I don't have any iOS devices in
front of me, and I've never really used any, so I can't see what iOS
does in various apps with the keyboard. Android has an explicit close
button on the keyboard.

Why should we do exactly what iOS or Android do here? Why can't we be
better than both of them? An explicit close button would be much better
than what we have now in most places, as it can be annoyingly difficult
to close the keyboard at times. Trying to close the keyboard when search
is focused in a scope for example, I shouldn't have to open an app to
result in the keyboard being closed. It also makes scrolling extra
annoying, as the keyboard is on top of the app, and doesn't cause the
app window to be resized to fit the keyboard underneath it in a tiled
fashion. This means that some things (which may need to be viewed in
some cases), can be very difficult to see, when one also needs to use
the keyboard at the same time.

There are several significant usability issues with the current
behavior, and with the iOS keyboard (which is why there are thousands of
threads on the Internet of people asking how to add a close button to
it). It would be nice if we could avoid these pitfalls in Ubuntu.

[Zsombor Egri (zsombi)]

On Tue, Jun 24, 2014 at 8:14 PM, Rodney Dawes <email address hidden>
wrote:

> On Tue, 2014-06-24 at 15:43 +0000, Zsombor Egri wrote:
> > @Rodney: if you take iOS Messaging app for instance, tapping on static
> > areas does not close the OSK. in Calendar, when creating an event,
> > tapping on static area doesn't close the OSK. OTOH, scrolling the screen
> > does close OSK, which ultimately also means taking the focus away from
> > the input. And that is also linked to control (component) focusing.
>
> Are we talking about iOS or Ubuntu? I don't have any iOS devices in
> front of me, and I've never really used any, so I can't see what iOS
> does in various apps with the keyboard. Android has an explicit close
> button on the keyboard.
>

iOS doesn't have one on phone layout, but on tablets they have. But you can
still hide the OSK on phone by swiping/dragging it down.

>
> Why should we do exactly what iOS or Android do here? Why can't we be
> better than both of them? An explicit close button would be much better
> than what we have now in most places, as it can be annoyingly difficult
> to close the keyboard at times. Trying to close the keyboard when search
> is focused in a scope for example, I shouldn't have to open an app to
> result in the keyboard being closed. It also makes scrolling extra
> annoying, as the keyboard is on top of the app, and doesn't cause the
> app window to be resized to fit the keyboard underneath it in a tiled
> fashion. This means that some things (which may need to be viewed in
> some cases), can be very difficult to see, when one also needs to use
> the keyboard at the same time.
>

Noone sais we should do exactly the same way. The reason I took iOS as
example is that they have a proven UX that works and people got used to it.
So Android. Usually, when a new UI framework, UX pattern is created, you
take ideas from other UI frameworks, taste their UX, and then build own
one. I'm not saying that they (iOS or Android) do always the best way, what
I'm trying to say is that they have certain UX patterns which are kind of
obvious for end users, or at least became obvious for some end-users. Yes,
I know, there are exceptions, and people don't always like everything these
frameworks provide, and we should address those people. Things like tapping
on a static area to close OSK is not something people would expect to have.
And you are right, opening an app is definitely not the way to dismiss OSK.
However resizing app window when OSK is opened may not be the best to do,
but the active input should definitely be pushed above the OSK. That is
already doable with the toolkit.

>
> There are several significant usability issues with the current
> behavior, and with the iOS keyboard (which is why there are thousands of
> threads on the Internet of people asking how to add a close button to
> it). It would be nice if we could avoid these pitfalls in Ubuntu.
>

Yeps, I second to that.

[dobey (dobey)]

On Tue, 2014-06-24 at 18:27 +0000, Zsombor Egri wrote:
> I know, there are exceptions, and people don't always like everything these
> frameworks provide, and we should address those people. Things like tapping
> on a static area to close OSK is not something people would expect to have.

Maybe it's because I'm a developer, and I'm used to more than 25 years
of using computers that have pop-up UI elements like menus, and similar,
which the OSK design and implementation certainly falls into the family
of, and I expect that tapping outside of the pop-up widget's area, and
not into another widget which would result in the same pop-up in the
same position, to close that pop-up. If I tapped on another text entry,
I'd expect the keyboard to stay. If I tapped on background text or empty
space, I'd expect it to close.

I'd also expect to be able to select and copy that text that isn't an
interactive widget, in some way, so that I can paste it into a text
entry elsewhere, if necessary.

I think the best way to solve all these issues, is to have an explicit
close button, as well as having a tap anywhere outside the keyboard area
result in its closure.

[Zsombor Egri (zsombi)]

The behavior the toolkit will provide is thst whenever an active component is tapped/clicked, the OSK will be taken away. This will also apply on PickerPanel, when PickerPanel opens, the OSK will be hidden.

An active component is considered to be one that handles mouse/touch events, or at least implements deriving or using AbstractButton.

OSK will not be hidden by the toolkit when an inactive area is tapped/clicked. Such situations must be handled by the applications themselves if needed.

[Zsombor Egri (zsombi)]

----------------------------------------------------------------

Desired solution:

Keyboard hides automatically when tapping outside form elements.

Daniela, if this is needed, it cannot be made in the toolkit reliably. Th toolkit can hide components while their focus is grabbed, but if the tap occurs on a non-active area, nothing is gonna take the focus away from it. If this is need, applications must take care to take focus away from any previous focus component.

[Olga Kemmet (olga-kemmet)]

I tend to agree with Zsomber, osk behaviour has to be determined by the apps because there are a lot of use-cases to cover and it would be hard to unify a behaviour in the toolkit. The above described behaviour might work for list views but not necessarily for messaging or notes apps.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:ubuntu-ui-toolkit/staging at revision 1211, scheduled for release in ubuntu-ui-toolkit, milestone Unknown

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-ui-toolkit - 1.1.1214+14.10.20140826-0ubuntu1

---------------
ubuntu-ui-toolkit (1.1.1214+14.10.20140826-0ubuntu1) utopic; urgency=medium

  [ Tim Peeters ]
  * Push modules/Ubuntu/Components/qmldir in push_to_phone.sh.
  * Add PageStack tests that use the new header.
  * Add tabs unit tests using the new header.

  [ Leo Arias ]
  * On autopilot helpers, take into account that text areas can have
    multiple lines when deleting the text. Fixes LP: #1359167
  * Fixed the four failing autopilot open page tests.
  * Added an autopilot custom proxy for QQuickGridView.
    Fixes LP: #1351670
  * Fixed the autopilot helper to search elements on lists, that
    failed when the element searched is on the first page of the list.
    Fixes LP: #1342521
  * On the autopilot scrollbar tests, we should not assume that the
    window is on the top left.

  [ Benjamin Zeller ]
  * Add a more stable regression test for bug LP: #1338602

  [ Zsombor Egri ]
  * Introducing Ubuntu Components FocusScope which extends QtQuick
    FocusScope with the ability to focus by mouse clicks.
  * Slider blocks Flickable while sliding. Fixes LP: #1353966
  * Save alarms data into JSON format. Affects test environments
    using fallback memory manager. Does not affect EDS backend
    functionality. Prerequisite for further alarm changes.
  * Focus handling on components. Fixes LP: #1234982
  * Fixing alarm disabling issue. Change organiser item fields
    only if those were marked as changed. Fixes LP: #1360101
  * AlamrModel is no longer reset when individual alarm is changed.
    This avoids UI flickering in Clock app. Fixes LP: #1359112

  [ Florian Boucault ]
  * Publish palettes of the themes.
  * Removed workaround that forced relayout when layout mirroring was
    enabled since bug was fixed in Qt. Fixes LP: #1353863
  * Visual feedback upon press for Header.
  * Better visual feedback upon press for List Items.
    Fixes LP: #1354036
  * Three startup optimisations that lead to saving 160ms
      MainView: load background asynchronously and do not cache it.
      MainView: delay popover menus creation until when necessary.
      Page: removed useless instantiation of ToolbarItems.

  [ Christian Dywan ]
  * Set organizationDomain which Qt.labs.settings uses.
    Fixes LP: #1241424 and LP: #1354321
  * Allow context menu buttons to grow wider for non-English locales
    to fit.

  [ Zoltán Balogh ]
  * Add a script to execute the test plan on a device.
  * Fix the desktop file for the UITK Gallery
    Fixes LP: #1357205 and LP: #1176918

  [ Martin Pitt ]
  * The autopilot-qt was split into Qt4 and Qt5 packages2. The
    libautopilot-qt used to pull qt4 packages. Avoid pulling qt4
    packages by depending on the Qt5 specific packages only.

  [ Nicholas Skaggs ]
  * Fix the warning for the emulators module. The warning will now
    only appear if you use the module directly. Fixes LP: #134169

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Tue, 26 Aug 2014 16:59:18 +0000