If rocketbar is ever opened, the value selector will not show again

VERIFIED FIXED in 2.2 S5 (6feb)


4 years ago
4 years ago


(Reporter: alive, Assigned: alive)



2.2 S5 (6feb)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 verified, b2g-master verified)



(2 attachments)

This is regression coming from bug 1124216:
* Open rocketbar.
* Go back to homescreen, open any app with value selector
* Click the <select>

The selector will not show.

We should check the module is active or not before broadcast the events.

Patch coming soon.
Comment on attachment 8558995 [details] [review]
[PullReq] alivedise:bugzilla/1129329/ignore-inactive-module to mozilla-b2g:master

Shame on me :/
Attachment #8558995 - Flags: review?(etienne)
Blocking request due to regression
blocking-b2g: --- → 2.2?
Comment on attachment 8558995 [details] [review]
[PullReq] alivedise:bugzilla/1129329/ignore-inactive-module to mozilla-b2g:master

Attachment #8558995 - Flags: review?(etienne) → review+
Tested my patch on top of this and is working great now, thanks
So I am going to use alternative (protect inside rocketbar to avoid the issue) because I found it's necessary for TaskManager who is inactive to get the holdhome events - unless we want to have a special case for task manager (Maybe module#BROADCAST_INACTIVE?).
Duplicate of this bug: 1129403
Closed: 4 years ago
Resolution: --- → FIXED
Comment on attachment 8558995 [details] [review]
[PullReq] alivedise:bugzilla/1129329/ignore-inactive-module to mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Regression of 1124216.
[User impact] if declined:
Unable to use select anymore once rocketbar is opened
[Testing completed]: Y
[Risk to taking this patch] (and alternatives if risky):
The way to fix is not let rocketbar deal with select event while it is not active. Should be riskless. (I know this is a regression already :/)
[String changes made]: NaN
Attachment #8558995 - Flags: approval-gaia-v2.2?
blocking-b2g: 2.2? → 2.2+
Attachment #8558995 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Issue verified fixed on Flame 3.0 

Tapped Rocketbar then returned to homescreen. Launched Settings and navigated to Languages before opening Language selection menu. Language selection menu appears correctly. Also attempted this with various other apps that have value selectors like Cost Control and Clock.

Leaving verifyme for 2.2 verification

Device: Flame 3.0 Master
Build ID: 20150210010523
Gaia: 0cf517083f7eb5fc269e1236edba50534f65e3cd
Gecko: 2cb22c058add
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Posted video Verify_video .mp4
The problem is verified not happen on latest Flame 2.2 build.

1. Open Racketbar.
2. Back to homescreen.
3. Launched Settings and navigated to Languages.
4. Open Language selection menu.

Actual Result:
4.Language selection menu appears correctly.

Fail rate:0/5
See attachment:Verify_video.MP4

Flame 2.2 version:
Build ID               20150211002505
Gaia Revision          943be6fd146017dcd9d4c9d1027be1e43bad13eb
Gaia Date              2015-02-11 08:01:09
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/e614443583e7
Gecko Version          37.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150211.040242
Firmware Date          Wed Feb 11 04:02:53 EST 2015
Bootloader             L1TC000118D0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.