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

Categories

(Firefox OS Graveyard :: Gaia::UI Tests, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: RobertC, Assigned: zcampbell)

References

Details

(Keywords: regression, Whiteboard: [fromAutomation])

Attachments

(4 files)

Attached file logcat.txt
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
Attached image 2014-03-26-16-04-44.png
Attached image 2014-03-26-16-04-54.png
Blocks: 987145
Can we check what happens on 1.3?
Keywords: qawanted
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
Keywords: qawanted
QA Contact: jzimbrick
Does this reproduce on 1.1?
Keywords: qawanted
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
Keywords: qawanted
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?
Flags: needinfo?(timdream)
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
Flags: needinfo?(ejchen)
Hi all, 

I noticed that there is one special log in our log file : 

E/GeckoConsole(  133): [JavaScript Error: "this is undefined" {file: "jar:file:///system/b2g/omni.ja!/components/WifiWorker.js" line: 2427}]

I am not sure whether this is the root cause or not, but based on another similar bug 984945 I got ni?, if we get this error message from Gecko, wifi will break and will make airpalneMode unresponsive. 

After checking the dependent bugs, I noticed that the real fix for this gecko bug (bug 986349) was just landed by Ryan at 2014-04-08 02:19:54 CST and what Robert reported was earlier than this bug got fixed.

Because I can't reproduce this bug on Buri/master, I think that might because current Gecko build has included the patch already.

Any ideas or thoughts are welcome :)
(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
Flags: needinfo?(robert.chira)
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.
Flags: needinfo?(robert.chira)
(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
Attached file github pr
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 :))
Attachment #8405326 - Flags: review?(florin.strugariu)
Attachment #8405326 - Flags: review?(andrei.hutusoru)
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
Attachment #8405326 - Flags: review?(florin.strugariu)
Attachment #8405326 - Flags: review?(andrei.hutusoru)
Attachment #8405326 - Flags: review-
Attachment #8405326 - Flags: review+
Comment on attachment 8405326 [details] [review]
github pr

Working as expected!
Attachment #8405326 - Flags: review?(andrei.hutusoru) → review+
Merged:
https://github.com/mozilla-b2g/gaia/commit/b7ad81ce2852b5fe2cb1c453ac27f771868d96f6
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Duplicate of this bug: 987145
No longer blocks: 987145
@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.