[Rocketbar] Search provider selector doesn't work when in a system dialog

VERIFIED FIXED in Firefox OS v2.2

Status

Firefox OS
Gaia::Search
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: albertopq, Assigned: albertopq)

Tracking

unspecified
2.2 S11 (1may)
x86
Mac OS X

Firefox Tracking Flags

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

Details

(Whiteboard: [systemsfe])

Attachments

(3 attachments)

(Assignee)

Description

3 years ago
STR

1.- Start the phone and skip SIM PIN dialogs
2.- Open SMS
3.- Click on the rocketbar and search something
4.- Click on the search provider selector

Expected:

It works

Actual:

It does nothing

* Note that bug 1150025 is tracking if the dialog should be closed when opening the rocketbar.
(Assignee)

Updated

3 years ago
No longer depends on: 1150025
Whiteboard: [systemsfs] → [systemsfe]
Component: Gaia::System::Input Mgmt → Gaia::Search
Dale, any idea whats going on here?
Flags: needinfo?(dale)
Naoki, can we get a video here please?
Flags: needinfo?(nhirata.bugzilla)
Created attachment 8590397 [details]
logcat.txt

After the first tap of the keyboard dismissing, the mozChromEvent goes to the System DialogManager... and goes poof.  The logcat of the whole steps is in the attachment.  This is with the specific tap:

D/wpa_supplicant(  978): wlan0: Control interface command 'SIGNAL_POLL'
D/wpa_supplicant(  978): nl80211: survey data missing!
I/GeckoDump(  210): [system] [HierarchyManager][65383.358] mozChromeEvent
I/GeckoDump(  210): [system] [HierarchyManager][65383.420] mozChromeEvent
I/GeckoDump(  210): [system] [HierarchyManager][65383.456] mozChromeEvent
I/GeckoDump(  210): [system] [HierarchyManager][65383.457] handover mozChromeEvent to SystemDialogManager
V/WLAN_PSA(  217): NL MSG, len[048], NL type[0x11] WNI type[0x5050] len[028]
I/GeckoDump(  210): [system] [HierarchyManager][65387.099] mozChromeEvent
I/GeckoDump(  210): [system] [HierarchyManager][65387.117] mozChromeEvent
I/GeckoDump(  210): [system] [HierarchyManager][65387.150] mozChromeEvent
I/GeckoDump(  210): [system] [HierarchyManager][65387.159] handover mozChromeEvent to SystemDialogManager

Video capture : https://www.youtube.com/edit?o=U&video_id=Sffp0wJkofs
Flags: needinfo?(nhirata.bugzilla)
The behavior changed in MC due to bug 1150834; I found a fall out from the fix in bug 1150834
The change in behavior is that if you tap the search provide selector and then tap a link, you'll notice that it does switch to the search providor overlay before switching to the SIM PIN link.

At the same time, I am not sure why we invoke the SIM PIN link when we could easily go through wifi to get these selections...
Just as a follow up, filed bug 1152956 and bug 1152938; I think this might be more windows management?
Sorry I tried finding a sim with a pin enabled and havent been able to, I could go out and buy another sim but if someone else who has one on hand could check this out it would be handy, Alberto is there any chance you can you take a look? apologies
Flags: needinfo?(dale)
Flags: needinfo?(apastor)
Flags: needinfo?(anygregor)
(Assignee)

Updated

3 years ago
Assignee: nobody → apastor
Flags: needinfo?(apastor)
(Assignee)

Comment 8

3 years ago
It seems that, when the system dialog is active, we are receiving the mozChromeEvent 'inputmethod-contextchange' (detail.type = select-one) in the system_dialog_manager [1], when clicking on the value selector of the search app. So the value_selector trying to be shown is the one inside the #simlock-dialog.

Alive, any idea who should we talk with to make sure the mozChromeEvent is received by the clicked target? Thanks!

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/system_dialog_manager.js#L108
Flags: needinfo?(alive)
The fix is pretty simple!
It's HierarchyManager decides who to recieve the focus event,
so we just need to switch to position of Rocketbar and SystemDialog here:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/hierarchy_manager.js#L69

and see if any bad things happens.
Flags: needinfo?(alive)
Created attachment 8593443 [details] [review]
[gaia] albertopq:1150037-search-provider > mozilla-b2g:master
Pretty bad behavior. Lets try to get this uplifted if it happens on 2.2 as well.
Flags: needinfo?(anygregor)
(Assignee)

Updated

3 years ago
Attachment #8593443 - Flags: review?(alive)
Attachment #8593443 - Flags: review?(alive) → review+
It happens on 2.2. nom a blocker.
blocking-b2g: --- → 2.2?
(Assignee)

Updated

3 years ago
Keywords: checkin-needed

Updated

3 years ago
Keywords: checkin-needed
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
(Assignee)

Comment 15

3 years ago
master: https://github.com/mozilla-b2g/gaia/commit/f45f85bd40f65dbc5deb2aa5b4e3373f7a60395e
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
blocking-b2g: 2.2? → 2.2+
Alberto, could you help uplift to 2.2?
Flags: needinfo?(apastor)
(Assignee)

Comment 17

3 years ago
Comment on attachment 8593443 [details] [review]
[gaia] albertopq:1150037-search-provider > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Hierarchy manager
[User impact] if declined: Value selectors not working when a system dialog is in the screen 
[Testing completed]: manual testing
[Risk to taking this patch] (and alternatives if risky): one liner with low risk.
[String changes made]: -
Flags: needinfo?(apastor)
Attachment #8593443 - Flags: approval-gaia-v2.2?(bbajaj)
This issue is verified fixed on Flame Master.

Result: The search engine selector is accessible properly when the rocketbar is launched from the SIM PIN dialog.

Environmental Variables:
Device: Flame 3.0 (KK, 319mb, full flash)
Build ID: 20150421010201
Gaia: a8e4f95dce9db727dda5d408b038f97fb4296557
Gecko: 7b823253d9f2
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

=================================
Leaving verifyme keyword for 2.2 uplift & verification.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-master: --- → verified
Flags: needinfo?(ktucker)
Keywords: verifyme
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: needinfo?(hcheng)
Could you please help approve the uplift request? ;)
Flags: needinfo?(bbajaj)

Updated

3 years ago
Flags: needinfo?(bbajaj)
Attachment #8593443 - Flags: approval-gaia-v2.2?(bbajaj) → approval-gaia-v2.2+
v2.2: https://github.com/mozilla-b2g/gaia/commit/b69336360f54956e9560c60eadc3b1ae990f8550
status-b2g-v2.2: --- → fixed
Target Milestone: --- → 2.2 S11 (1may)
According to the STR of Comment 0,this bug has been successfully verified on latest Nightly Flame v2.2.

Result: The search engine selector is accessible properly when the rocketbar is launched from the SIM PIN dialog.

See attachment: verified_v2.2.mp4
Reproduce rate: 0/5

Device: Flame 2.2 build(Pass)
Build ID               20150426002504
Gaia Revision          265ca0bc9408c21fc4b25a259fcee7fb642cd06b
Gaia Date              2015-04-24 19:13:28
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/1908685d798d
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150426.043030
Firmware Date          Sun Apr 26 04:30:42 EDT 2015
Bootloader             L1TC000118D0
status-b2g-v2.2: fixed → verified
Keywords: verifyme
Flags: needinfo?(hcheng)
You need to log in before you can comment on or make changes to this bug.