[AdaptivePageLayout] can't easily grab scrollbar if dual column

[Bill Filler]

If you have an app that uses AdaptivePageLayout and supports 2 columns, if there is a scrollbar in the first column, it's very difficult to grab it with your mouse because when you get close to it, you get the horizontal arrows showing to allow resizing of the panels in the multi-column layout.

You can try this with messaging-app in silo 30 (soon to land)

[Andrea Bernabei (faenil)]

This was discussed already this week, the UX team will provide a solution to the conflict.

The column resizing area was large to allow easy resizing using touch, but since we now could have draggable scrollbars there (on touch as well), the situation has become delicate.

Adding ubuntu-ux

[Matthew Paul Thomas (mpt)]

    (A) A scrollbar is immediately adjacent to a column splitter
is a special case of
    (B) a scrollbar’s touch area overlaps with the touch area for anything else
which is a special case of
    (C) the touch areas for any two things overlap.

In the long run we will need a solution for (C). But for now, here’s my proposal for (B). <https://goo.gl/kKcynn> Unfortunately that document is Canonical-only and what I’ve written is not yet approved. So for now, here’s what I’ve written:
____________

As an exception to any standard control touch area clash behavior, if any part of a scrollbar thumb’s touch area clashes with the touch area of one or more other controls, then:
 * If you press on that area, neither/no element should receive the press event until one of the following happens.
 * If you release without a substantial drag, the press and release should be passed to the control(s) that aren’t the thumb.
 * If you begin dragging (nearly) vertically, it should be treated as dragging the thumb.
 * If you begin dragging in any other direction, the press event and any future events should be passed to the control(s) that aren’t the thumb.
____________

[Launchpad Janitor (janitor)]

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

[Zsombor Egri (zsombi)]

Sorry, UX, this doesn't solve the proper aiming on the AdaptivePageLayout column divider.

Implementing such a functionality is pretty complex and error prone. First, the order the overlapping components are receiving the touch events is not predefined, and not even predictable. A touch event is handled by the topmost instantiated component first, meaning if the divider is above the Scrollbar, that will get the event first, and will consume it. This means the Scrollbar below will not even see the event coming.

In order to implement the event handling above, we could think of the following solutions:
1) Create a touch event handler component which would be shared between the scrollbar and the divider. The component will then need to be explicitly shared between the APL and Scrollbar -> cannot be automated by the toolkit and would require to expose some (weird) APIs for both Scrollbar/Scrollview and APL, and app developers would need to bind these two components manually.
2) make sure the Scrollview is parented so that is always going to be above the APL divider, in this way it can get the touch events prior to the APL divider. Then Scrollbar should consume vertical touch drags only, and APL divider the horizontal ones, but neither of these should consume the touch press events. This may cause problems as the touch events will be forwarded to the flickable component under the scrollbar, and no further touch events will be handled.

I was thinking more on a touch grabber spot presence on the APL divider, and the touch events should be grabbed only when that spot is aimed.

BUT, we still have the mouse interaction, which had not been addressed by UX at all. So I'm moving back the UX share to In Progress, until we get a proper solution for both input use cases.

[Kugi Eusebio (kugi-igi)]

It seems that Dekko is not affected by this bug.

[Andrea Bernabei (faenil)]

because Dekko is not currently using AdaptivePageLayout

[Matthew Paul Thomas (mpt)]

I agree that this solution is “complex and error prone”. Any solution would balance those; I chose more complexity for fewer errors.

However, while I used the phrase “touch area” rather than “target area”, nothing in the solution I gave is inapplicable to a mouse. It should all work exactly the same with mouse input.