Closed Bug 1213342 Opened 9 years ago Closed 7 years ago

Touch and drag doesn't scroll (on Linux)

Categories

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

Product:
Core
Component:
Widget: Gtk
Version:
44 Branch
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: koalay, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: tpi:+) 

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

Steps to reproduce:

1. Boot Linux on a touch screen platfor
    (tested on HP Spectre X360, GNOME 3.16, Ubuntu 15.10)
2. Open Firefox  for Linux (Firefox 41.0)
3. Browse to a long page where you can scroll
4. Touch down onto the blank place
5. Drag up and down


Actual results:

Some of the page contents are highlighted.
As if I move the mouse cursor to that position, click-and-hold, then drag.


Expected results:

The page should scroll opposite to my drag direction.
(Tested the latest Chrome on the same platform, it works)
OS: Unspecified → Linux
Depends on: 978679
I've just tried to run `MOZ_USE_XINPUT2=1 ./firefox` (with nightly). After several test:

1. Setting `dom.w3c.touch_events.enabled` to 2 doesn't fix the scrolling behaviour
2. Setting `dom.w3c.touch_events.enabled` to 1 works

A bit different than the behaviour discussing on bug 1217515.
Interesting. I guess WidgetUtilsGTK::IsTouchDeviceSupportPresent() must be returning false on your system so the autodetection is failing. Setting it to 1 bypasses that check and force-enables the touch events, and that seems to be working. Sounds like a bug in the autodetection - failing when it should be passing.
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
(I'm morphing this bug to track this new issue on Nightly - the original issue you filed this bug for is expected, since we only added touch support as of Firefox 44)
Version: 41 Branch → 44 Branch
Touch support for Linux wasn't added until 44, this is filed against 41
Is there anyway I can actually test WidgetUtilsGTK::IsTouchDeviceSupportPresent() on my system to verify? Anyway I can help tackling the bug?
If you're comfortable with building firefox locally and debugging then you can do that - the function is in widget/gtk/WidgetUtilsGtk.cpp. If not I can probably put together a try build with additional logging for you to run and collect output from.
I'm not a cpp guy at all. I have no idea how to do it myself. If you could build me something to run / write me something to build and run, I'll be happy to test here. Thanks a lot!
I did a try build with some logging: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b943d10d67bf

Please download the appropriate build (32-bit [1] or 64-bit [2]) and run it from the command line, saving the output to a file. Just starting it up with dom.w3c_touch_events.enabled set to 2 and shutting it down should be sufficient to run the function and get the necessary output. You can probably also run it like so:

./firefox 2>&1 | grep Bug1213342

and grab the output from that.

[1] http://archive.mozilla.org/pub/firefox/try-builds/kgupta@mozilla.com-b943d10d67bf4b24da6d738caccdbff172bfd85b/try-linux/firefox-45.0a1.en-US.linux-i686.tar.bz2
[2] http://archive.mozilla.org/pub/firefox/try-builds/kgupta@mozilla.com-b943d10d67bf4b24da6d738caccdbff172bfd85b/try-linux64/firefox-45.0a1.en-US.linux-x86_64.tar.bz2
Without MOZ_USE_XINPUT2=1:

> Bug1213342: returning 0
> Bug1213342: returning 0
> Bug1213342: device source 5
> Bug1213342: returning 1


With MOZ_USE_XINPUT2=1:

> Bug1213342: device source 5  
> Bug1213342: returning 1
> Bug1213342: device source 5
> Bug1213342: returning 1
> Bug1213342: device source 5
> Bug1213342: returning 1
That's odd, it is returning 1 in the XINPUT2 case so when you are running that with the touch events pref set to 2 it should work just fine. There should be no difference between that and running with the pref value set to 1.
I can confirm that 20151127 doesn't scroll but rather attempts to highlight.
@Paul, was it working for you before, or did you just happen to try this particular nightly? There was a change that landed not too long ago that might have broken it if it used to work for you.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #13)
> @Paul, was it working for you before, or did you just happen to try this
> particular nightly? There was a change that landed not too long ago that
> might have broken it if it used to work for you.

It's never worked for me but this is the first nightly that has come through the Ubuntu PPAs since bug 978679 landed so I never got to test.
Depends on: 1207700
Has Mozilla given up on getting touch working on Linux?
(In reply to Paul [pwd] from comment #15)
> Has Mozilla given up on getting touch working on Linux?

Definitely not! It should work on a recent version of Firefox (using GTK3) if you enable XInput2 manually by defining MOZ_USE_XINPUT2=1 in your environment, and bug 1207700 tracks using XInput2 by default.
On Firefox 47 (with MOZ_USE_XINPUT2=1), still doesn't work.
(In reply to Koala Yeung from comment #17)
> On Firefox 47 (with MOZ_USE_XINPUT2=1), still doesn't work.

You need to have e10s enabled along with MOZ_USE_XINPUT2=1. In 47 and 48 release builds you can set the browser.tabs.remote.force-enable pref to true and restart the browser to ensure that. 47 doesn't have e10s enabled by default on release.
Priority: -- → P4
Whiteboard: tpi:+
* On Firefox 49
* env MOZ_USE_XINPUT2=1
* browser.tabs.remote.autostart=true
* browser.tabs.remote.autostart.2=true
* there is no "browser.tabs.remote.force-enable" in this version

Still doesn't work.
(In reply to Koala Yeung from comment #19)
> * there is no "browser.tabs.remote.force-enable" in this version

It doesn't exist in any version. You have to add it manually in about:config.
Got it work finally.

For people who might have similar issue:

1. Go to about:support and find "Multiprocess Window". If you got 0, e10s is disabled and things won't work.

2. You have to disable the "Ubuntu Modifications" extension first. It is not e10s ready. (see this bug: https://bugs.launchpad.net/ubuntu/+source/ubufox/+bug/1627290)

3. If you still can't get things work after disabling "Ubuntu Modifications", check your other extensions (here: http://arewee10syet.com/) and see if it support e10s yet.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
This is still not enabled _per default_. I suggest this ticket should be reopened until this actually works out of the box. Can this be reopened?
(In reply to jonas from comment #22)
> This is still not enabled _per default_. I suggest this ticket should be
> reopened until this actually works out of the box. Can this be reopened?

Once bug 1207700 is fixed it will automatically be enabled by default. Therefore there's no point in having this bug open as well, as all the work that needs to be done is in bug 1207700.

Things seems working fine now even without the MOZ_USE_INPUT2 flag. I'd consider it fixed.

You need to log in before you can comment on or make changes to this bug.