1333098 - Touchscreen touch scrolling is brittle

Status: RESOLVED DUPLICATE of bug 1321069

(Core :: Widget: Gtk, defect, P3)

Description

[matt.panaro]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161209095719

Steps to reproduce:

I enabled e10s so that I could scroll via touch on my Dell XPS 13" 9350 with touchscreen.  I'm on Ubuntu 16.04.01. Initially, it worked very well, until I touch-long-clicked to get a context menu to open a link in a new tab


Actual results:

After successfully opening a link in a new tab, although I could still touch to scroll, several things went wrong
1. Scroll inertia disappeared: I could only scroll while I was actively touching the screen, no flicking to keep scrolling
2. Scrolling was much slower (though this may be directly related to issue 1.)
2. I was no longer able to touch to click anything: I couldn't click on a lick with a touch, nor could I long-touch to get a context menu for a link.  Nor can I switch tabs by touching, although the tab does highlight when touched.

Interestingly, while these symptoms persist across all tabs in the window in which they occurred, they do not affect other open windows; however, the bug is immediately reproducible in another open window


Expected results:

Touching behavior should not change at all, despite long-clicking to open a link.

Comment 1

[matt.panaro]

If  I CTRL+SHIFT+W (close window) and then CTRL+SHIFT+N (restore just-closed window), the normal expected behavior is restored.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Hm, almost sounds like APZ is getting disabled in the new window. Botond, can you repro this?

Comment 3

[Botond Ballo [:botond]]

I can! I'll look into it. Leaving needinfo on me for now.

Comment 4

[Botond Ballo [:botond]]

Looks like we somehow get stuck in the PINCHING state, so APZ thinks we're doing two-fingered panning. We don't currently do momentum scrolling for a two-fingered pan (bug 1180799).

Comment 5

[Botond Ballo [:botond]]

The issue is not in APZ: APZ is receiving touch events with two touch points after the long tap.

nsWindow::mTouches seems to get stuck with two elements after the long tap, suggesting that the issue is in the GTK widget code.

Comment 6

[Botond Ballo [:botond]]

It looks like touch_event_cb() is never called with a GDK_TOUCH_END for the long-tap. So this may even be an issue in GTK itself, although I don't understand GTK and the widget code well enough to say for sure.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Could it be the touch-end event is getting delivered to a different window, because the long-tap creates a context menu window?

Comment 8

[Botond Ballo [:botond]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> Could it be the touch-end event is getting delivered to a different window,
> because the long-tap creates a context menu window?

So the context menu window does get its own nsWindow, and that nsWindow also registers a touch-event callback, but that callback doesn't receive a GDK_TOUCH_END event, either.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Ok, that sounds like a gtk bug then. (Unless it's actually the intended gtk behaviour, which I doubt)

Comment 10

[matt.panaro]

So should I go ahead and open a bug on bugzilla.gnome.org?

Comment 11

[Botond Ballo [:botond]]

I actually found another bug about this issue, where :karlt and :stone have done some investigation and gotten further than we did in this bug: bug 1321069. I'm going to dupe this over, and we can continue discussion in that bug.

Comment 12

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #8)
> So the context menu window does get its own nsWindow, and that nsWindow also
> registers a touch-event callback, but that callback doesn't receive a
> GDK_TOUCH_END event, either.

(Just to follow up on this: based on the discussion in bug 1321069, the context menu window *does* receive the GDK_TOUCH_END event, you just need to ask for the callback to receive touch events at all by including GDK_TOUCH_MASK in another API call. The solution being explored in bug 1321069 is along the lines of including the GDK_TOUCH_MASK so the context window gets the TOUCH_END event, and then routing the event to the correct nsWindow.)

Comment 13

[matt.panaro]

thanks everybody for helping out: your efforts are most appreciated

Comment 14

[Botond Ballo [:botond]]

You're very welcome!

Please keep the bug status as DUPLICATE; it allows the two bugs to be linked for reference.

Comment 15

[Botond Ballo [:botond]]

I can confirm that the patch in bug 1321069 fixes this.