1217717 - Turn off airplane mode from settings, the wifi will be toggled on/off alternately

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect, P2)

Description

[Shine(Leave from Mozilla)]

Attachment: AriesKK_v2.5.3gp

[1.Description]:
[AriesKK v2.5][Flame v2.2]Connect an ap and then enable airplane mode, then kill settings process and then disable airplane mode, and the wifi will auto-turn off/on alternately.
See attachment: AriesKK_v2.5.3gp & logcat.txt
Found time: 14:17

[2.Testing Steps]: 
Precondition: connect a wifi ap
1. Enable airplane mode
2. Long tap home button and then kill the settings process
3. Disable airplane mode from settings.
4. Launch settings-->tap wifi

[3.Expected Result]: 
4. Wifi turns on and connects an ap automatically

[4.Actual Result]: 
4. Wifi will be auto-turned on / off alternately

[5.Reproduction build]: 
Device: Aries KK 2.5 (Affected)
Build ID               20151023005002
Gaia Revision          29ce8ec8606e59f582375234440812b046346513
Gaia Date              2015-10-22 05:31:38
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1f03a14106e59280761ac53904340f389674337f
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151023.001128
Firmware Date          Fri Oct 23 00:11:35 UTC 2015
Bootloader             s1

Device: Flame KK 2.2 build (Affected)
Build ID               20151022033039
Gaia Revision          885647d92208fb67574ced44004ab2f29d23cb45
Gaia Date              2015-10-07 13:05:24
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/7bc753230036
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151022.070332
Firmware Date          Thu Oct 22 07:03:43 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Flame KK 2.5 build (Unaffected)
Build ID               20151022150207
Gaia Revision          29ce8ec8606e59f582375234440812b046346513
Gaia Date              2015-10-22 05:31:38
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/76bd0c01d72e64ca4f261ffdb2652a91f961e930
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151022.185000
Firmware Date          Thu Oct 22 18:50:13 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

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

[7.TCID]: 
Free Test

Comment 1

[Shine(Leave from Mozilla)]

Attachment: logcat.txt

Comment 2

[Shine(Leave from Mozilla)]

Hi William,

This bug seems like a blocker, could you help to check? thanks :)

And, please note that: flame 2.2 is *affected*, flame 2.5 is *unaffected*, AriesKK v2.5 is *affected* .

Comment 3

[William Hsu [:whsu]]

[Blocking Requested - why for this release]:

(In reply to Shine from comment #2)
> Hi William,
> 
> This bug seems like a blocker, could you help to check? thanks :)
> 
> And, please note that: flame 2.2 is *affected*, flame 2.5 is *unaffected*,
> AriesKK v2.5 is *affected* .

You were using different Gecko versions to do the test.
So, I am not sure if it truly cannot be reproduced on Flame 2.5.

But, I think we should nominate this bug because it brings bad user experience.
Thank you.

Comment 4

[Mahendra Potharaju [:mahe]]

Blocks 2.5. 

QA Wanted, Can you please reproduce this and give detailed STR and devices affected

Comment 5

[John Thomas [:Johnt]]

I have been unable to reproduce this issue for the Aries Master and the Flame 2.5
Result: After disabling Airplane mode and entering the WiFi tab in settings the Device connects to Wifi successfully and remains on without disabling / re-enabling. 

This may call for a different STR. Leaving qawanted for others to attempt. 

Environmental Variables:
Device: Aries 2.5 Kk
BuildID: 20151028104739
Gaia: 2e89362de40a6c9c36525d36317fa1ae8e67e143
Gecko: fc706d376f0658e560a59c3dd520437b18e8c4a4
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Environmental Variables:
Device: Flame 2.5 Kk Fullflash (512mb)
BuildID: 20151028030421
Gaia: 2e89362de40a6c9c36525d36317fa1ae8e67e143
Gecko: fc706d376f0658e560a59c3dd520437b18e8c4a4
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Comment 6

