Closed Bug 1133665 Opened 10 years ago Closed 9 years ago

[Flame][Wifi] The SSID that has set to be binded with MAC address is not hightlighted when user taps it.


(Firefox OS Graveyard :: Wifi, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:2.2+, firefox37 wontfix, firefox38 wontfix, firefox39 fixed, b2g-v2.1 unaffected, b2g-v2.2 fixed, b2g-master fixed)

2.2 S9 (3apr)
blocking-b2g 2.2+
Tracking Status
firefox37 --- wontfix
firefox38 --- wontfix
firefox39 --- fixed
b2g-v2.1 --- unaffected
b2g-v2.2 --- fixed
b2g-master --- fixed


(Reporter: fan.luo, Assigned: vchang)




(5 files, 1 obsolete file)

Attached video video.mp4
[Flame][v2.2 & v3.0][Wifi]There is no hightlight or other response when the user taps SSID which has set to bind with MAC address and failed to connect before.
Found time:05:17
Attachment:logcat_0517 & video.mp4

[2.Testing Steps]: 
Prerequisites: Connection failed before.
1. Turn on wifi.
2. Try to connect an ap with MAC address bound.

[3.Expected Result]: 
2. Tap SSID, then it will be marked as highlight.

[4.Actual Result]: 
2. There is no hightlight or other response when the user taps a SSID.

[5.Reproduction build]: 
Flame 2.2 version:
Build ID               20150216002503
Gaia Revision          ea64caf6d4ab03fc4472eca9f41f20d651d55fa9
Gaia Date              2015-02-13 05:27:43
Gecko Revision
Gecko Version          37.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150216.040540
Firmware Date          Mon Feb 16 04:05:52 EST 2015
Bootloader             L1TC000118D0

FLame 3.0  version:
Build ID               20150216010344
Gaia Revision          f0b93e0668ef9565bd6f050b15b4f794d59feb65
Gaia Date              2015-02-13 13:13:27
Gecko Revision
Gecko Version          38.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150216.050451
Firmware Date          Mon Feb 16 05:05:02 EST 2015
Bootloader             L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,10/10

Free Test
Attached file logcat_0517.txt
Hi Norry, Could you also check v2.1, thank you.
Hi Eric, This issue can't reproduce on Flame 2.1
Set 2.2? for regression and ux not consistent.
blocking-b2g: --- → 2.2?
so this bug is for UX instead of "can not connect" right? If so, can we have a pic or video what 2.1 looks like? thank you.
Flags: needinfo?(fan.luo)
Attached video compare.mp4
Hi howie,
I update a compare video,left one is Flame 2.1 and right one is Flame 2.2
For Flame 2.1 you can see device will show highlight and 'connecting...' status to inform user device try to connect ap. but on 2.2 there is no hightlight or other response.

see compare.mp4

Flame 2.1 version:
Build ID               20150308001818
Gaia Revision          ea97a87048a4c1e2a479bbea1d75e0a182b2c4c9
Gaia Date              2015-03-05 16:30:05
Gecko Revision
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150308.045836
Firmware Date          Sun Mar  8 04:58:47 EDT 2015
Bootloader             L1TC000118D0

Flame 2.2 version:
Build ID               20150308002503
Gaia Revision          166491b92278dc9e648f8d49ab02d9ca00d74421
Gaia Date              2015-03-06 18:26:27
Gecko Revision
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150308.052515
Firmware Date          Sun Mar  8 05:25:25 EDT 2015
Bootloader             L1TC000118D0
Flags: needinfo?(fan.luo)
I can help to check this bug from Gaia side.
Assignee: nobody → ejchen
QA Whiteboard: [COM=Gaia::Settings]
Triage: regression, blocking
blocking-b2g: 2.2? → 2.2+
Attached image log_from_inspector.png (obsolete) —
Hi Vincent,

I just checked the inspector and noticed that at first, all networks objects are right when calling wifiManager.getNetworks() at first (with all needed info like ssid, security ...).

But after a while, if users are trying to connect to this kind of AP (AP has a blacklist that would block the SSID of phone and prevent it to connect), when `wifiManager.onstatuschange` is triggered, the passing event is wrong without `security` information, and this would make us unable to map to the right item and make this bug happen.

Can you check the screenshot and see what's going on in such situation from Gecko side ? Thanks !
Flags: needinfo?(vchang)
Attached image log_from_inspector2.png
I added some hints on the screenshot to make it more understandable :)
Attachment #8575738 - Attachment is obsolete: true
Okay, I think this bug should be Gecko's instead of Gaia's.

I verified this assumption by myself if I forcedly change the key from `TPE_QA` to `TPE_QA+WPA-PSK` from source code, the highlight would be back with `connecting ...` wordings on the item and disconnect by itself within few seconds like what we saw in v2.1.

Thanks all, hope this information helps !
Hi Dimi, Vincent is taking leave. Can you please take a look?
Flags: needinfo?(dlee)
Hi Vincent, can you reassign if needed? thanks.
Assignee: ejchen → vchang
Component: Gaia::Settings → Wifi
Attached patch macFilter.patchSplinter Review
The patch fixes two problems. 
1. Report enough information("SSID" + "secure key") when firing statuschange event. 
2. disable network after 3 times retry failure due to mac filter.
Flags: needinfo?(vchang)
Attachment #8583001 - Flags: review?(hchang)
Comment on attachment 8583001 [details] [diff] [review]

Review of attachment 8583001 [details] [diff] [review]:

It looks good to me. Thanks!
Attachment #8583001 - Flags: review?(hchang) → review+
Flags: needinfo?(dlee)
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S9 (3apr)
Please nominate this patch for b2g37 approval when you get a chance.
Flags: needinfo?(vchang)
Comment on attachment 8583001 [details] [diff] [review]

NOTE: Please see to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: There is no highlight or other response when the user taps a SSID in settings app
Testing completed: manually test on Flame and Nexus 5 devices 
Risk to taking this patch (and alternatives if risky): none 
String or UUID changes made by this patch: none
Flags: needinfo?(vchang)
Attachment #8583001 - Flags: approval-mozilla-b2g37?
Attachment #8583001 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Hi Sunny,

Could you help to verify this bug? thanks.
Flags: needinfo?(wangxiaomei)
Keywords: verifyme
See Also: → 1162455
This bug still exist on Nexus5 v2.2 & v3.0 and Flame v2.2 & v3.0. So we clone bug 1162455 to track this issue.
Flags: needinfo?(wangxiaomei)
Removing verifyme keyword based on comment 22.
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.