Closed Bug 1055214 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: Panning and Zooming, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

VERIFIED FIXED
2.1 S3 (29aug)
blocking-b2g 2.1+
Tracking Status
b2g-v1.4 --- unaffected
b2g-v2.0 --- unaffected
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: sotaro, Assigned: drs)

References

Details

(Keywords: regression)

+++ 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".
kats, do you know a similar bug to this?
Flags: needinfo?(bugmail.mozilla)
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.
Flags: needinfo?(bugmail.mozilla)
Summary: [HERE Maps] → [HERE Maps] clicking on preferences doesn't seem to work
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.
Component: Panning and Zooming → Mobile
Product: Core → Tech Evangelism
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
Component: Mobile → Preinstalled B2G Apps
QA Wanted for branch checks.
Keywords: qawanted
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
[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.
blocking-b2g: 2.1? → 2.0?
Component: Preinstalled B2G Apps → General
Product: Tech Evangelism → Firefox OS
Version: Trunk → unspecified
QA Contact: pcheng
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 ?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Broken by Bug 625289? Can you take a look David?
Flags: needinfo?(jmitchell) → needinfo?(dbaron)
comment 8 disagrees with comment 6 (which says 2.0 is affected). Presumably one of those comments is wrong.
(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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dbaron)
Keywords: qawanted
[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
blocking-b2g: 2.0? → 2.1?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
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.
Blocks: 1037066
Component: General → Panning and Zooming
Product: Firefox OS → Core
I confirmed that backout of bug 1037066 fixed the problem on master flame.
Assignee: nobody → drs+bugzilla
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
If fixing this bug takes longer, it seems better to backout Bug 1037066.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Not a duplicate; fixed via backout.
Resolution: DUPLICATE → FIXED
Target Milestone: --- → 2.1 S3 (29aug)
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.
blocking-b2g: 2.1? → 2.1+
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.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(dharris)
You need to log in before you can comment on or make changes to this bug.