to input-dev triage queue

This is WAI and a problem on the page. The body has touch-action: none set so we shouldn't do any panning or zooming. This is consistent with Firefox on Android. Panning and zooming works on Safari as they don't support touch-action.

Should we ask dev rel to reach out? This is a feedback from a friend. User will just think it doesn't work in Chrome.

If the content size is much larger than the viewport. And there is repeat scroll gesture. Should we ask user whether they want to override the bad property?

+aerotwist@

Reaching out is probably the best way to go. An intervention here has potential to break legitimate use cases and we haven't seen many pages like this to justify a heavy-handed approach.

Paul, is there a procedure for reaching out to broken sites?

Is there a specific library involved here?  Eg. we had a lot of success getting people to update to a version of hammer.js which fixed their touch-action bug when we first launched touch-action support.  Ideally we'd identify some library we could submit a github issue or pull request against.  Though we'd likely still have the problem of getting kaspersky.com to deploy it.

Note that WebKit will likely ship full touch-action support eventually, so this issue will probably impact Safari. https://bugs.webkit.org/show_bug.cgi?id=133112.  Every other modern browser now has it (with Firefox close to enabling by default), so the main issue here is just that Safari has been slower than all other browsers to deploy this feature.

In the past we've found site outreach for anything but the top-100 sites to be a waste of time (rarely can find anyone to talk to) and so not something DevRel does.  That said, someone could easily submit a "contact us" form on kapersky.com if they wanted to try.

In general I don't believe providing user-options to work around site bugs will scale.  How would we avoid offering that option, for example, whenever someone swipes on top of a carousel embedded inside a scrollable page?  We could try to design a complicated set of heuristics to guess at what is a bug vs. correctly functioning UX, but it's going to be a nightmare to maintain and reason about.

Is there any reason to think this isn't an isolated instance? If we had examples of dozens of sites hitting this, that could change the equation.

If we really wanted to go down the path of working around site-by-site bugs, we could try following Opera and Microsoft in their attempts to create "site compatibility lists" which include extra JavaScript/CSS injected into specific websites to improve web compat.  They've both told us that after huge investments they've decided it was a mistake (caused more pain than benefit long-term).  But it's still very tempting to consider (especially for the issues we know of that impact a larger number of sites or result in serious performance problems).  I believe Microsoft and Mozilla have large teams devoted to site compat (including outreach and at one point maintaining such site-compat lists).  Grace, I'd be happy to discuss spinning up such a team if you think it would be a worthwhile investment.

I don'think we want to do "site compat list". That seems too expensive.

I know it is challenging to fix back compat issues. But this, touch-action, is kind of new. Is the incorrect behavior coming from some library?

In general, it's difficult to tell where a style is coming from. But I can't check anymore, it looks like the link has since been fixed, it now loads a mobile-friendly page that scrolls just fine. RDS loads what looks more like the old page but it also scrolls ok so I think the site author has fixed the issue.

Are they eavesdropping? :) Thanks.