944082 - Double tap delay introducing large tap latency

Status: RESOLVED DUPLICATE of bug 941995

(Core :: Panning and Zooming, defect)

Description

[Benoit Girard (:BenWa)]

Currently the APZC supports *double* tap (NOT long tap). To implement this we have a delay to wait for a touch down after a single tap gesture has been detected. Currently this is introducing a 300ms delay!!!

http://mxr.mozilla.org/mozilla-central/ident?i=MAX_TAP_TIME&filter=

Comment 1

[Benoit Girard (:BenWa)]

What roles do double taps play on mobile? 300ms for every touch is very costly and is easily our biggest bottleneck for responding to tap gestures events.

Comment 2

[Matt Brubeck (:mbrubeck)]

Double-tap is used in mobile browsers to zoom to an element.  This is useful especially on non-mobile-friendly web pages, for zooming in on a column of text, for example.

We already eliminate the delay on pages where zooming is disabled (bug 922896).

In responsive or mobile-optimized web pages or apps, double-tap is not as useful.  Chrome just announced that their next release will disable double-tap in web pages that are already sized to fit the screen without zooming:

http://blog.chromium.org/2013/11/chrome-32-beta-animated-webp-images-and.html

We may want to implement the same logic.

Comment 3

[Benoit Girard (:BenWa)]

Do we currently have this delay without APZC for apps or is this a regression from turning APZC for gaia?

Comment 4

[Matt Brubeck (:mbrubeck)]

(In reply to Benoit Girard (:BenWa) from comment #3)
> Do we currently have this delay without APZC for apps or is this a
> regression from turning APZC for gaia?

I believe this is a regression from turning on APZC for apps, since previously we did not support zooming gestures (pinch or double-tap) within apps.

However, any app that has this problem with APZC would have the same problem when running in Firefox for Android, or other mobile browsers like Safari or Chrome (early than Chrome 32).  A short-term solution that works in at least APZC and Fennec is to disable zooming with <meta name="viewport" content="user-scalable=no">.

(The longer-term solution may be to disable double-tap automatically for responsive apps, as described in the Chromium blog post above.)

Comment 5

[Benoit Girard (:BenWa)]

Perhaps this bug should be morphed to discuss the implication of introducing this to gaia as a side effect to turning on APZC. Remember APZC is an implementation optimizations so it shouldn't have side effects. If we want these side effects it should be an explicit decision, not an implicit decision from turning on the APZC switch.

(In reply to Matt Brubeck (:mbrubeck) from comment #4)
> (In reply to Benoit Girard (:BenWa) from comment #3)
> > Do we currently have this delay without APZC for apps or is this a
> > regression from turning APZC for gaia?
> 
> I believe this is a regression from turning on APZC for apps, since
> previously we did not support zooming gestures (pinch or double-tap) within
> apps.

We explicitly don't support this outside the top level APZC ATM.

Comment 6

[Matt Brubeck (:mbrubeck)]

(In reply to Benoit Girard (:BenWa) from comment #5)
> Perhaps this bug should be morphed to discuss the implication of introducing
> this to gaia as a side effect to turning on APZC.

Well, currently a B2G installed app is the only mobile web environment that does *not* include the ability to zoom, or the 300ms tap delay for zoomable content.  If you load the same app in Firefox for Android, or Safari, or even in the B2G browser, then you get the delay.  This changes Gaia from a weird non-standard environment to one that matches the mobile web platform.

For some apps, being able to pinch and/or double-tap zoom is a feature.  These can enable zooming and it will work cross-browser.  They can also intercept touch events if they want to handle taps without a delay.

For other apps where double-tap zooming is not desired, they should use the standard cross-browser viewport controls to disable it -- rather than assuming that they will only run in the non-standard Gaia environment.

Comment 7

[Matt Brubeck (:mbrubeck)]

(And conversely, if like Chrome we want to eliminate the double-tap gesture and tap delay for mobile apps, we should do it for apps running in Fennec and in the B2G Browser, not just for Gaia.  One web platform.)

Comment 8

[Benoit Girard (:BenWa)]

Thanks for the information. These are great points and not for me to decide.

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

Vivien, thoughts?

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

As Matt mentioned, this delay has never exists in Gaia because of the previous architecture, which was not really mobile, but much closer to desktop.

Hopefully bug 922896 has fixed it for apps with user-scalable=no which is great (note that this optimizations relies on the mAllowZoom flag and as I describe in https://bugzilla.mozilla.org/show_bug.cgi?id=942754#c4 it seems like there are some issues with it) and this sounds good enough for now (in the future we way want to be smarter like what chrome will do soon).

But in the current state, many apps in our marketplace will regress.

My opinion is that we should fix bug 940036 in Gecko for a little while, for example by saying that all apps that are installed as mozapp on the device as a default viewport of <meta name="viewport" content="width=device-width, height=device-height, user-scalable=no"> to mimick what was the previous state of the device and in the meantime, ask the markeplace guys to evangelize the use of the viewport tag for apps in the marketplace. Once it is clear that most apps are fixed we can remove this hack.

Not doing it right now will have the effect of breaking already installed apps layout and to introduce this 300ms delay for those apps. I understand 100% that this is something bad to fake a viewport for those apps, and I would like to not have to do it but I can live with it with one or two releases, the time for those apps to not be 'Gaia' only as mentionned by Matt. I don't think users/partners will understand that suddenly pre-installed apps are broken if we don't do that.

So in short, this bug does not block bug 909877 for me if we fix bug 940036 in Gecko (temporarily). Then we can be smarter about when to add this delay or not in the future.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Are there any apps where we want to allow user scalable behavior?  E-mail, SMS, ...?  If there are, and for those, what is the right thing to do?