Tapping button in toolbar closes toolbar

Reported by Sam Bull on 2013-07-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu UI Toolkit
Ubuntu UX
Vesa Rautiainen
ubuntu-keyboard (Ubuntu)
ubuntu-ui-toolkit (Ubuntu)

Bug Description

Frequently when tapping a button in the toolbar, it is interpreted as a swipe and closes the toolbar.

This could be solved by moving the swipe area a little higher, so you can only close the toolbar when swiping from just above the toolbar. This would make it consistent with the behaviour of the osk.

Desired solution:

Add a 0.5 gu vertical threshold value to toolbar dragging. If the value is passed toolbar dragging can start. If not, event is interpreted as a click (if the gesture was a click)
to toolbar buttons.

John Lea (johnlea) on 2013-08-05
Changed in ubuntu-ux:
assignee: nobody → Vesa Rautiainen (vesar)
Vesa Rautiainen (vesar) wrote :

I don't like the idea of moving the swipe area a little higher because moving it a little doesn't really solve the problem. Currently the swipe area covers the whole toolbar. So it should be moved all the way above the toolbar buttons which makes toolbar dismissal very awkward. You would need in that case be very precise where to grab the toolbar and in addition there is no visual cue where the grab area is. Of course one option is to increase toolbar size and add the grab area. But visually it's not very appealing.

The current solution is quite nice but obviously has its own issues now when it misinterprets some of the user's gestures. But there is room for improvement I think. A threshold value. Toolbar shouldn't start dragging until certain threshold value is passed. Clearly simple click of a button doesn't pass the value and the buttons would get their click event properly.

description: updated
Changed in ubuntu-ux:
status: New → Fix Committed
Sam Bull (dreamsorcerer) wrote :

Either way this should probably have some consistency with the OSK. So, the toolbar could only accept input just above itself like the keyboard, or the keyboard can go back to dragging anywhere on the keyboard.

The keyboard changed behaviour to solve the exact same problem, so it makes sense that both components should use the same solution (whichever solution that is), which also makes it easier for the user to know what to expect if all components behave similarly.

Bill Filler (bfiller) wrote :

for quite some time now you can only dismiss keyboard by starting drag above the top row of keys, not in the keyboard itself specifically for the reasons mentioned in this bug.

Changed in ubuntu-keyboard:
status: New → Fix Released
Changed in ubuntu-keyboard (Ubuntu):
status: New → Fix Released
Sam Bull (dreamsorcerer) wrote :

Right, so, surely the keyboard should either switch to the proposed design here, or the proposed design should switch to that of the keyboard.

Sam Bull (dreamsorcerer) on 2014-01-18
affects: touch-preview-images → ubuntu-ui-toolkit
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers