1009725 - [B2G][Flame][Settings]Wi-Fi toggle button intermittently non-responsive when selected

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Wifi, defect)

Description

[Montoya Clemmons (MClemmons)]

Attachment: Flame Logcat WiFi Toggle Problem

User taps Settings App and selects Wi-Fi while it is disabled. When selecting the toggle button, the Wi-Fi option doesn't react accordingly. User sometimes has to tap several times to get the option changed to enabled. 

Prerequisites:
Wi-Fi is disabled

Repro Steps:
1)Updated Flame to BuildID: 20140513000208
2)Tap Settings App 
3)Tap Wi-Fi
4)Tap toggle button to change selection and observe behavior 

Actual:
Intermittently the Wi-Fi toggle button did not give the user the option to change. User needs to press up to 11 times with the blue halo light showing a legitimate attempt but the toggle button does not change to enabled. 

Expected:
Wi-Fi toggle button changes after a single user attempt


Repro frequency: 8/10 = 80 percent
See attached: logcat, video clip = https://www.youtube.com/watch?v=Pn_xhmjX2qM

Environmental Variables:
Device: Flame 1.4 MOZ
BuildID: 20140513000208
Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93
Gecko: c140bcd02b9b
Version: 30.0
Base: v10E

Comment 1

[Montoya Clemmons (MClemmons)]

This issue does not reproduce on 1.4 Buri. Following the STR in comment 0, single selection of the Wi-Fi button resulted in expected toggle change for user each time. 

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140513000208
Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93
Gecko: c140bcd02b9b
Version: 30.0
Firmware Version: v1.2-device.cfg

Comment 2

[Montoya Clemmons (MClemmons)]

This issue does not reproduce on 1.3 Buri. Following the STR in comment 0, single selection of the Wi-Fi button resulted in expected toggle change for user each time. 


Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140513024003
Gaia: 26a7a59d219fc8753613b433844123e428adcd56
Gecko: 328611bdebc6
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 3

[Montoya Clemmons (MClemmons)]

This issue reproduces on v1.3 with v10F-3. Following the STR from Comment 0, intermittently the Wi-Fi toggle button did not give the user the option to change.

This issue reproduces on v10F-3 with v1.4. Following the STR from Comment 0, intermittently the Wi-Fi toggle button did not give the user the option to change.

Comment 4

[Jason Smith [:jsmith]]

Does this reproduce on Open C?

Comment 5

[Cody Roesch [:croesch]]

This bug DOES exist on Master build of OpenC.

I'm easily able to get this bug to happen but only after the first tap for ON/OFF. Once i change switch the button once, then the button seems to be greyed out and not responsive for any additional taps for about 8 seconds at which time the on/off selector becomes available again.

Environmental Variables
Device: OpenC Master build v2.0
Build ID: 20140515040207
Gecko: https://hg.mozilla.org/mozilla-central/rev/e4843f4f08a7
Gaia: 3a1d67246a79e3632c3b3f2460a25291e7e2714c
Platform Version: 32.0a1
Firmware Version: P821A10v1.0.0B06_LOG_DL

Comment 6

[Jason Smith [:jsmith]]

Can we check this on Open C 1.3 as well?

Comment 7

[Cody Roesch [:croesch]]

This bug does NOT happen on the OpenC v1.3 base.
I tap to turn Wifi on, then tap to turn wifi off again and see no problems. There is a 3 second delay when the on / off switch is greyed out when turning wifi back ON again during searching but I'm sure that's probably normal.

Environmental Variables
Device: OpenC v1.3 Base
Build ID: 20140505052400
Gecko: /rev/
Gaia: Unknown Git commit; build date shown her
Platform Version: 28.0
Firmware Version: P821A10v1.0.0B06_LOG_D

Comment 8

[Jason Smith [:jsmith]]

The testing results here are confusing. Can we get a summary of differences seen between testing each of the following scenarios again?

* Flame w/1.4
* Open C w/1.4

I would expect the branch & device results to be consistent with each other, but the results above don't align with each other.

Comment 9

[Cody Roesch [:croesch]]

Verified that the bug exists in Flame 1.4 Latest.