[zouyi(Leave from Mozilla)]

Attachment: AriesKK_v2.5_repro.3gp

I can 100% repro this bug with below STR, and it exists on flameKK 2.2/2.5 and ariesKK 2.5

STR: 
Precondition: connect an ap
1. Launch settings;
2. Tap airplane mode to enable, and "disabled" will be shown under the wifi option;
3. Long tap home button and kill the setting app;
4. Launch settings again;
5. Before the "disabled" is shown, Tap airplane mode to disable;
**Wifi will be auto-turned on / off alternately

*Note: The key step should be STR5: before the "disabled" is shown,  if you wait for about 10 seconds and then disable airplane mode, the bug will not occur.

See attachment: Arieskk_v2.5_repro.3gp and logcat.txt, in the video, you can see the bug did not happen from 00:00~00:32 with waiting "disabled" appearing; you can see the bug happened from 00:33 to end with not waiting "disabled" appearing.

Device: AriesKK v2.5(Affected);
Build ID               20151029010303
Gaia Revision          75f2236d36cc9f9c02d3596fae3de014007cfd82
Gaia Date              2015-10-28 17:02:16
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/1e700005a0ddf2b17803213e1f3f8d78a7a618b8
Gecko Version          44.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151029.002011
Firmware Date          Thu Oct 29 00:20:19 UTC 2015
Bootloader             s1

Device: FlameKK v2.2(Affected)
Build ID               20151028032502
Gaia Revision          885647d92208fb67574ced44004ab2f29d23cb45
Gaia Date              2015-10-07 13:05:24
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/05144e035522
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151028.072640
Firmware Date          Wed Oct 28 07:26:52 EDT 2015
Bootloader             L1TC000118D0

Device:FlameKK v2.5(Affected)
Build ID               20151028150209
Gaia Revision          2e89362de40a6c9c36525d36317fa1ae8e67e143
Gaia Date              2015-10-28 04:56:28
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/fc706d376f0658e560a59c3dd520437b18e8c4a4
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151028.182746
Firmware Date          Wed Oct 28 18:27:57 EDT 2015
Bootloader             L1TC000118D0

Comment 7

[zouyi(Leave from Mozilla)]

Attachment: logcat.txt

Comment 8

[Ethan Tseng [:ethan]]

Request Tim Huang to help investigate this issue.

Comment 9

[Tim Huang[:timhuang]]

Now, I can successfully reproduce this bug, and I will try to solve it as soon as possible.

Comment 10

[Tim Huang[:timhuang]]

This bug is caused by a mechanism of the settings apps, which tries to sync wifi state with the hardware. It writes “wifi.enabled” whenever gecko reports wifi enable/disable accordingly. This action changes underlying wifi as well, because the gecko listens “wifi.enabled” to enable/disable wifi. So if it involves fast changes of “wifi.enabled”, this problem will be triggered. Following describing this phenomenon in a chronological order:

1. Settings Apps writes “wifi.enabled = true”.
2. Gecko tries to starts wifi but not finish yet.
3. Settings Apps writes “wifi.enabled = false”.
4. Gecko queues this request due to the previous request not finish yet.
5. Gecko finishes enabling wifi, and it reports an event of wifi enabled. Then it tries to handle disabling from moment 3.
6. Settings Apps catches the event of wifi enabled, it writes “wifi.enabled = true”.
7. Gecko queues the request from moment 6, because it still on disabling.
8. Gecko finishes the disabling, and reports an event of wifi disabled. Then it tries to handle enabling from moment 6.
9. Settings Apps catches the event of wifi disable, it writes “wifi.enabled = false”.
10. Gecko queues the request from moment 9, because of it still on enabling.
11. I am tired to keep writing ...

