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

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Wifi, defect)

Description

[Zhenqing Liu]

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.

Comment 1

[Zhenqing Liu]

Attachment: log about this bug

It seemed stuck in an on-off loop.

Comment 2

[yang.zhao]

>-------------------------> 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

[yang.zhao]

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!

Comment 4

[yang.zhao]

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!

Comment 5

[Evelyn Hung]

(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?

Comment 6

[yang.zhao]

(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.

Comment 7

[James Zhang (Spreadtrum)]

Yes, we should fix this wifi auto switch bug, it will make user confuse.

Comment 8

[Zhenqing Liu]

(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|.

Comment 9

[Zhenqing Liu]

Hi Vincent, could you give a comment on this bug?

Comment 10

[Henry Chang [:hchang]]

I remember :chuck had ever introduced a variable to break certain 
enable/disable cycle. Not sure if it's relevant to this issue.

Comment 11

[Zhenqing Liu]

I think we should give high attention on this bug because it has become a block issue.

Comment 12

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

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.

Comment 13

[Vincent Chang[:vchang][changyihsin]]

Clear the NI because Chuck has answered the question in comment 12.

Comment 14

[yang.zhao]

Attachment: wifi.patch

Comment 15

[yang.zhao]

(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!

Comment 16

[James Zhang (Spreadtrum)]

We found 1.4 dolphin also has this bug.

Comment 17

[Wayne Chang [:wchang]]

I cannot reproduce this on flame 1.3, also given the STR I agree with Chuck on the unlikelihood of users getting here.

Comment 18

[yang.zhao]

(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.

Comment 19

[Zhenqing Liu]

(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.

Comment 20

[Zhenqing Liu]

Attachment: 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.

Comment 21

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

Attachment: 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.

Comment 22

[yang.zhao]

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.

Comment 23

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

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.

Comment 24

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

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 25

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

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.

Comment 26

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

Attachment: 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.

Comment 27

[David Flanagan [:djf]]

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.

Comment 28

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

(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 !

Comment 29

[Zhenqing Liu]

(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!

Comment 30

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

Attachment: Don't sync wifi state into settings while setting app start. (Gaia 1.3t, 1.4)

Comment 31

[Vincent Chang[:vchang][changyihsin]]

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.

Comment 32

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

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 :)

Comment 33

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

(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.

Comment 34

[Andreas Pehrson [:pehrsons]]

Jan, this is more your table than mine.

Comment 35

[Henry Chang [:hchang]]

(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...

Comment 36

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

(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.

Comment 37

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

(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?

Comment 38

[Zhenqing Liu]

(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 39

[Henry Chang [:hchang]]

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!

Comment 40

[Rachelle Yang [:ryang][[e-mail]]]

patch ready.

Comment 41

[Vincent Chang[:vchang][changyihsin]]

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.

Comment 42

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

Attachment: 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

Comment 43

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

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

Comment 44

[bhavana bajaj [:bajaj]]

NI : is this needed for tarako/dolphin only? 2.0/2.1 and flame unaffected here?

Comment 45

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

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.

Comment 46

[bhavana bajaj [:bajaj]]

(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.

Comment 47

[Wayne Chang [:wchang]]

Given the low probability of this occurring and the current project stage, not taking this on neither 1.3t or 1.4.

Comment 48

[bhavana bajaj [:bajaj]]

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.