Environmental Variables
Device: Flame 1.4
Build ID: 20140520000201
Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/95be84248033
Gaia: 17b102ee8d9a724b62285547cc5f1c5d30bfb01c
Platform Version: 30.0
Firmware Version: v10F-3

Verified that the bug exists in OpenC 1.4 Latest

Environmental Variables
Device: OpenC V1.4
Build ID: 20140520000201
Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/95be84248033
Gaia: 17b102ee8d9a724b62285547cc5f1c5d30bfb01c
Platform Version: 30.0
Firmware Version: v10F-3

Comment 10

[Jason Smith [:jsmith]]

Ok - that makes this bug device independent on 1.4.

Can we do the same comparison again on 1.3?

Comment 11

[Cody Roesch [:croesch]]

This bug does NOT happen on the OpenC v1.3 base.

Environmental Variables
Device: OpenC 1.3 Base
Build ID: 20140505052400
Gecko: /rev/
Gaia: Unknown Git commit; build date shown her
Platform Version: 28.0
Firmware Version: P821A10v1.0.0B06_LOG_DL

------------------------------------------------------

This bug does NOT happen on the 1.3 flame.

Environmental Variables
Device: Flame 1.3
Build ID: 20140520094859
Gecko: b637b0677e15318dcce703f0358b397e09b018af/rev/
Gaia: a73235d23685e9898f40647cebd83b3fcbfd0117
Platform Version: 28.0
Firmware Version: v10G-2

Comment 12

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue occurs on the earliest Flame Build available.

Environmental Variables:
Device: Flame
BuildID: 20140417000006
Gaia: 7591e9dc782ac2e97d63a96f9deb71c7b3588328
Gecko: e71ed4135461
Version: 31.0a1

Comment 13

[Preeti Raghunath(:Preeti)]

Tim

Please review and reassign.

Comment 14

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

I suspect this is a [POVB] issue but EJ can give more feedback.

Comment 15

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #14)
> I suspect this is a [POVB] issue but EJ can give more feedback.

I don't think so - if that was the case, then this would only be present on a single device. The testing above seems to imply it's present across multiple devices (Open C & Flame).

Comment 16

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