So, it all starts from fast enabling and disabling of “wifi.enabled”. It happens when disabling airplane mode when launching settings apps. If you disable airplane mode fast enough after launching settings apps, faster than settings apps initiates its wifi panel. The “wifi.enabled” will first be set to true since the airplane mode is disabled, then when the wifi panel loads up, its init function will check the hardware status, which shows “disable" since the enabling of wifi does not finish yet, then writes “wifi.enabled” to false. This leads to this problem occurs.

Comment 11

[Ethan Tseng [:ethan]]

(In reply to Tim Huang[:timhuang] from comment #10)
Tim, thanks for finding out the root cause!

Timdream, we need to discuss how to resolve this issue together since the solution might involve changes in the Settings App (we could arrange a discussion offline).

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

We should really move that toggle away from mozSettings and to the API itself. Is it doable for a blocker like this?

Please also loop Fred on this.

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

FYI https://groups.google.com/d/msg/mozilla.dev.webapi/96nlo6RPuiM/4nbsSJLUQiAJ dated Dec 30 2014.

Comment 14

[Henry Chang [:hchang]]

I wonder if it would make it even more buggy since the API hasn't been tested very well in gaia. (although we have marionette-webpai test case against to the new APIs in gecko). Besides, the wifi would also be automatically toggled when switching wifi tethering on/off. It makes it super complicated to migrate from mozSettings to API when it comes to wifi. 

That being said, I really hope the API to be used one day so we might make it happen iteratively as the following:

1) Start the migration off from other toggles like BT/NFC. It would still be complicated considering the airplane mode but at least no implicit toggle would happen to gaia (unlike wifi). I imagine we would learn a lot of experience from the very first attempt.

2) Meanwhile, get rid of the assumption that wifi will be automatically switched off when turning on wifi tethering.

3) Enable/disable wifi and wifi tethering by using API. Ideally, it should be able to migrate separately but I have to take it a look to make sure this.

Comment 15

[Henry Chang [:hchang]]

