Closed Bug 1095709 Opened 10 years ago Closed 10 years ago

[Marketplace][Settings] User is unable to open the Settings menu in the Marketplace app.


(Marketplace Graveyard :: Consumer Pages, defect, P1)

Gonk (Firefox OS)



blocking-b2g 2.2+


(Reporter: Marty, Assigned: kngo, NeedInfo)




(Keywords: regression, verifyme, Whiteboard: [2.2-Daily-Testing])


(1 file)

Attached file Marketplace-log.txt
The user taps on the Gear icon, but the main Marketplace screen simply reloads.
Repro Steps:
1) Update a Flame device to BuildID: 20141107073659
2) Open the Marketplace app
3) Tap on the Gear icon to open the Marketplace Settings menu
The Settings  menu is not opened, and the main Marketplace screen reloads

The Settings menu is opened.
Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141107073659 (Shallow Flash)
Gaia: 779f05fead3d009f6e7fe713ad0fea16b6f2fb31
Gecko: b62ccf3228ba
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
Notes: This occurs with both 319MB and 512MB memory.

Repro frequency: 7/7
See attached: video clip (URL), logcat


This issue does NOT occur in Flame 2.1.
The Marketplace settings menu is opened properly.

Environmental Variables:
Device: Flame 2.1
BuildID: 20141107001205 (Shallow Flash)
Gaia: 6295f6acfe91c6ae659712747dd2b9c8f51d0339
Gecko: 8c23b4f2ba29
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(onelson)
Using the latest nightly and Flame, I can reproduce this intermittently using:

Gaia   779f05fead3d009f6e7fe713ad0fea16b6f2fb31
SourceStamp b62ccf3228ba
BuildID 20141107073659
Version 36.0a1
Observed what was observed in Comment 1 by Marcia, issue did not appear to be 100% repro. However, bad UX when encountered as user is unable to navigate their marketplace settings.
Tagging qawanted for branch checks.
Appears to be a regression following comment 0's results.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(onelson)
Keywords: qawanted, regression
Confirmed branch checking results from comment 0. Issue is 10/10 reproducible on 2.2, and 0/10 on 2.1 for me.

Also checked 2.0 and issue is NOT reproducible in all 10 attempts.

Device: Flame 2.0
BuildID: 20141110000204
Gaia: d3e4da377ee448f9c25f908159480e867dfb13f3
Gecko: 7198906837e7
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

For some reason there isn't a tracking flag available on this bug. To summarize, issue occurs on 2.2, and does NOT occur on 2.1 and 2.0.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Blocking on 2.2, issue is a regression and broken functionality
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: pcheng
mozilla-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20141106045424
Gaia: 068b9711277b06c7d633517f9e1fcb5624bb39b3
Gecko: e25127d1ad19
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20141106050822
Gaia: 068b9711277b06c7d633517f9e1fcb5624bb39b3
Gecko: e2a1f8575950
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

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

Gecko pushlog:

Possibly caused by Bug 1093686?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Possibly caused by Bug 1093686? - can you take a look?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(bugmail.mozilla)
QA Contact: pcheng
It probably was regressed by bug 1093686, yes. Prior to that click events were not retargeted to nearly "clickable" elements on pages where the body element had a touch/mouse listener. This was a bug, and so now we are getting the correct behaviour. The problem here is that the marketplace settings icon is not designated as "clickable" because it's an anchor tag with no href. It also doesn't specify a role="button" or any such "clickable-ness" indicator. So when the user taps on it we retarget the click to the the marketplace icon just above, as that is determined to be the nearest clickable element within the retargeting radius.

I think this is probably best fixed in the marketplace app itself, because as-is that settings icon is not accessibility-friendly either. The simplest fix is to just add a role="button" on it, that should make it "clickable" according to the platform retargeting heuristics. Other options include setting an href attribute or adding any sort of touch/mouse listeners to it.
Flags: needinfo?(bugmail.mozilla)
Assignee: nobody → kngo
Priority: -- → P1
Target Milestone: --- → 2014-11-18

Sorry for the long turnaround time. Didn't notice this bug in my queue.
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: 2014-11-18 → 2014-12-02
Verified the issue is fixed on 2.2 Flame.

Settings menu is available in "Marketplace"

"Flame 2.2

Device: Flame 2.2 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141201040205
Gaia: 39214fb22c203e8849aaa1c27b773eeb73212921
Gecko: 08be3008650f
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (Unknown)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Adding " verifyme" for 2.1
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
triage: blocking

Kevin, could you request uplift to 2.2?
blocking-b2g: 2.2? → 2.2+
Flags: needinfo?(kngo)
You need to log in before you can comment on or make changes to this bug.