(In reply to Jason Smith [:jsmith] from comment #15)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #14)
> > I suspect this is a [POVB] issue but EJ can give more feedback.
> 
> I don't think so - if that was the case, then this would only be present on
> a single device. The testing above seems to imply it's present across
> multiple devices (Open C & Flame).

Maybe PVOB on these two devices ? No idea, because this doesn't happen based on comment #1.

Next week we would get flame devices in Taipei office, so I can check deeper when I get the device.

Comment 17

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Well, is this a bug ?

In settings app, we will block the checkbox which needs hardware to do some heavy actions after user clicking on it. (For example: bluetooth checkbox, wifi checkbox and airplaneMode checkbox)

Back to the topic, the reason why you will get blocked is because we are waiting for events to tell us the operations are done or not, so I think this timing may rely on Gecko or hardware. 

Any ideas ?

Comment 18

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Ni myself to follow this bug.

Comment 19

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

EJ, please verify the Gaia side indeed work correctly based on signals given by the APIs. If the devices takes too long to respond there is nothing we can do about it, but first we need to make sure we are not liable on this one.

Comment 20

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Hi all,

left some notes about my observations here.

1. I tried Flame with 1.3 Gaia, and when you disable the wifi checkbox at the first time, it will jump to disabled mode very fast (what we expected) but when you try to enable and disable again, the same problem occurs ! It will pend there for a while then disabled. 

2. After trying again in master (2.0), I noticed there are still *some chances* that we can get `wifi-disabled` very quickly.

3. No matter I tested on 1.3 or 2.0 Gaia, if I get `wifi-disabled` slowly, I always get some interesting logs from adblog :

---
I/wpa_supplicant( 7899): rmdir[ctrl_interface]: No such file or directory
D/WifiHW  ( 7577): 'DRIVER SCAN-ACTIVE' command timed out.
D/DHCP    ( 7577): failed to set prefixLength 0: Cannot assign requested address
E/GeckoConsole( 7857): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:94 in onWifiDisabled: wifi-disabled (my debug info)
---

From Gaia side, the core logic of this part didn't get changed too much from 1.3, I think it would be better to needinfo some wifi gurus from Gecko :]


Hi @Chucklee,

can you give us some feedbacks from Gecko perspectives ? thanks !!

Comment 22

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

We don't have control on these apps, and these messages are not observed on other platform.
I think partner should handle these error messages.

Vincent and I have done a little profiling yesterday, and suspect it's netutil command takes too much time and blocks upcoming commands. If so, this issue also require partner to resolve.

Comment 23

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

(In reply to Chuck Lee [:chucklee] from comment #22)
> We don't have control on these apps, and these messages are not observed on
> other platform.
> I think partner should handle these error messages.
> 
> Vincent and I have done a little profiling yesterday, and suspect it's
> netutil command takes too much time and blocks upcoming commands. If so,
> this issue also require partner to resolve.

Thanks for the information ! Chucklee !

Comment 25

[Vincent Chang[:vchang][changyihsin]]

Attachment: Patch v1.0

Comment 28

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 8437580 [details] [diff] [review]
Patch v1.0

Review of attachment 8437580 [details] [diff] [review]:
-----------------------------------------------------------------

Determining wifi is enable/disable based on wifi state seems to be a more precise and real-time way than current |WifiManager.enabled|.
Maybe we don't need to use |WifiManager.enabled| anymore, just |WifiManager.isWifiEnabled| is enough.
Can you test that? Thanks!

Comment 29

[Vincent Chang[:vchang][changyihsin]]

Attachment: Patch v1.1

Address the review comments.

Comment 30

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 8438282 [details] [diff] [review]
Patch v1.1

Review of attachment 8438282 [details] [diff] [review]:
-----------------------------------------------------------------

Look good, Thank you!

Also, Since we put check on nearly all API implementation, maybe we can move them to |WifiWorker.receiveMessage()| and do the check there [1], like

> if (aMessage.name != "WifiManager:getState") {
>   if (!WifiManager.enabled) {
>     this._sendMessage(aMessage.name + ":Return", false, "Wifi is disabled", msg);
>     return;
>   }
>   this._domRequest.push({name: aMessage.name, msg:msg});
> }

[1] http://dxr.mozilla.org/mozilla-central/source/dom/wifi/WifiWorker.js#2690

Comment 31

[Vincent Chang[:vchang][changyihsin]]

(In reply to Chuck Lee [:chucklee] from comment #30)
> Comment on attachment 8438282 [details] [diff] [review]
> Patch v1.1
> 
> Review of attachment 8438282 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Look good, Thank you!
> 
> Also, Since we put check on nearly all API implementation, maybe we can move
> them to |WifiWorker.receiveMessage()| and do the check there [1], like
> 
> > if (aMessage.name != "WifiManager:getState") {
> >   if (!WifiManager.enabled) {
> >     this._sendMessage(aMessage.name + ":Return", false, "Wifi is disabled", msg);
> >     return;
> >   }
> >   this._domRequest.push({name: aMessage.name, msg:msg});
> > }
> 
> [1] http://dxr.mozilla.org/mozilla-central/source/dom/wifi/WifiWorker.js#2690

Instead of using settings APIs to turn on/off wifi, we plan to have more APIs such as wifi.enabled or wifitethering.enabled to turn on/off wifi. So let's keep the current patch.

Comment 32

[Vincent Chang[:vchang][changyihsin]]

https://hg.mozilla.org/integration/b2g-inbound/rev/0ea2be7a142d

Comment 33

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0ea2be7a142d

Comment 34

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/18e2630727d4
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/d001f9f42d0d

The 1.4 patch had to be rebased around bug 917102 a bit. Please take a look to be sure nothing was missed.

Comment 35

[Coler]

This issue has been verified successfully on Flame2.0&2.1.
Reproducing rate: 0/5
See attachment: Verify_Flame_Wifi.mp4

Flame2.0 build version:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141130000204
Version         32.0

Flame2.1 build version:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141130001203
Version         34.0

Comment 36

[Coler]

Attachment: Verify_Flame_Wifi.MP4