(In reply to Tim Huang[:timhuang] from comment #10)
> This bug is caused by a mechanism of the settings apps, which tries to sync
> wifi state with the hardware. It writes “wifi.enabled” whenever gecko
> reports wifi enable/disable accordingly. This action changes underlying wifi
> as well, because the gecko listens “wifi.enabled” to enable/disable wifi. So
> if it involves fast changes of “wifi.enabled”, this problem will be
> triggered. Following describing this phenomenon in a chronological order:
> 
> 1. Settings Apps writes “wifi.enabled = true”.
> 2. Gecko tries to starts wifi but not finish yet.
> 3. Settings Apps writes “wifi.enabled = false”.
> 4. Gecko queues this request due to the previous request not finish yet.
> 5. Gecko finishes enabling wifi, and it reports an event of wifi enabled.
> Then it tries to handle disabling from moment 3.
> 6. Settings Apps catches the event of wifi enabled, it writes “wifi.enabled
> = true”.
> 7. Gecko queues the request from moment 6, because it still on disabling.
> 8. Gecko finishes the disabling, and reports an event of wifi disabled. Then
> it tries to handle enabling from moment 6.
> 9. Settings Apps catches the event of wifi disable, it writes “wifi.enabled
> = false”.
> 10. Gecko queues the request from moment 9, because of it still on enabling.
> 11. I am tired to keep writing ...
> 
> So, it all starts from fast enabling and disabling of “wifi.enabled”. It
> happens when disabling airplane mode when launching settings apps. If you
> disable airplane mode fast enough after launching settings apps, faster than
> settings apps initiates its wifi panel. The “wifi.enabled” will first be set
> to true since the airplane mode is disabled, then when the wifi panel loads
> up, its init function will check the hardware status, which shows “disable"
> since the enabling of wifi does not finish yet, then writes “wifi.enabled”
> to false. This leads to this problem occurs.







(In reply to Tim Huang[:timhuang] from comment #10)
> This bug is caused by a mechanism of the settings apps, which tries to sync
> wifi state with the hardware. It writes “wifi.enabled” whenever gecko
> reports wifi enable/disable accordingly. This action changes underlying wifi
> as well, because the gecko listens “wifi.enabled” to enable/disable wifi. So
> if it involves fast changes of “wifi.enabled”, this problem will be
> triggered. Following describing this phenomenon in a chronological order:
> 
> 1. Settings Apps writes “wifi.enabled = true”.
> 2. Gecko tries to starts wifi but not finish yet.
> 3. Settings Apps writes “wifi.enabled = false”.
> 4. Gecko queues this request due to the previous request not finish yet.
> 5. Gecko finishes enabling wifi, and it reports an event of wifi enabled.
> Then it tries to handle disabling from moment 3.
> 6. Settings Apps catches the event of wifi enabled, it writes “wifi.enabled
> = true”.

It seems the loop is originated from here. Why the settings app writes "wifi.enabled" to true while it explicitly wrote "wifi.enabled" to false at (3)? I doubt if this could be fixed by using API.

Comment 16

[Tim Huang[:timhuang]]

> It seems the loop is originated from here. Why the settings app writes
> "wifi.enabled" to true while it explicitly wrote "wifi.enabled" to false at
> (3)? I doubt if this could be fixed by using API.

The Settings app writes "wifi.enabled" to true and then false because of the first "true" is wrote in response to the disabling of Airplane mode. And the "false" at (3) is wrote by the init function of the wifi_context of the Settings app.

In my view, this problem is hard to be fixed by only using API, but not change the behavior of Settings apps.

Comment 17

[[e-mail]]

According to comment 10, the issue is related to how our api is working with mozSettings, so its more elegant to solve from api level (with many gaia api callback changes...).

In Settings the airplane mode is able to interact before wifi related code because we lazy loading the wifi panel.
A short term fix could be disable the interaction of Airplane mode switch before the wifi panel is ready.

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Henry Chang [:henry] from comment #14)
> I wonder if it would make it even more buggy since the API hasn't been
> tested very well in gaia. (although we have marionette-webpai test case
> against to the new APIs in gecko). Besides, the wifi would also be
> automatically toggled when switching wifi tethering on/off. It makes it
> super complicated to migrate from mozSettings to API when it comes to wifi. 

Yes, it's not possible to pull the task under release blocker schedule. Fred gave the latest proposed solution in comment 17. 

> 
> That being said, I really hope the API to be used one day so we might make
> it happen iteratively as the following:
> 
> 1) Start the migration off from other toggles like BT/NFC. It would still be
> complicated considering the airplane mode but at least no implicit toggle
> would happen to gaia (unlike wifi). I imagine we would learn a lot of
> experience from the very first attempt.
> 
> 2) Meanwhile, get rid of the assumption that wifi will be automatically
> switched off when turning on wifi tethering.

Agreed, it's perfectly possible that eventually we could have devices that can operates under both mode (like a wifi rely), and our API design should reflect that.

> 3) Enable/disable wifi and wifi tethering by using API. Ideally, it should
> be able to migrate separately but I have to take it a look to make sure this.

That's plan on this off this bug. Glad we are getting some attentions here!

Comment 19

[GitHub Autolander Bot]

Attachment: [gaia] gasolin:issue-1217717 > mozilla-b2g:master

Comment 20

[[e-mail]]

Hi Tim & zouyi,

Thanks for provide detailed STR. I got the gaia patch that disable the Airplane mode interaction before the wifi panel is ready.

I tested it on device and works fine please help test it on your side.

Comment 21

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(Keep a written record here, just FYI)

The code in question that try to "sync" mozSettings state and hardware WIFI state was done in bug 823783 and it's current place is 

https://github.com/mozilla-b2g/gaia/blob/4f99b85d33c6459e150ff83fc23cc83acbf2ae44/apps/settings/js/modules/wifi_context.js#L101-L104

Comment 22

[Tim Huang[:timhuang]]

