[Tarako]WIFI keeps toggling just like some one keeps on tapping the button

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: zhenqing.liu, Assigned: chucklee)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v1.3T wontfix, b2g-v1.4 wontfix)

Details

(Whiteboard: [sprd335595])

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

4 years ago
STR:
  1. Connect to an AP and then close Wifi.
  2. Restart the phone.
  3. Tap WIFI button in the Notification Bar.
  4. Tap Settings button in the Notification Bar.
  5. Tap Wi-Fi in the settings Dialog.

Sometimes Wifi will keep toggling.
(Reporter)

Updated

4 years ago
Whiteboard: [sprd335595]
(Reporter)

Comment 1

4 years ago
Created attachment 8461373 [details]
log about this bug

It seemed stuck in an on-off loop.

Comment 2

4 years ago
>-------------------------> 1.restart the phone

04-30 00:56:50.100 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/wifi.js:88 in wf_init/<: 1367283410024  mxm_The observer value=false ,wifiManager=[xpconnect wrapped nsIDOMWifiManager]
04-30 00:56:50.490 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/quick_settings.js:103 in qs_init/<: 1367283410464  mxm_The observer value=false

>------------------------->2.then click the wifi icon in quick setting:

04-30 00:56:58.540 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/quick_settings.js:156 in qs_handleEvent: 1367283418530  mxm_The quick set wifi.enabled=true
04-30 00:56:58.670 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/wifi.js:88 in wf_init/<: 1367283418613  mxm_The observer value=true ,wifiManager=[xpconnect wrapped nsIDOMWifiManager]
04-30 00:56:58.670 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/quick_settings.js:103 in qs_init/<: 1367283418629  mxm_The observer value=true

>------------------------->3.click settings icon in quick setting,the connectivity.js will settings.createLock().set({'wifi.enabled': wifiManager.enabled});

04-30 00:57:01.890 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/connectivity.js:41 in Connectivity<: 1367283421775  mxm_The connectivity set wifi.enabled=false
04-30 00:57:02.150 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/wifi.js:88 in wf_init/<: 1367283422115  mxm_The observer value=false ,wifiManager=[xpconnect wrapped nsIDOMWifiManager]
04-30 00:57:02.160 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/quick_settings.js:103 in qs_init/<: 1367283422137  mxm_The observer value=false

>------------------------->4.click Wi-Fi item on the main list of settings:

04-30 00:57:04.620 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/settings.js:897 in settings_sectionOpenClick: 1367283422562  mxm_The settings.js sectionOpenClickapp://settings.gaiamobile.org/index.html#wifi
04-30 00:57:04.620 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/settings.js:51 in transit: 1367283422687  mxm_The _transit

>------------------------->Here response for the STEP 2:enable the wifi

04-30 00:57:05.270 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/connectivity.js:48 in wifiManager.onenabled: mxm_The onenabled
04-30 00:57:05.270 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/connectivity.js:153 in wifiEnabled: mxm_The wifiEnabled
04-30 00:57:05.270 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/connectivity.js:144 in syncWifiEnabled/<: mxm_The syncWifiEnabled enabled=true wifiEnabled=false
04-30 00:57:05.270 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:93 in onWifiEnabled: 1367283425192  mxm_The wifi switch box status is false
04-30 00:57:05.270 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:94 in onWifiEnabled: 1367283425193  mxm_The wifi connection status (get by mozWifiManager.enabled) is true
04-30 00:57:05.280 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:95 in onWifiEnabled: mxm_The wifi switch box status is 'can '
04-30 00:57:05.280 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:78 in wifiSettings/Connectivity.wifiStatusChange: 1367283425201  mxm_The wifiStatusChange event={"isTrusted":false} ,event.status=disconnected
04-30 00:57:05.280 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:78 in wifiSettings/Connectivity.wifiStatusChange: 1367283425206  mxm_The wifiStatusChange event={"isTrusted":false} ,event.status=disconnected
04-30 00:57:05.520 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/wifi.js:88 in wf_init/<: 1367283425495  mxm_The observer value=true ,wifiManager=[xpconnect wrapped nsIDOMWifiManager]
04-30 00:57:05.520 E/GeckoConsole(   85): Content JS LOG at app://system.gaiamobile.org/js/quick_settings.js:103 in qs_init/<: 1367283425510  mxm_The observer value=true
04-30 00:57:05.870 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:1074 in wifiSettings/<: 1367283425549  mxm_The observer event=true

