Julien Wajsberg [:julienw] Reporter
	Description • 7 years ago

After bug 1367765 it still doesn't work on my Windows 10 computer. In case this is a useful information: this is a computer with both a touchscreen and a trackpad.

* Example website where the problem occurs:
Any website really. For example http://www.lemonde.fr

* Graphics section of about:support
(coming in a subsequent comment)

* The symptoms that lead you to believe it's not working
I touch (on the touchscreen) the scrollbar and try to drag it, but instead everything happens as if the scrollbar isn't here. For example if I scroll by moving down the finger, it should go down, but it goes up.

It works fine in a non-content page like about:support.


I'll try on 58 and nightly as well.

	Julien Wajsberg [:julienw] Reporter
	Comment 2 • 7 years ago

This actually works as expected in latest nightly.

	Julien Wajsberg [:julienw] Reporter
	Comment 3 • 7 years ago

beta 58 too

	Julien Wajsberg [:julienw] Reporter
	Comment 4 • 7 years ago

OK, it actually works in 57 on a different profile. Only my partner's profile doesn't work :/
I checked the various "drag" prefs, they all have the default value to "true". I'm sure I miss something.

	Botond Ballo [:botond]
	Comment 5 • 7 years ago

(In reply to Julien Wajsberg [:julienw] from comment #1)
> Created attachment 8930672 [details]
> Graphics section of about:support

I'm not seeing "ApzTouchInput: 1" in there (in the about:support UI, that shows up as "touch input enabled" under "Asynchronous Pan/Zoom"). I'll bet that's the difference between this profile and the one where it works.

	Julien Wajsberg [:julienw] Reporter
	Comment 6 • 7 years ago

I'm sure I fiddled with the prefs over time, I'll look closer at the changed prefs.

The profile which works is not a "clean" new profile, it's also one that got converted over, but it's been a lot less used.

	Botond Ballo [:botond]
	Comment 7 • 7 years ago

What is the value of the "dom.w3c_touch_events.enabled" pref in the problematic profile?

	Julien Wajsberg [:julienw] Reporter
	Comment 8 • 7 years ago

Ah ah, dom.w3c_touch_events.enabled was at 0 instead of the default 2. Maybe I changed it at one point so that the scrollbar drag would work in a previous version.

I reset it to the default value and now everything works as expected.

Should we close this bug as "worksforme" or "invalid" ? Or would you want to do something with this pref like reset it, or remove it, in a future version ?

	Julien Wajsberg [:julienw] Reporter
	Comment 9 • 7 years ago

(heh I found it too :) )

	Botond Ballo [:botond]
	Comment 10 • 7 years ago

(In reply to Julien Wajsberg [:julienw] from comment #8)
> Ah ah, dom.w3c_touch_events.enabled was at 0 instead of the default 2. Maybe
> I changed it at one point so that the scrollbar drag would work in a
> previous version.
> 
> I reset it to the default value and now everything works as expected.

Ok, great, glad it works now!

> Should we close this bug as "worksforme" or "invalid" ? Or would you want to
> do something with this pref like reset it, or remove it, in a future version
> ?

I don't think there's a need to reset or remove the pref. It's a regular feature pref like we have for many CSS and DOM features; we generally don't expect users to fiddle with them.

	Julien Wajsberg [:julienw] Reporter
	Comment 11 • 7 years ago

Yep I see. It's "funny" this works even with this pref to "0" for all privileged pages like about:support though. So it's funny we need this pref to be to "2" (or maybe "1" works too) for this to work in a non-privileged context.

Anyway, thanks for your time, happy to have it working now :)

	Botond Ballo [:botond]
	Comment 12 • 7 years ago

(In reply to Julien Wajsberg [:julienw] from comment #11)
> Yep I see. It's "funny" this works even with this pref to "0" for all
> privileged pages like about:support though. So it's funny we need this pref
> to be to "2" (or maybe "1" works too) for this to work in a non-privileged
> context.

I agree that that's funny, and worth investigating.

On Linux, scrollbar dragging actually works on all pages even with the pref set to "0", because when touch support is disabled, the OS generates mouse events corresponding to the touch events instead, and our mouse-dragging codepath is activated.

I'm not sure what is happening on Windows that would cause things to work on about:support but not content pages. I would investigate further, but that requires a Windows build, and I'm currently having trouble doing any Windows development (bug 1421083).