4.67 MB, video/mp4
212.49 KB, text/plain
46 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
2.48 MB, video/mp4
Say you have a hidden-SSID WiFi network which has no password or security. Usually to connect to this network you have enter the SSID name manually and say that it is open. This works fine when done from the Gaia Settings app. However, during the FTU if you try to do this, the screen where you enter the hidden SSID will not let you hit "OK" unless there is a password in the password field.
This makes a poor impression when first setting up the device.
blocking-b2g: --- → 1.3?
status-b2g-v1.3: --- → affected
Does this reproduce on 1.1?
Feature was introduced in 1.2, so comment 2 does not apply
QA Wanted to check the behavior on 1.2.
This issue reproduces on the 01/30/14 1.2 build. Environmental Variables: Device: Buri v1.2 MOZ RIL BuildID: 20140130004002 Gaia: 539a25e1887b902b8b25038c547048e691bd97f6 Gecko: f9f469d5d1e1 Version: 26.0 Firmware Version: V1.2-device.cfg
status-b2g-v1.2: --- → affected
Not a regression, so not blocking.
blocking-b2g: 1.3? → -
Whiteboard: [systemsfe][priority] → [systemsfe], [priority]
The code for hidden-network handling in the FTU appears to be a complete disaster. I fixed up a bunch of stuff  but it still fails to actually connect to the network. Somebody please steal my patch and finish it off.  https://github.com/staktrace/gaia/commit/862debb00c43a4a235e353bea2b02d62850aff9f
Thanks for taking a stab at this Kat
Can we re-test this for master/2.2 now that bug 1120267 has landed?
(In reply to Sam Foster [:sfoster] from comment #10) > Can we re-test this for master/2.2 now that bug 1120267 has landed? Hi Sam, This problem is verified fail on latest build of Flame2.2 Repro STR: Precondition: have a hidden-SSID WiFi network which has no password or security 1.Flash build or enter FTU from Settings app. 2.Tap “Join hidden network” button on “Select a network” view. 3.Input hidden-SSID name and set the “Security” to “None” ** But the “Join” button is unavailable; I have to input a password. 4.Input a incorrect password and tap “Join” button. ** It can connect to the hidden-SSID wifi successfully. See attachments: logcat_1114.txt & Flame2.2_verify_video.MP4 Repro time: 11:14 Rate: 5/5 Flame 2.2 build: Gaia-Rev f5b3d1b6cfa3e702033f613915ae637cb735cbfb Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5d7497ce4cc7 Build-ID 20150120002507 Version 37.0a2 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20150120.035540 FW-Date Tue Jan 20 03:55:51 EST 2015 Bootloader L1TC000118D0
Fernando, while you are on your stealth network, would you be able to look at this one too?
Flags: needinfo?(sfoster) → needinfo?(fernando.campo)
yep, taking a look too
Assignee: nobody → fernando.campo
Issue DOES reproduce on Flame 3.0 Master When connecting in FTU to a hidden network with no set password Flame 3.0 Master, the user cannot connect without entering an incorrect password even with security set to "none". Device: Flame 3.0 Master Build ID: 20150123010227 Gaia: cba2f0bf49b882e0044c3cc583de8fcf83d2ffa4 Gecko: 494632b9afed 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?]
status-b2g-master: --- → affected
QA Contact: mvaughan → bzumwalt
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
update: got a patch ready, but I'm having some problems with the tests at the moment (decided to use the occasion to fix what we had, and got carried away a little).
Created attachment 8556535 [details] [review] Link to patch - https://github.com/mozilla-b2g/gaia/pull/27709 Basically adding a ssid-not-empty condition when joining a hidden network, plus a few checks to show/hide or enable/disable DOM elements depending on security type and password content. Includes unit tests. There's also a few changes not directly related to the bug, but I felt like fixing a few things on the code using the occasion.
Comment on attachment 8556535 [details] [review] Link to patch - https://github.com/mozilla-b2g/gaia/pull/27709 Some comments in the PR. The main thing I'm worried about is its unclear when WifiManager.networks gets populated and what the behavior will be until it is. It seems like that changes further in this patch and although you've added a bunch more tests to nail it down, its pretty opaque still. I'm cancelling review for now, but I'm open to being convinced that this patch doesnt make things worse and is a step along the road to better network discovery handling :)
(In reply to Sam Foster [:sfoster] from comment #19) > Comment on attachment 8556535 [details] [review] > Link to patch - https://github.com/mozilla-b2g/gaia/pull/27709 > > Some comments in the PR. The main thing I'm worried about is its unclear > when WifiManager.networks gets populated and what the behavior will be until > it is. It seems like that changes further in this patch and although you've > added a bunch more tests to nail it down, its pretty opaque still. I'm > cancelling review for now, but I'm open to being convinced that this patch > doesnt make things worse and is a step along the road to better network > discovery handling :) I was writing a defense of the new async getNetwork, but I actually changed my mind in the middle of it, as I can't think of a situation where a user is able to choose a network on the screen but the network list is empty... All the problems that this patch fixes can also be solved while keeping the function sync, still using this.networks. Only small changes are required to avoid problems with 'undefined' or null responses.
Comment on attachment 8556535 [details] [review] Link to patch - https://github.com/mozilla-b2g/gaia/pull/27709 rebased and updated, going back to existing list of networks instead of async but checking for possible empty values.
Comment on attachment 8556535 [details] [review] Link to patch - https://github.com/mozilla-b2g/gaia/pull/27709 Looks good. Thanks - this looks like a lot of work. The test run shows a few unit test failures though, can you get those green before landing?
Attachment #8556535 - Flags: review?(sfoster) → review+
nits addressed, re-run and green :) thanks for quick review sam
Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/0b60a385277a5f0af3e76c953439b85f01d5ffba
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Created attachment 8612751 [details] 0430.mp4 This bug has been verified as pass on latest build of Flame v3.0 and Nexus5 v3.0 by the STR in Comment 11. Actual results: In FTU,after user inputted hidden-SSID name and set the"Security"to"None",the"Join"button becomes available.Then tap"Join"button, it can connect to the hidden-SSID wifi successfully. See attachment: 0430.mp4 Reproduce rate: 0/6 Device: Flame 3.0 build(Pass) Build ID 20150528160205 Gaia Revision e7d268074ee3c9eeb191c2205c0e35992fb3915d Gaia Date 2015-05-28 10:47:28 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/f986e55c4e0b Gecko Version 41.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.cltbld.20150528.192335 Firmware Date Thu May 28 19:23:44 EDT 2015 Bootloader L1TC000118D0 Device: Nexus5 3.0 build(Pass) Build ID 20150528160205 Gaia Revision e7d268074ee3c9eeb191c2205c0e35992fb3915d Gaia Date 2015-05-28 10:47:28 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/f986e55c4e0b Gecko Version 41.0a1 Device Name hammerhead Firmware(Release) 5.1 Firmware(Incremental) eng.cltbld.20150528.191717 Firmware Date Thu May 28 19:17:35 EDT 2015 Bootloader HHZ12f
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+] [MGSEI-Triage+]
status-b2g-master: affected → verified
You need to log in before you can comment on or make changes to this bug.