>------------------------->Here disable the wifi

04-30 00:57:06.860 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/connectivity.js:53 in wifiManager.ondisabled: mxm_The ondisabled
04-30 00:57:06.860 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/connectivity.js:161 in wifiDisabled: mxm_The wifiDisabled
04-30 00:57:06.860 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/connectivity.js:144 in syncWifiEnabled/<: mxm_The syncWifiEnabled enabled=false wifiEnabled=true
04-30 00:57:06.860 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:103 in onWifiDisabled: 1367283426726  mxm_The wifi switch box  status is true
04-30 00:57:06.860 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:104 in onWifiDisabled: 1367283426727  mxm_The wifi connection status (get by mozWifiManager.enabled) is false
04-30 00:57:06.860 E/GeckoConsole(  377): Content JS LOG at app://settings.gaiamobile.org/js/wifi.js:105 in onWifiDisabled: mxm_The wifi switch box status is 'can '

>------------------------->Then you'll see the switch of wifi switches between on and off all the time.

Comment 3

4 years ago
Maybe the main cause for the issue is that gaia/gecko/hardware is async.
We found that if we remove |settings.createLock().set({'wifi.enabled': wifiManager.enabled});| in apps/settings/js/connectivity.js ,the issue would disappear.

Hi,etienne
   Could we remove this line in connectivity.js ?Thank you!
Flags: needinfo?(etienne)

Comment 4

4 years ago
Please see comment 2 and comment 3 and find someone to help.This issue could reproduce in a high rate if we add some log in the code.Thank you!
Flags: needinfo?(ehung)

Comment 5

