Nightly 43.0a1 09/20/2015 SONY Xperia Z2 Android 5.0.2 Steps to reproduce: 1.User visits planet.mozilla.org 2.User views page in landscape mode 3.User double taps on page content 4.Repeats step 2 several times Expected result: After step 3:Page zooms in and a double-tap and zooms out at the next double-tap action Actual result: Page does not zoom out at a double tap action

Assuming this is a regression, can we get a regression window? I can't reproduce on a nexus 4.

This issue could be reproduced on Sony Xperia Z2 (5.0.2) and Nexus 9(5.1.1) by using the latest Nightly (44.0a1 09/30/2015) and Aurora(43.0a2 09/30/2015). On the Beta build (42.0b2), this issue could not be reproduced Please note that on a Nexus 7 (5.1.1), on the above mentioned builds, the issue could not be reproduced. For the Nightly build, the issue started reproducing with the 4th of September build For the Aurora build, the issue started reproducing with the 22nd of September build

Ioana would someone from the SV team show Mihai how to use MozRegression to get a regression range that has a mercurial mozilla-inbound change sets.

Hello Kevin, Here is the changelog http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7f987c38bd3e5ac9a834981e85378bdb02338e9d&tochange=e816a7a854a333bda1447ab6c5b633233f322669 . In the above mentioned log the following bug was found : https://bugzilla.mozilla.org/show_bug.cgi?id=1201539 that might trigger the issue. If this is not the case please let me know and further investigations will be performed in inbound builds

Can you attach a logcat of when this happens?

Attached, you will find the logcat

Converted from opendocument to plaintext, please attach logs in plaintext in the future. Also this log only has about two seconds worth of output. I guess it if it captures the doubletap that's fine, but there's nothing here that indicates what's going wrong. :(

Snorp, can you find an assignee here, since kats is PTO?

(In reply to mihai.ninu from comment #4) > Hello Kevin, > Here is the changelog > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=7f987c38bd3e5ac9a834981e85378bdb02338e9d&tochange=e816 > a7a854a333bda1447ab6c5b633233f322669 . > > In the above mentioned log the following bug was found : > https://bugzilla.mozilla.org/show_bug.cgi?id=1201539 that might trigger the > issue. If this is not the case please let me know and further investigations > will be performed in inbound builds I think it would be helpful to get a range on inbound as well.

(In reply to :Margaret Leibovic from comment #9) > (In reply to mihai.ninu from comment #4) > > Hello Kevin, > > Here is the changelog > > http://hg.mozilla.org/mozilla-central/ > > pushloghtml?fromchange=7f987c38bd3e5ac9a834981e85378bdb02338e9d&tochange=e816 > > a7a854a333bda1447ab6c5b633233f322669 . > > > > In the above mentioned log the following bug was found : > > https://bugzilla.mozilla.org/show_bug.cgi?id=1201539 that might trigger the > > issue. If this is not the case please let me know and further investigations > > will be performed in inbound builds > > I think it would be helpful to get a range on inbound as well. This bug started reproducing since 4th of September. In the tinder-box inbound folder, the earliest present build is from Sep 9th so an inbound range investigation cannot be performed.

Lets revisit when APZ is enabled, since that changes double tap behavior

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #11) > Lets revisit when APZ is enabled, since that changes double tap behavior The time is now! Has this changed on Nightly?

Hi Margaret, No, this issue can still be reproduced on Nightly (46.0a1), Aurora(45.0a2) and Beta (44.0b6) as it rode the train, in landscape view, the double-tap action still doesn't zoom in or zoom out. Tested on: Nexus 9 - Android 6.0 Sony Xperia Z2 - Android 5.0.2 Samsung Galaxy Tab S2 - Android 5.0.2

This issue is reproducible on Firefox 46 Beta 2 using Asus Transformer Pad (Android 4.2.1).

I took another look at the regression range and the code, and it looks like there's some dead code for the reflow-on-zoom feature that was left in. However it shouldn't be causing this problem, as far as I can tell - except if the reflow-on-zoom pref was true for these devices. I'll file a new bug to get rid of the dead code anyway, not sure if it'll fix this.

Since APZ didn't fix this (per comment 13) we should look into why. The fix for the APZ codepath is likely going to be different for the non-APZ codepath. I'm going to mark this wontfix for 46 and 47, we can look into fixing it for 48 with APZ.

Came up on SUMO @ https://support.mozilla.org/en-US/questions/1115657

I don't have a tablet to check if this is still reproducing. I'll try to grab one next time I'm in the toronto office.

Is there anything we can provide here to help fix this?

I picked up an Asus Transformer today that can reproduce the issue. I'll look into it.

So it looks like this behaviour is actually intentional, and the "regression" is really the correction of a *previous* regression. Here's the timeline: Build of Feb 22, 2014 [1]: double-tap zoom is allowed Feb 24/25 - Bug 941995 lands and disallows double-tap on devices with wide screens Build of Feb 26, 2014 [2]: double-tap zoom is not allowed Sometime between Feb 26, 2014 and Sep 4, 2015: there is a regression that allows double-tap zoom again Sep 4, 2015: double-tap zoom stops working The current behaviour (double-tap zoom not working) is the desired behavior as of bug 941995, see the discussion in that bug for details. Therefore this bug is a wontfix. For the record, the code that is preventing the double-tap zoom currently lives at [3] (I verified this was getting hit on the Asus Transformer Pad in landscape mode). [1] http://archive.mozilla.org/pub/mobile/nightly/2014/02/2014-02-22-03-02-04-mozilla-central-android/ [2] http://archive.mozilla.org/pub/mobile/nightly/2014/02/2014-02-26-03-02-02-mozilla-central-android/ [2] http://searchfox.org/mozilla-central/rev/790b2cb423ea1ecb5746722d51633caec9bab95a/layout/base/ZoomConstraintsClient.cpp#229