Closed Bug 988316 Opened 6 years ago Closed 6 years ago
Enabling airplane mode while wifi is obtaining IP address does not work as expected
Enabling airplane mode while wifi is "Obtaining IP address" causes the airplane mode toggle button to get stuck on enabled. After this when tapping on the toggle button we cannot disable it. Even though airplane mode appears to be enabled the icon is missing from the status bar. Tapping on WiFi we can see it as disabled, but it also appears to be Connected to the network. This issue is reproduced on both master and v1.4. STR: 1. launch Settings app 2. try to connect a WiFi 3. when WiFi description is "obtaining an IP address", enable "Airplane mode" Expected result: Airplane mode icon appears on the status bar Actual result: The icon does not appear and it is not possible to disable airplane mode We can reproduce the issue manually on both master and v1.4 Screenshots and logcat are attached. Buri master build: Gaia 3286e2a0cbcac52e38c0494ab614bac23cdc229f Gecko https://hg.mozilla.org/mozilla-central/rev/fa098f9fe89c BuildID 20140324160202 Version 31.0a1 ro.build.version.incremental=eng.archermind.20131114.105818 ro.build.date=Thu Nov 14 10:58:33 CST 2013 Hamachi v1.4 build: Gaia 7e705dd4718d528974d99ac31866318d7e201152 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/4889124accfa BuildID 20140326000201 Version 30.0a2 ro.build.version.incremental=eng.tclxa.20131223.163538 ro.build.date=Mon Dec 23 16:36:04 CST 2013
Can we check what happens on 1.3?
I was able to reproduce this issue on the latest Buri 1.3 build. 1.3 Environmental Variables: Device: Buri BuildID: 20140326004002 Gaia: 812838ad0fabf51fa14435af562ddac6d26fa936 Gecko: ba97efb0da4b Version: 28.0 Base Image: V1.2-device.cfg
QA Contact: jzimbrick
Does this reproduce on 1.1?
I have been unable to reproduce this issue on the latest Buri 1.1 and 1.2 builds. 1.1 Environmental Variables: Device: Buri BuildID: 20140326041202 Gaia: 44a2ddf63373f8e95c784faf4ed4d60081699c61 Gecko: 24ed63715d1b Version: 18.0 Base Image: V1.2-device.cfg 1.2 Environmental Variables: Device: Buri BuildID: 20140325164002 Gaia: 539a25e1887b902b8b25038c547048e691bd97f6 Gecko: 41acea9beff3 Version: 26.0 Base Image: V1.2-device.cfg Removing qawanted and adding regression tags.
Is it possible to workaround or recover from this problem to get airplane mode working again?
Yes, restarting the device seems to be the best way to get around this issue. On restarting, the user should be able to toggle Airplane mode off and on again. Tested with the following build: 1.4 Environmental Variables: Device: Buri BuildID: 20140326000201 Gaia: 7e705dd4718d528974d99ac31866318d7e201152 Gecko: 4889124accfa Version: 30.0a2 Base Image: V1.2-device.cfg
This feels like something that's a strong edge case & possible to workaround, so I don't think I can make an argument to block here. However - I'd like to know if something changed in the automated test to cause this to start appearing. We should investigate what changed recently in the relevant automated test.
We did not change anything in how our test work. Could bug 988979 be the issue that is causing this to fail?
(In reply to [:AndreiH] from comment #10) > We did not change anything in how our test work. > Could bug 988979 be the issue that is causing this to fail? It would be worth retesting this after that bug gets implemented.
I can see the same behaviour on v1.3, but after 4-5 seconds of waiting the airplane mode does switch on, and wifi and geolocation does switch off.
(In reply to [:AndreiH] from comment #12) > I can see the same behaviour on v1.3, but after 4-5 seconds of waiting the > airplane mode does switch on, > and wifi and geolocation does switch off. Hamachi device, build: Gaia c5cd3a11e91339163b351d50769eaca0067da860 Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/c6c7b01cdb8e BuildID 20140403004001 Version 28.0
While this isn't a blocking issue, this is causing us problems to automate testing of airplane mode on device. Tim - Can you find someone to look into this to help us get our airplane mode on device automation back online?
EJ, please work on this bug on your non-blocking capacity.
Flags: needinfo?(timdream) → needinfo?(ejchen)
OK, I would take a look at this bug first.
Assignee: nobody → ejchen
(In reply to Robert Chira [:RobertC] from comment #0) > STR: > 1. launch Settings app > 2. try to connect a WiFi > 3. when WiFi description is "obtaining an IP address", enable "Airplane mode" Robert, because the time difference between seeing "obtaining an IP address" and "to enable airplane mode" is very short (For me, less than 1s I think). Can you tell me more about how you reproduce this bug ? Did you press the AP first and when you see "obtaining an IP address", you quickly went back to root panel and pressed the airplaneMode toggle ? Or did you press the AP first and when you see "obtaining an IP address", you quickly dragged down the utility tray and pressed the airplaneMode button ? More details can be helpful ! Thanks :D
I can't reproduce this with the manual STR form comment #1 Gaia 650e8c2c611ed07495d3bf3769f44a0efd88a492 Gecko https://hg.mozilla.org/mozilla-central/rev/5811efc11011 BuildID 20140408160203 Version 31.0a1 ro.build.version.incremental=324 ro.build.date=Thu Dec 19 14:04:55 CST 2013 We can still see the same issue when we run the automated test. Something goes wrong there and the phone is stuck in the same state as before.
(In reply to Florin Strugariu [:Bebe] from comment #19) > We can still see the same issue when we run the automated test. > Something goes wrong there and the phone is stuck in the same state as > before. Ok, it means I have to test on automated test. Is `automated test` the same with gaia-ui-test ? (Python version : https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/README.md) If so, I think I have to setup the env to test. Would you mind share the filename of the test case so that I can try it on my side ? And one more question, are you guys testing on a real device or b2g desktop ? More information would be helpful, thanks ;)
Yes EJ you can find the python tests at https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests More info on how to setup the test env you can find at: https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/gaia-ui-tests/Gaia_UI_Tests_Run_Tests#Testing_on_Firefox_OS_Devices Keep in mid you will have to edit your credentials file to add the wifi network information. The test you need to run is test_settings_airplane_mode.py https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/gaiatest/tests/functional/settings/test_settings_airplane_mode.py We are running our tests on Hamachi's flashed with the latest builds.
I enhanced the automated test to wait for it to wait for the Settings app to say 'Connected to Mozilla Guest' and then waited a further 30 seconds just to be 100% sure that the WifiManager had finished connecting but it still had this problem. I am now going to try and bypass the atom incase using the Wifi API is having an effect on allowing airplane mode to work.
OK I spent a disproportionate amount of time working on this today but I was focussing on the automated test. but I have managed to replicate it locally but it is difficult and very sensitive to timing. I think it's some kind of race between wifi and airplane mode but I can't be sure. The one way to replicate it 100% is by running the automated test.
Hi all, I found something interesting and let me share here. At first I noticed that the airplaneMode toggle was in transitioning mode and it means that it is waiting some specific events from services managers. And after adding some debug infos in system, I found airplaneMode is waiting wifi related event. At first I think there might be any flaw in airplane_mode.js in system app, but after testing manually on Buri and Inari, they all work well and I can receive these events when toggling airplaneMode. Then, I checked the `adb logcat` when doing `gaiatest`, I noticed that there is no wifi related event coming up ! (system/wifi.js will emit `wifi-enabled` and `wifi-disabled` events) hmmm, it is interesting to me and I start to comment out some setup steps about `wifi` with timeout so that I can did it manually (to connect to wifi) and I saw the wifi related event coming up !! Based on above notes, I am suspecting that there is something wrong (maybe in python because it is not reproducible manually when using mobiles) so that our event emitters in `system/wifi.js` got lost and can't emit related events to inform airplaneMode to exit. If possible, can someone help to comment out some wifi related parts and try to manipulate them manually when running gaiatest ? Want to make sure whether information helps there or not. Big thanks :)
Check this short note if you are in a hurry : In gaiatest, when running the test, callback for `wifiManager.onenabled` (https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/wifi.js#L57) is still there but `wifiManager.ondisabled` (https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/wifi.js#L65) is missing. Because `wifiManager.ondisabled` is missing, that's why wifi.js can't emit `wifi-disabled` to inform airplaneMode do the right thing and this breaks airplanemode. Not sure why this would happen, is there any python guru can check some related code there to dig out why `wifiManager.ondisabled` is missing ? or to loop some Gecko friends ? THanks !! :)
(In reply to EJ Chen [:eragonj][:小龍哥] from comment #25) > Check this short note if you are in a hurry : > > In gaiatest, when running the test, callback for `wifiManager.onenabled` > (https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/wifi.js#L57) > is still there but `wifiManager.ondisabled` > (https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/wifi.js#L65) > is missing. > > Because `wifiManager.ondisabled` is missing, that's why wifi.js can't emit > `wifi-disabled` to inform airplaneMode do the right thing and this breaks > airplanemode. Hi all, I may find the root cause based on this comment I left ! As my assumption above, someone might override `ondisabled` function somewhere. After doing almost one-day grep, I noticed that there is one place that would override this function here (https://github.com/mozilla-b2g/gaia/blob/master/tests/atoms/gaia_data_layer.js#L249) After commenting out logics inside `disableWifi`, the test passed and airplaneMode did work awesome as usual !! Because I am not familiar with gaiatest (python), can @Zac or @Bebe help to find deeper there about what's going on (or got changed recently) to cause this problem ? Hope this is really the root cause and figure out the problem !! THanks !!
EJ I think we're on the right track, that's some good sleuthing! :) We'll work on it from that angle and see what we can fix.
Assignee: ejchen → zcampbell
Component: Gaia::Settings → Gaia::UI Tests
Guys this might need a bit more testing around all wifi tests, -type=b2g+wifi might do the trick. EJ, thanks, that's some great sleuthing from you. Thanks very much :))
Comment on attachment 8405326 [details] [review] github pr The test that this fix is originally intended for is still falling for me with : https://pastebin.mozilla.org/4784190
Attachment #8405326 - Flags: review?(andrei.hutusoru) → review-
Comment on attachment 8405326 [details] [review] github pr Looks OK Andrei make sure you reset you virtual env
Comment on attachment 8405326 [details] [review] github pr Working as expected!
Attachment #8405326 - Flags: review?(andrei.hutusoru) → review+
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
@Zac, awesome !!!! I am glad we found it ! haha Thanks for your awesome work to fix the bug :)
You need to log in before you can comment on or make changes to this bug.