4 years ago
(In reply to yang.zhao from comment #3)
> Maybe the main cause for the issue is that gaia/gecko/hardware is async.
> We found that if we remove |settings.createLock().set({'wifi.enabled':
> wifiManager.enabled});| in apps/settings/js/connectivity.js ,the issue would
> disappear.
> 
> Hi,etienne
>    Could we remove this line in connectivity.js ?Thank you!

No, you can't do that. The whole function will be broken.(In reply to yang.zhao from comment #4)
> Please see comment 2 and comment 3 and find someone to help.This issue could
> reproduce in a high rate if we add some log in the code.Thank you!

What do you mean by "reproduce in a high rate if we add some log in the code"? Is it possible that the response of wifi driver is late so the UI is waiting?
Flags: needinfo?(etienne)
Flags: needinfo?(ehung)

Comment 6

4 years ago
(In reply to Evelyn Hung [:evelyn] from comment #5)
We add some log for debugging, and find that the issue occurs nearly 100% with the log in it.

You could see the log in comment 2.When you turn on wifi from the quick settings,the command of set('wifi.enabled',true) is sent,then you enter settings,but the value of |wifiManager.enabled| is still false at that time,so the command of set('wifi.enabled',false) is sent,but after the command is sent, wifiManager.onenabled function is called,then syncWifiEnabled function is called.In syncWifiEnabled,the enabled=true and wifiEnabled=false,so the command of set('wifi.enabled',true) is sent again.Then the event.status=disconnected is triggered in wifiStatusChange,then wifiManager.ondisabled is called,the call syncWifiEnabled again,here command set('wifi.enabled',false) is sent again.

true->false->true->false.....    so the switcher switches between on and off all the time.
Yes, we should fix this wifi auto switch bug, it will make user confuse.
(Reporter)

Comment 8

4 years ago
(In reply to Evelyn Hung [:evelyn] from comment #5)
> What do you mean by "reproduce in a high rate if we add some log in the
> code"? Is it possible that the response of wifi driver is late so the UI is
> waiting?

I think there is nothing to do with the driver.
From gecko downward just work according to |wifi.enabled|. I add some log in gecko and find gaia keeps dispatching wifi enable and disable command.
I'm not familiar with gaia. But I'm really confused why as an observer it should have the ability to set the value of |wifi.enabled| in |connectivity.js|.
(Reporter)

Updated

4 years ago
Flags: needinfo?(ehung)
(Reporter)

Comment 9

4 years ago
Hi Vincent, could you give a comment on this bug?
Flags: needinfo?(vchang)
I remember :chuck had ever introduced a variable to break certain 
enable/disable cycle. Not sure if it's relevant to this issue.
Flags: needinfo?(chulee)
(Reporter)

Comment 11

4 years ago
I think we should give high attention on this bug because it has become a block issue.
The root cause is settings is used for both controlling behavior and recording user preference. So Gaia uses settings to control wifi, and Gaia also need to value in settings based on received wifi state.
This loop can't be broken in gecko because this might break app behavior, so the loop need to be break in Gaia. Maybe Gaia can try to solve this by disabling UI element until |WifiManager.enabled === settings['wifi.enabled']|.

Also, the STR seems not a common operation for normal user to me, I suggest take this into consideration before deciding this is a blocker or not. And leave all issues of this kind to the final solution, using API instead of settings, as bug 930335.
Flags: needinfo?(chulee)
Clear the NI because Chuck has answered the question in comment 12.
Flags: needinfo?(vchang)

Comment 14

4 years ago
Created attachment 8463754 [details] [diff] [review]
wifi.patch

Comment 15

4 years ago
(In reply to Chuck Lee [:chucklee] from comment #12)
> This loop can't be broken in gecko because this might break app behavior, so
> the loop need to be break in Gaia. Maybe Gaia can try to solve this by
> disabling UI element until |WifiManager.enabled ===
> settings['wifi.enabled']|.

Hi,Chuck
   I use attachment 8463754 [details] [diff] [review] could break the loop in Gaia. But reboot the phone, enable wifi from quick settings,then enter settings,the wifi is still set disabled by this line in connectivity.js:
|settings.createLock().set({'wifi.enabled': wifiManager.enabled});|
   Could you help to afford a better patch? Thank you!
Flags: needinfo?(chulee)
We found 1.4 dolphin also has this bug.
status-b2g-v1.3T: --- → affected
status-b2g-v1.4: --- → affected
Flags: needinfo?(wchang)
Flags: needinfo?(ryang)
I cannot reproduce this on flame 1.3, also given the STR I agree with Chuck on the unlikelihood of users getting here.
Flags: needinfo?(wchang)

Comment 18

4 years ago
(In reply to Wayne Chang [:wchang] from comment #17)
> I cannot reproduce this on flame 1.3, also given the STR I agree with Chuck
> on the unlikelihood of users getting here.
I check it again, and found that on Tarako,you don't need to restart the phone,just kill settings app in card view, it's easy to reproduce.
(Reporter)

Comment 19

4 years ago
(In reply to Wayne Chang [:wchang] from comment #17)
> I cannot reproduce this on flame 1.3, also given the STR I agree with Chuck
> on the unlikelihood of users getting here.

Not reproducing on flame 1.3 doesn't mean the logic is right.
The STR just give a path by which it's easy to reproduce. 
|WifiManager.enabled| is assigned to be |true| on supplicant is connected. So as long as I enter the settings app before supplicant is connected, there will be a potential to reproduce.
(Reporter)

Comment 20

4 years ago
Created attachment 8463875 [details]
Two ways to reproduce this bug.

STR:
1. Force closing settings.
2. Quickly tap Wifi and Settings button in quick-settings.
3. Tap Wi-Fi and the bug appears.
Flags: needinfo?(dflanagan)
Created attachment 8463876 [details] [diff] [review]
Don't sync wifi state into settings while setting app start. (Gaia 1.3t)

I think we only have to stop settings app from syncing wifi state into settings at start up, because 
1. WifiManager.enabled is false while "enabling wifi" and is true while in "diabling wifi". If settings app perform sync at these points, the sync value will be wrong.
2. Currently we are using settings to control wifi enable, so the settings value is already reflecting the enable status of wifi and doesn't need to be sync-ed.
3. An exception for 2. is enabling hotspot mode while wifi is enabled, wifi will be turned off by gecko automatically. But for now, only settings app can change hotspot settings and it will sync settings based on wifi enable/disable event.
Based on 1 ~ 3, the unsync state between settings and wifi real state will only be "user change hotspot mode in settings app then kill settings app right away before it receives wifi state change event", which I think is nearly impossible to happen and easier to recover.
Attachment #8463876 - Flags: feedback?(ejchen)
Flags: needinfo?(chulee)
(Reporter)

Updated

4 years ago
Flags: needinfo?(ehung)

Comment 22

4 years ago
hi,Chuck
  I've tried remove that line in connectivity.js,and find that follow the STR in 
https://bugzilla.mozilla.org/show_bug.cgi?id=823783#c21.Copy here:
1) start settings app, ensure that wifi is enabled and connected to a network
2) force quit settings app
3) open setting app again, and go to hotspot
4) turn hotspot on and off
5) Go to wifi panel. Toggle button shows wifi on, but it is actually off now
6) Tap on wifi toggle button. It goes off and remains disabled forever.

