Sometimes input breaks and only edges are responsive

This is most probably about mouse (as opposed to touch) events getting lost, edges use touch events while all the rest uses mouse events, and those seem to get lost some times.

I saw that once or twice without wake/resume, so that doesn't seem to be important.

This seems to happen more with new scopes, still a case of "edges work, no other input does"...

Upon loading build 258 this same symptom manifested itself a couple of times.

First boot - swipe from apps to music to video. The UI is very sluggish and then it freezes half way through the transition to the video scope. The system turned the screen off, power button to bring it back went to the apps page, which was still hung. A few moments later it started to work again.

Second occurrence a moment later - opened the gallery, returned to the dash apps page, and UI hung.
Returning to the gallery with a right edge swipe and then back to the dash cleared the hand.

Looking at top there was nothing apparent during the UI hangs.

Subsequently I am unable to reproduce it. The device has around 20 mp3, 7 videos, and 50 photos.

I have been trying to find out exact steps for this bug for last hour but have not been able to find a pattern. Though I did indeed start seeing it with new-scopes very often.

This became less frequent, but still a big issue. Raising importance because we really need to get to the heart of this.

I need steps to reproduce it.
Never experienced this when playing with the device.

Yeah problem is there are no clear steps, this "just happens" from time to time. I have a feeling this is related to the device suspending, so don't keep it connected to usb.

If all else fails, we might need to resort to remote access to a device someone got locked up.

Has anyone ideas about reproducing this?

There is a way to reproduce specific to ubuntu-system-settings, the symptoms are similar but I am not sure the cause is the same.

Test Case:
1. Launch system settings
2. Tap on accounts
3. Tap on back
4. There is a black screen for 20s (bug 1292652). Wait until it goes away and u-s-s is displayed

-> At this point launcher, indicators and dash are working (edges are responsive) but u-s-s doesn't receive input event (cannot scroll the screen or tap an icon)

I'm afraid the above is different - bug #1355263

I wonder if this could be caused by a leftover MouseArea{} event eater, like the one used by notifications...

That is an interesting idea...

So the latest theory is that mouse pointer emulation out of touch events inside Qt (more specifically, inside QQuickWindow) breaks for some reason. So all MouseArea elements in unity8 stop getting events but other elements that are touch-event based like the indicator panel and edge gestures keep working.

Upstream fix (or work around, depending on how you see it) here:
https://codereview.qt-project.org/#/c/93002/

Upstream seems to currently think (as per given code reviews) it's not the right level to do a workaround at, ie. platform should behave correctly or constrain the problematic behavior at a lower level. Although, the debate was still ongoing 3 days ago whether it's a realistic scenario that one holds touch so still that it doesn't generate any events - if it's unlikely enough, a time limit approach could be used when no new touch updates are received for a certain time and a new touch begins. The discussion could probably continue with a new patch set with the time limit approach.

@Timo

I decided to do the touch stream validation at qtmir level instead, ensuring qtmir always provides a sane and clean stream of touch events to Qt regardless of what comes to it, thus avoiding Qt from getting stuck at that bogus state. Or so I hope :)

But of course it would be nice to have Qt more resilient/robust as well.

would be good to get the fix landed in rtm today or tomorrow so we can use a promoted image to hand to customer QA team this week..

Here's a way to easily reproduce it with the dash to verify if this issue is fixed:

* tap and hold the dash (do not release)
* with the other hand, drag in the launcher and launch an app
* when the other app has started, release the first finger

=> Dash mouse input will be broken. You cannot scroll the dash any more or tap entries. However, touch input still works as you can still activate the bottom edge.

@Zanetti

> Here's a way to easily reproduce it with the dash to verify if this issue is fixed:
> [...]

Thanks for that test case! Very useful.

That's another issue, which lp:~dandrader/qtmir/missingTouchEnd-lp1295623 doesn't fix. I was hoping to deal with it in another bug report but we can keep using this one since to the user it's hard to distinguish between the two.

So, those are the problems:

1 - unity8 not receiving a touch end from Mir (or lower, like the evedev device) and thus having its mouse event emulation getting stuck
2 - A MirSurfaceItem inside unity8's QML scene not receiving a touch end, and thus leaving the mouse event emulation of the corresponding Qt client app stuck (like unity8-dash).

So lp:~dandrader/qtmir/missingTouchEnd-lp1295623 fixes item 1. Now I'm working on a fix/workaround for item 2. Item 2 does look like a Qt bug (although some might claim we're using its API wrongly). It happens when you disable an Item while it's owning a touch point, which causes QQuickWindow's event delivery to stop sending touch events for that Item (which is ok). But it will never get further updates for that touch point even when reenabled. Meaning it will never get a TouchEnd for that touch. When you tap on it again it receives a whole new TouchBegin like if the previous touch point, whose end is still pending, never existed. So, when you disable an Item that owns a touch point I think QQuickWindow should synthesize a TouchEnd for that disabled Item.