I had tested the solution which provided by fred. It works perfectly right now. The wifi would not be toggled alternatively after disabling airplane mode.

Comment 23

[Yura Zenevich [:yzen] (please use "needinfo")]

Comment on attachment 8681832 [details] [review]
[gaia] gasolin:issue-1217717 > mozilla-b2g:master

The code changes look good and the patch works as expected. Two comments however:
* It would nice to have a test for the event resulting in enabling of the airplane mode.
* Because this is a work around we need to open a new bug for the actual issue. This work around introduces a new condition where airplane mode can't be enabled until wifi is ready. However, airplane mode affects plenty of other things besides wifi so this dependency is a smell.

Comment 24

[Yura Zenevich [:yzen] (please use "needinfo")]

Also, probably unrelated, but some Gu tests were failing.

Comment 25

[[e-mail]]

added tests for airplane mode item and wifi item. Wait treeherder result.

Tim Huang, could you help identify and file related api level bug?

Comment 27

[[e-mail]]

all green, merged https://github.com/mozilla-b2g/gaia/commit/f17421e9a23b9dbd88c41347f1b9c442a97f48e0

thanks!

Comment 28

[Tim Huang[:timhuang]]

Bug 1221068 had been created as a follow up bug for the wifi api.

Comment 29

[Jessica]

Attachment: verified_Aries KK v2.6.3gp

According to the STR of Comment 0, this bug has been verified as pass on latest Flame KK v2.6 512mb and Aries KK v2.6.

Actual results: Airplane mode can't be enabled until wifi is ready, after airplane mode is off wifi turns on and connects an ap automatically
See attachment: verified_Aries KK v2.6.3gp
Reproduce rate: 0/6


Device: Flame KK v2.6 512mb (master) (Pass)
Build ID               20151103150203
Gaia Revision          61918ddd9ccce104c009e873e34a0791e125753a
Gaia Date              2015-11-03 17:22:30
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/f742b9412ed5aace90ad863b276faae0641090a8
Gecko Version          45.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20151103.182550
Firmware Date          Tue Nov  3 18:26:03 EST 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK v2.6 (master) (Pass)
Build ID               20151104004249
Gaia Revision          61918ddd9ccce104c009e873e34a0791e125753a
Gaia Date              2015-11-03 17:22:30
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/f742b9412ed5aace90ad863b276faae0641090a8
Gecko Version          45.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151104.000116
Firmware Date          Wed Nov  4 00:01:24 UTC 2015
Bootloader             s1

Comment 30

[Ethan Tseng [:ethan]]

Good job! We resolved a 2.5 blocker!
Thanks for everyone's help here. :)

Comment 31

[Jessica]

Attachment: verified_Aries KK v2.5.3gp

According to the STR of Comment 0, this bug has been verified as pass on latest build of Flame KK v2.5 512mb and Aries KK v2.5.

Actual results: Airplane mode can't be enabled until wifi is ready, after airplane mode is off wifi turns on and connects an ap automatically.
See attachment: verified_Aries KK v2.5.3gp
Reproduce rate: 0/6


Device: Flame KK v2.5 512mb (Pass)
Build ID               20151116173604
Gaia Revision          9473dbcbebf4e758a3b73200968efc69071b4312
Gaia Date              2015-11-16 15:49:25
Gecko Revision         http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/17877d161e5f62726027ee70101a7004dcad5a69
Gecko Version          44.0a2
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151116.164743
Firmware Date          Mon Nov 16 16:47:52 UTC 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK v2.5 (Pass)
Build ID               20151116174534
Gaia Revision          9473dbcbebf4e758a3b73200968efc69071b4312
Gaia Date              2015-11-16 15:49:25
Gecko Revision         http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/17877d161e5f62726027ee70101a7004dcad5a69
Gecko Version          44.0a2
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20151116.165317
Firmware Date          Mon Nov 16 16:53:25 UTC 2015
Bootloader             s1