Touch events enabled on Windows desktop (nightly only)

[Kartikaya Gupta]

In bug 1180706 I turned on the dom.w3c_touch_events.enabled pref for
Windows desktop builds. This should be in Jan 31 nightly. For devices
that have touchscreens, this has two effects:

1) Touch scrolling now uses APZ. The physics will probably need some
tuning, but if you see correctness issues with scrolling, tapping,
long-tapping, etc., please file a bug and cc me. Pinch zooming is
currently disabled.

2) Web content will be receiving touch events. This may result in
pages responding very differently when using touch to interact with
it. Pages may also do different things on load, because they can
detect the presence of touch interfaces via window.Touch and
window.TouchEvent which wasn't the case before. If you observe
strange/buggy behaviour on touchscreen windows devices that wasn't
there before, try setting dom.w3c_touch_events.enabled to false
(restart required) to confirm it was caused by this change, and please
file a bug and cc me if so.

For the moment this change will remain on Nightly until we are
confident that it doesn't break anything major.

Note also that touch event support has been enabled on Linux for a
while now (not just Nightly) although you need MOZ_USE_XINPUT2=1 in
the environment for it to work. If you have a Linux touchscreen device
please feel free to try it out there as well and file bugs if you
encounter any problems.

Thanks!
kats

[Kartikaya Gupta]

Oh, I should also mention that currently many (if not all) Windows
touchscreen devices have e10s disabled by default, because a
touchscreen seems to trigger the accessibility code which disables
e10s. And if e10s is disabled, APZ is disabled, which means no APZ
touch scrolling. If you encounter bugs in this configuration, again,
please file. If you want to force-enable e10s (and therefore APZ), you
can set the browser.tabs.remote.force-enable pref to true.

[Justin Dolske]

On 2/1/16 9:51 AM, Kartikaya Gupta wrote:
> Oh, I should also mention that currently many (if not all) Windows
> touchscreen devices have e10s disabled by default, because a
> touchscreen seems to trigger the accessibility code which disables
> e10s. And if e10s is disabled, APZ is disabled, which means no APZ
> touch scrolling.

I assume there's a bug(s) on file for making e10s/a11y work right on
touch devices?

Looking at the TOUCH_ENABLED_DEVICE telemetry probe, while touch devices
are a fairly small segment of the overall userbase (~2%, for beta 44),
it's significantly higher on what I'd expect to be modern hardware (7.4%
of Windows 10 users, 6.9% for Win8.1).

Justin

[Gijs Kruitbosch]

Several people including me have been bitten by this, but based on the
last comment on https://bugzilla.mozilla.org/show_bug.cgi?id=1166564, it
seems the current plan is "fix a11y to work on e10s so we can enable it
for a11y users, too" (because it is too difficult to distinguish the UIA
touch a11y that win8/win10 use from the other ones, apparently).

I too would hope we will fix a11y+e10s, or at least fix the messaging
about this, before we release.

~ Gijs

[Bill McCloskey]

On Mon, Feb 1, 2016 at 2:12 PM, Gijs Kruitbosch <gijskru...@gmail.com>
wrote:

> Several people including me have been bitten by this, but based on the
> last comment on https://bugzilla.mozilla.org/show_bug.cgi?id=1166564, it
> seems the current plan is "fix a11y to work on e10s so we can enable it for
> a11y users, too" (because it is too difficult to distinguish the UIA touch
> a11y that win8/win10 use from the other ones, apparently).
>
> I too would hope we will fix a11y+e10s, or at least fix the messaging
> about this, before we release.

Fixing a11y+e10s is pretty difficult. It will be many months of work. I
think it makes sense to roll e10s out to most users before a11y support is
ready.

We definitely should investigate making special accommodations for users of
touch devices. But even that is fairly difficult. We have to figure out
what subset of the a11y API is actually being used on these devices and
then make sure that that subset works. As far as I know, finding that
subset is only possibly by experimentation, and it has to be done by
someone with a device where the problem reproduces. And finding people to
work on Windows is not easy.

I don't know what we would do about messaging. We're not planning on having
any UI besides about:support where people will know that e10s is enabled.
The hope is that it will be completely transparent.

I can imagine it's frustrating if you have one of these devices, but we
have to prioritize how we spend our time. And I don't think it's worth
holding up the whole project for a few percent of users, even if they are
the cool ones :-).

-Bill


>
>
> ~ Gijs
>
>
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[smaug]

That 7.4% is significantly *lower* than what I'd expect for modern hardware. I would have expected something like 25% or higher, based on the
laptops being sold in Finland.
But anyhow, 7.4% is definitely high enough that we should make the a11y work a top priority thing, like having some small group of people working only
on that or something.
(unfortunately the first approach for e10s+a11y didn't seem to have quite worked.)



-Olli

[Justin Dolske]

On 2/1/16 2:37 PM, Bill McCloskey wrote:

> I can imagine it's frustrating if you have one of these devices, but we
> have to prioritize how we spend our time. And I don't think it's worth
> holding up the whole project for a few percent of users, even if they are
> the cool ones :-).

Yep, incremental improvements are good. I don't think this should block
an E10S rollout for everyone.

But I did want to point it out, because touch-enabled devices are more
and more widespread, and APZ (responsiveness) is particularly important
there. And then there's the issue of "I just bought a new
(touch-enabled) computer and Firefox seems janky" being awkward when
that new computer probably includes Edge or Chrome for the user to
compare with and possibly switch to.

So I do think this is something important to fix soon.

Justin

[Jim Mathies]

On Monday, February 1, 2016 at 11:50:44 AM UTC-6, Kartikaya Gupta wrote:
> In bug 1180706 I turned on the dom.w3c_touch_events.enabled pref for
> Windows desktop builds. This should be in Jan 31 nightly. For devices
> that have touchscreens, this has two effects:

The last time we turned this on it caused numerous problems. Please see bug 806805 for a list of issues that cropped up.

One problem is that the touch events we send from win32 widget aren't spec, the other involved sites that started treating desktop like mobile. We ended up having to turn touch events off due to these issues.

[Kartikaya Gupta]

Thanks for the pointer to the metabug! I'll keep an eye on it and try
to test those issues to see if they still happen. This was a major
concern for me as well, which is why this is Nightly-only for now.
Even if there are sites that are broken I definitely think we should
push hard to get them fixed because we can't not support touch
forever.

[Mike Taylor]

On 2/3/16 9:46 AM, Kartikaya Gupta wrote:
> Thanks for the pointer to the metabug! I'll keep an eye on it and try
> to test those issues to see if they still happen. This was a major
> concern for me as well, which is why this is Nightly-only for now.
> Even if there are sites that are broken I definitely think we should
> push hard to get them fixed because we can't not support touch
> forever.

Feel free to needinfo? me on these issues to investigate as well, I'm
also interested -- especially with the inference that "has touch events"
means "probably supports WebKit stuff".

e.g., <https://bugzilla.mozilla.org/show_bug.cgi?id=1244464#c8> (but not
the cause of this bug in particular).

--
Mike Taylor
Web Compat, Mozilla