After Step 5:toggle the wifi on,you'll find the toggle button toggles between on and off again!Maybe it's still a sync problem.FYI.
I can't reproduce that.

Syncing problem is caused by using setting to control wifi and lack of status update from current API, especially in hotspot-wifi interaction.
There's no perfect solution for current structure and we can only apply many workarounds to prevent it from being triggered in normal use case.
There are some workarounds in gecko-central/gaia-master which are not uplift to 1.3t, maybe you can compare wifi part in gecko and gaia and uplift these differences.
It seems that tarako takes more time to response wifi up/down event so the enable/disable command can't be break by command optimize mechanism in gecko.
Maybe delay execution of each command by 200ms or so can make it work again.
Comment on attachment 8463876 [details] [diff] [review]
Don't sync wifi state into settings while setting app start. (Gaia 1.3t)

This code did make wifi toggle all the time when there is a pending request already in Gecko.
Attachment #8463876 - Flags: feedback?(ejchen) → feedback+
Attachment #8463876 - Attachment description: Don't sync wifi state into settings while setting app start → Don't sync wifi state into settings while setting app start. (Gaia 1.3t)
Created attachment 8464633 [details] [diff] [review]
Add delay to command queue execution. (Gecko 1.3t, 1.4)

Gaia of tarako takes more time than expected to handle wifi events, and this makes protection mechanism in gecko not functional.
This can be solve by adding a little delay between each queue execution.

This can solve the issue in comment 22, the drawback is wifi won't be enabled automatically after hotspot is disabled.
This drawback also shown on flame, since this has no major affect for user and should be resolved after Gaia adopted to wifi enable API. I think this is acceptable solution.
Attachment #8464633 - Flags: feedback?(vchang)
I'm not sure what info was requested from me. I haven't looked at the wifi code in a long time. When I did I saw that it had serious problems because it was using the settings db to maintain state between gecko, the system app and the settings app and that there were all kinds of potential race conditions. So I'm not suprised that the slower speed of Tarako would cause some bugs to manifest in this code.

