Closed Bug 1133665 Opened 7 years ago Closed 6 years ago
[Flame][Wifi] The SSID that has set to be binded with MAC address is not hightlighted when user taps it
1.94 MB, video/mp4
260.33 KB, text/plain
5.65 MB, video/mp4
392.54 KB, image/png
2.55 KB, patch
|Details | Diff | Splinter Review|
[1.Description]: [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 https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/62c80c92b39e 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 https://hg.mozilla.org/mozilla-central/rev/e0cb32a0b1aa 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 [7.TCID]: Free Test
Hi Norry, Could you also check v2.1, thank you.
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.
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 https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/0443f2e951dc 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 https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/a48af0b5a6e4 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
I can help to check this bug from Gaia side.
Assignee: nobody → ejchen
Triage: regression, blocking
blocking-b2g: 2.2? → 2.2+
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 !
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?
Hi Vincent, can you reassign if needed? thanks.
Assignee: ejchen → vchang
Component: Gaia::Settings → Wifi
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.
Attachment #8583001 - Flags: review?(hchang)
Comment on attachment 8583001 [details] [diff] [review] macFilter.patch Review of attachment 8583001 [details] [diff] [review]: ----------------------------------------------------------------- It looks good to me. Thanks!
Attachment #8583001 - Flags: review?(hchang) → review+
Please nominate this patch for b2g37 approval when you get a chance.
Comment on attachment 8583001 [details] [diff] [review] macFilter.patch NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing 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
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.
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.
You need to log in before you can comment on or make changes to this bug.