1055214 - [HERE Maps] clicking on preferences doesn't seem to work

Status: VERIFIED FIXED

(Core :: Panning and Zooming, defect)

Description

[Sotaro Ikeda [:sotaro]]

+++ This bug was initially created as a clone of Bug #1049195 +++

This bug is created based on Bug 1049195 Comment 26. On latest master flame, it is very difficult to select items in Preferences in "HERE Maps" app.

[1] In stall "HERE Maps" from marketplace.
[2] Start "HERE Maps"
[3] Select the layers button on the bottom right corner.
     It is "Preferences".
[4] Touch items in "Preferences".

On master flame, in [4], it is very difficult to touch items in "Preferences".

Comment 1

[Sotaro Ikeda [:sotaro]]

kats, do you know a similar bug to this?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

No, I don't. I took a quick look at the app in app manager and it seems to be getting the touch events and click events, but it has touch listeners and click listeners that are run obfuscated code so I can't tell what it's trying to do.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I added more logging and it looks like the app is calling preventDefault on the touchstart event and trying to handle it internally. This doesn't appear to be an APZ issue, it is likely an evangelism issue. Note that the APZ code to deal with touch listeners and prevent-default was rewritten in 2.1 to be more correct; it's quite possible that this was only working by accident in 2.0 and previous versions.

Comment 4

[Sotaro Ikeda [:sotaro]]

[Blocking Requested - why for this release]:

Comment 5

[Jason Smith [:jsmith]]

QA Wanted for branch checks.

Comment 6

[Rachel Pribble [:rpribble]]

The touch area for the buttons appears to be too far to the right.  If the user touches to the right of the buttons instead of directly on them, the options are selected as expected.

-------------------------------------------------

I am able to repro this issue on the Flame v2.1, Flame v2.0, and Buri v2.1.
Buttons are difficult to select unless the user touches in the area to the right of the buttons.

Device: Flame Master (319mb)
BuildID: 20140818040201
Gaia: aa8aace12d65956dd9525da5dac66e0d3b28597f
Gecko: 0aaa2d3d15cc
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0"

Device: Flame 2.0 (319mb)
BuildID: 20140818000201
Gaia: fb2dd31abed2803eb7ad67eb4c52abb48de1e0f7
Gecko: 09f7a7184c71
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Buri 2.1 Master
BuildID: 20140819040202
Gaia: b33b4d9558e0b9eabbfda7be23435e2b38fd40bf
Gecko: 111a1da2a95d
Version: 34.0a1 (2.1 Master)
Firmware: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

------------------------------------------------
I am unable to repro this issue on the Flame v1.4.
Buttons are able to be selected as expected.

Device: Flame 1.4 (319mb)
Build ID: 20140818063007
Gaia: 21bec64497dc06a7f12071d573570ba8fea598ae
Gecko: 07d78d0f9bef
Version: 30.0 (1.4)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 7

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: switching from 2.1 to 2.0 - comment 4 (the original nomination) did not list any reasons why but I'm assuming it is because this is a regression and makes the settings unusable if the user does not discover the hit-detection is to the right of the buttons.

Comment 8

[Pi Wei Cheng [:piwei] (inactive)]

mozilla-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140813153056
Gaia: a2219a55145e730e56e09527b40152d68a43b0d9
Gecko: ddda7acf3739
Version: 34.0a1 (2.1 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20140813154054
Gaia: a2219a55145e730e56e09527b40152d68a43b0d9
Gecko: c57732433b20
Version: 34.0a1 (2.1 Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Gaia is the same so it's a Gecko issue.

Gecko pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ddda7acf3739&tochange=c57732433b20

Possibly caused by Bug 625289, or Bug 1037066 ?

Comment 9

[Joshua Mitchell (Inactive)]

Broken by Bug 625289? Can you take a look David?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

comment 8 disagrees with comment 6 (which says 2.0 is affected).  Presumably one of those comments is wrong.

Comment 11

[Jason Smith [:jsmith]]

(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) (away/busy Aug 27-Sep 11) from comment #10)
> comment 8 disagrees with comment 6 (which says 2.0 is affected).  Presumably
> one of those comments is wrong.

Ah, that's right. Flagging qawanted to double check branch checks & the window.

Comment 12

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: (switching from 2.0 to 2.1)

Part of the initial Branch Check was incorrect:

This issue DOES NOT reproduce on Flame 2.0

Actual Results - User can set preferences and select options by clicking on the expected area

Device: Flame 2.0
Build ID: 20140818153113
Gaia: 3df0c5f1ee3e208d1e8cbfe399baf1095e673c4f
Gecko: ef6277f356d9
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 2.0  (319 mem AND 512 mem)
Build ID: 20140818000201
Gaia: fb2dd31abed2803eb7ad67eb4c52abb48de1e0f7
Gecko: 09f7a7184c71
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 13

[Kartikaya Gupta (email:[e-mail])]

If the regression range in comment 8 is correct then it might be bug 1037066. That code is certainly relevant and is exercised while trying to tap on things. I don't see a bug in it based on code inspection but that doesn't mean there isn't one. CC'ing doug as well.

Comment 14

[Sotaro Ikeda [:sotaro]]

I confirmed that backout of bug 1037066 fixed the problem on master flame.

Comment 15

[Sotaro Ikeda [:sotaro]]

If fixing this bug takes longer, it seems better to backout Bug 1037066.

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Not a duplicate; fixed via backout.

Comment 18

[bhavana bajaj [:bajaj]]

Switching the 2.1?->2.1+, on these fixed bugs as these are regression.

Nothing to land here, its just flag-cleanup of 2.1? list. Please Ni me if there is confusion/disagreement.

Comment 19

[John Thomas [:Johnt]]

This issue is verfied fixed for the Flame 2.2 Master (319mb) and the Flame 2.1 KK (319mb)

Flame 2.2 Master KK (319mb) (Full Flash)

Device: Flame 2.2 Master
BuildID: 20141011040204
Gaia: 95f580a1522ffd0f09302372b78200dab9b6f322
Gecko: 3f6a51950eb5
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.1 KK (319mb) (Full Flash)

Device: Flame 2.1
BuildID: 20141011000201
Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1
Gecko: d813d79d3eae
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Result: Here Maps Preferences are working responsively.