It sounds like Chuck has found a workaround, and I suspect that is the best we can do in 1.3T and 1.4.  Eventually we probably need to rewrite all of the wifi code.
Flags: needinfo?(dflanagan)
(In reply to David Flanagan [:djf] from comment #27)
> It sounds like Chuck has found a workaround, and I suspect that is the best
> we can do in 1.3T and 1.4.  Eventually we probably need to rewrite all of
> the wifi code.

We already re-wrote all wifi related codes in master !
Flags: needinfo?(pehrsons)
(Reporter)

Comment 29

4 years ago
(In reply to Chuck Lee [:chucklee] from comment #26)
> Created attachment 8464633 [details] [diff] [review]
> Add delay to command queue execution. (Gecko 1.3t)

> This can solve the issue in comment 22, the drawback is wifi won't be
> enabled automatically after hotspot is disabled.
> This drawback also shown on flame, since this has no major affect for user
> and should be resolved after Gaia adopted to wifi enable API. I think this
> is acceptable solution.

Seem a good workaround on normal use. Thanks!
Created attachment 8465179 [details] [review]
Don't sync wifi state into settings while setting app start. (Gaia 1.3t, 1.4)
Attachment #8463876 - Attachment is obsolete: true
Attachment #8465179 - Flags: review?(ejchen)
Comment on attachment 8464633 [details] [diff] [review]
Add delay to command queue execution. (Gecko 1.3t, 1.4)

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

Using a timer may not be a good solution. Giving a feedback+ because it helps to fix the problem for a moment.
Not sure if Henry can give any suggestion here.
Attachment #8464633 - Flags: feedback?(vchang)
Attachment #8464633 - Flags: feedback?(hchang)
Attachment #8464633 - Flags: feedback+
Comment on attachment 8465179 [details] [review]
Don't sync wifi state into settings while setting app start. (Gaia 1.3t, 1.4)

Thanks Chuck ! This patch works nice for me :)
Attachment #8465179 - Flags: review?(ejchen) → review+
(In reply to yang.zhao from comment #22)
> hi,Chuck
>   I've tried remove that line in connectivity.js,and find that follow the
> STR in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=823783#c21.Copy here:
> 1) start settings app, ensure that wifi is enabled and connected to a network
> 2) force quit settings app
> 3) open setting app again, and go to hotspot
> 4) turn hotspot on and off
> 5) Go to wifi panel. Toggle button shows wifi on, but it is actually off now
> 6) Tap on wifi toggle button. It goes off and remains disabled forever.
> 
> After Step 5:toggle the wifi on,you'll find the toggle button toggles
> between on and off again!Maybe it's still a sync problem.FYI.

This can be reproduced on flame if run STR 2~3 fast enough:
1. enable wifi
2. enable hotspot
3. disable hotspot

It seems that we need apply gecko patch to central and other related branch as well.
Jan, this is more your table than mine.
Flags: needinfo?(janjongboom)
Flags: needinfo?(pehrsons)
(In reply to Vincent Chang[:vchang] from comment #31)
> Comment on attachment 8464633 [details] [diff] [review]
> Add delay to command queue execution. (Gecko 1.3t)
> 
> Review of attachment 8464633 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Using a timer may not be a good solution. Giving a feedback+ because it
> helps to fix the problem for a moment.
> Not sure if Henry can give any suggestion here.

Since the root cause is both gecko/gaia is trying the synchronous
the internal wifi state and settings, we can ask gaia to just
trust gecko's wifi machinery, sit back and wait until settings
being sync'ed. 

The only exception is wifi hotspot. Settings would become 
out of sync if we enable wifi hotspot while wifi is on. 
We may get around this by asking the one who changes 
'tethering.wifi.enabled' to sync the wifi settings.
There are two places where 'tethering.wifi.enabled'
would be changed so it's not a big modification.

The above solution is definitely just a hotfix for 1.3T
and is not verified effective or not...
Flags: needinfo?(janjongboom)
(In reply to Henry Chang [:henry] from comment #35)
> The only exception is wifi hotspot. Settings would become 
> out of sync if we enable wifi hotspot while wifi is on. 
> We may get around this by asking the one who changes 
> 'tethering.wifi.enabled' to sync the wifi settings.
> There are two places where 'tethering.wifi.enabled'
> would be changed so it's not a big modification.

There's no problem settings wifi off while user enables hotspot, but it doesn't always enable wifi while user disables hotspot - wifi only being enabled automatically if it is previously disabled by user enabling hotspot.
Also, the same logic applies to hotspot while user enabling/disabling wifi.

If app has the knowledge to handle the relation between hotspot and wifi described above correctly, then we don't have to do it in gecko anymore.
This involves many modification and testing, and we expected Gaia can take control of such behavior after we provide API for enabling wifi and hotspot.
(In reply to Zhenqing Liu from comment #29)
> Seem a good workaround on normal use. Thanks!

Hi Zhenging,
  Does we need to land these patches into 1.3t branch, or you already applied them into your local repo?
(Reporter)

Comment 38

4 years ago
(In reply to Chuck Lee [:chucklee] from comment #37)
> (In reply to Zhenqing Liu from comment #29)
> > Seem a good workaround on normal use. Thanks!
> 
> Hi Zhenging,
>   Does we need to land these patches into 1.3t branch, or you already
> applied them into your local repo?

We have applied them into our local repo. And I think it's better to land them into 1.3t branch. Thanks!
Comment on attachment 8464633 [details] [diff] [review]
Add delay to command queue execution. (Gecko 1.3t, 1.4)

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

I agree this is the least risky workaround for 1.3T!
Attachment #8464633 - Flags: feedback?(hchang) → feedback+
patch ready.
Flags: needinfo?(ryang)
Assignee: nobody → chulee
Attachment #8464633 - Attachment description: Add delay to command queue execution. (Gecko 1.3t) → Add delay to command queue execution. (Gecko 1.3t, 1.4)
Comment on attachment 8464633 [details] [diff] [review]
Add delay to command queue execution. (Gecko 1.3t, 1.4)

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

Sorry for pending for a while. Looks good to me.
Attachment #8464633 - Flags: review?(vchang) → review+
Created attachment 8474393 [details] [diff] [review]
Add delay to command queue execution. r=vchang (Gecko 1.3t, 1.4)

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Timing issue while using slow speed CPU.
User impact if declined: Wifi will keep enabling and disabling automatically forever after some operation
Testing completed: Manual test per comment 38
Risk to taking this patch (and alternatives if risky): No
String or UUID changes made by this patch: No
Attachment #8464633 - Attachment is obsolete: true
Attachment #8474393 - Flags: approval-mozilla-b2g30?
Attachment #8474393 - Flags: approval-mozilla-b2g28?
Comment on attachment 8465179 [details] [review]
Don't sync wifi state into settings while setting app start. (Gaia 1.3t, 1.4)

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Timing issue while using slow speed CPU.
[User impact] if declined: Wifi will keep enabling and disabling automatically forever after some operation like STR in comment 20
[Testing completed]: Manual tested per comment 38
[Risk to taking this patch] (and alternatives if risky): State unsync between settings value and wifi state after some operation, described in comment 21.
[String changes made]: No
Attachment #8465179 - Flags: approval-gaia-v1.4?
Attachment #8465179 - Flags: approval-gaia-v1.3?
NI : is this needed for tarako/dolphin only? 2.0/2.1 and flame unaffected here?
Flags: needinfo?(chulee)
They are affected but I think we don't have to uplift because it's corner use case and harder to reproduce on fast CPU, also we plan to remove remove command queue by using API instead of settings in the future.
Flags: needinfo?(chulee)
(In reply to Chuck Lee [:chucklee] from comment #45)
> They are affected but I think we don't have to uplift because it's corner
> use case and harder to reproduce on fast CPU, also we plan to remove remove
> command queue by using API instead of settings in the future.

As this is needed by partner I am NI wayne to help make a call here. Its too late for 1.3 though, we could take on 1.4 depending on wayne's partner conversation.
Flags: needinfo?(wchang)
Given the low probability of this occurring and the current project stage, not taking this on neither 1.3t or 1.4.
Flags: needinfo?(wchang)

Updated

4 years ago
Attachment #8465179 - Flags: approval-gaia-v1.4?
Attachment #8465179 - Flags: approval-gaia-v1.3?
Comment on attachment 8474393 [details] [diff] [review]
Add delay to command queue execution. r=vchang (Gecko 1.3t, 1.4)

Clearing the approval request flag, given wayne's input which i agree with.
Attachment #8474393 - Flags: approval-mozilla-b2g30?
Attachment #8474393 - Flags: approval-mozilla-b2g28?

Updated

4 years ago
status-b2g-v1.3T: affected → wontfix
status-b2g-v1.4: affected → wontfix
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.