Closed Bug 1152098 Opened 9 years ago Closed 9 years ago

Crash in bluetooth while quickly toggling BT icon in notification window without bluetoothd running

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(blocking-b2g:2.2+, firefox38 wontfix, firefox39 wontfix, firefox40 fixed, b2g-v2.2 fixed, b2g-master fixed)

RESOLVED FIXED
2.2 S10 (17apr)
blocking-b2g 2.2+
Tracking Status
firefox38 --- wontfix
firefox39 --- wontfix
firefox40 --- fixed
b2g-v2.2 --- fixed
b2g-master --- fixed

People

(Reporter: ggrisco, Assigned: shawnjohnjr)

References

Details

(Keywords: crash, Whiteboard: [caf priority: p2][CR 819587][b2g-crash])

Attachments

(3 files, 3 obsolete files)

1. Disable bluetoothd and reboot the phone
2. Go to settings/bluetooth
3. Pull down the notification window
4. Quickly toggle the bluetooth icon at bottom of screen (faster is better)

Crash seen 100% reproducible:

Operating system: Android
                  0.0.0 Linux 3.10.49-gd2933a6 #2 SMP PREEMPT Mon Apr 6 14:40:21 PDT 2015 armv7l qcom/msm8909/msm8909:5.1/LMY47D/b2guser04052219:userdebug/test-keys
CPU: arm
     ARMv0
     4 CPUs

Crash reason:  SIGSEGV
Crash address: 0x0

Thread 0 (crashed)
 0  libxul.so!mozilla::dom::bluetooth::BluetoothServiceBluedroid::ProfileDeinitResultHandler::Proceed [BluetoothServiceBluedroid.cpp : 1150 + 0x8]
     r0 = 0x00000000    r1 = 0x00000000    r2 = 0x00000000    r3 = 0xb672a4e0
     r4 = 0xb6a5d900    r5 = 0x00000001    r6 = 0xb6a5d8d0    r7 = 0xbe9f3564
     r8 = 0x00000000    r9 = 0xbe9f35a7   r10 = 0x00000000   r12 = 0xbe9f3564
     fp = 0xbe9f3548    sp = 0xbe9f3520    lr = 0xb564bec9    pc = 0xb565be56
    Found by: given as instruction pointer in context
 1  libxul.so!mozilla::dom::bluetooth::BluetoothA2dpManager::CleanupAvrcpResultHandler::Cleanup [BluetoothA2dpManager.cpp : 379 + 0x5]
     r3 = 0x00000000    r4 = 0xb6a5d900    r5 = 0x00000001    r6 = 0xb6a5d8d0
     r7 = 0xbe9f3564    r8 = 0x00000000    r9 = 0xbe9f35a7   r10 = 0x00000000
     fp = 0xbe9f3548    sp = 0xbe9f3528    pc = 0xb564bec9
    Found by: call frame info
 2  libxul.so!mozilla::dom::bluetooth::BluetoothHALInterfaceRunnable0<mozilla::dom::bluetooth::BluetoothA2dpResultHandler, void>::Run [BluetoothHALHelpers.h : 916 + 0x15]
     r3 = 0xb564beb5    r4 = 0xb6a5d900    r5 = 0x00000001    r6 = 0xb6a5d8d0
     r7 = 0xbe9f3564    r8 = 0x00000000    r9 = 0xbe9f35a7   r10 = 0x00000000
     fp = 0xbe9f3548    sp = 0xbe9f3530    pc = 0xb4d71869
    Found by: call frame info
 3  libxul.so!nsThread::ProcessNextEvent [nsThread.cpp : 855 + 0x5]
     r3 = 0xb4d7184d    r4 = 0xb6a5d900    r5 = 0x00000001    r6 = 0xb6a5d8d0
     r7 = 0xbe9f3564    r8 = 0x00000000    r9 = 0xbe9f35a7   r10 = 0x00000000
     fp = 0xbe9f3548    sp = 0xbe9f3538    pc = 0xb4c3ce07
    Found by: call frame info
 4  libxul.so!NS_ProcessNextEvent [nsThreadUtils.cpp : 265 + 0xb]
     r4 = 0x00000000    r5 = 0xb69fc0c0    r6 = 0xb69f4260    r7 = 0x00000001
     r8 = 0xbe9f3648    r9 = 0xbe9f3638   r10 = 0xbe9f363c    fp = 0xbe9f3644
     sp = 0xbe9f35a0    pc = 0xb4c49e69
    Found by: call frame info
 5  libxul.so!mozilla::ipc::MessagePump::Run [MessagePump.cpp : 99 + 0x7]
     r0 = 0xb6a5d8d0    r1 = 0x01000000    r4 = 0xb69f4250    r5 = 0xb69fc0c0
     r6 = 0xb69f4260    r7 = 0x00000001    r8 = 0xbe9f3648    r9 = 0xbe9f3638
    r10 = 0xbe9f363c    fp = 0xbe9f3644    sp = 0xbe9f35b0    pc = 0xb4d8b6cd
    Found by: call frame info
 6  libxul.so!MessageLoop::RunInternal [message_loop.cc : 233 + 0x5]
     r4 = 0xb69fc0c0    r5 = 0xb1799340    r6 = 0xb6a5d8d0    r7 = 0xbe9f380d
     r8 = 0xbe9f3648    r9 = 0xbe9f3638   r10 = 0xbe9f363c    fp = 0xbe9f3644
     sp = 0xbe9f35d8    pc = 0xb4d81d91
    Found by: call frame info
 7  libxul.so!MessageLoop::Run [message_loop.cc : 226 + 0x5]
     r3 = 0x00000000    r4 = 0xb69fc0c0    r5 = 0xb1799340    r6 = 0xb6a5d8d0
     r7 = 0xbe9f380d    r8 = 0xbe9f3648    r9 = 0xbe9f3638   r10 = 0xbe9f363c
     fp = 0xbe9f3644    sp = 0xbe9f35e0    pc = 0xb4d81e45
NI'ing shawn to help here.
Flags: needinfo?(shuang)
In the logs I see:

I/GeckoBluetooth(  261): OnError: BluetoothInterface::Init failed: 5

after which in the code sBtInterface is set to null
(In reply to Greg Grisco from comment #2)
> In the logs I see:
> 
> I/GeckoBluetooth(  261): OnError: BluetoothInterface::Init failed: 5
> 
> after which in the code sBtInterface is set to null

Hi Greg,
Are you still using HAL interface (in-gecko loads bluedroid) instead of bluetooth daemon?
Flags: needinfo?(shuang)
(In reply to Greg Grisco from comment #2)
> In the logs I see:
> 
> I/GeckoBluetooth(  261): OnError: BluetoothInterface::Init failed: 5
> 
> after which in the code sBtInterface is set to null

Just want to clarify things:
v2.2 should now default uses bluetooth daemon, it checks /init.bluetooth.rc exists.
http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/file/43041c78052b/dom/bluetooth/BluetoothInterface.cpp#l124
Is it on purpose to use HAL based backend?
(In reply to Shawn Huang [:shawnjohnjr] from comment #3)
> (In reply to Greg Grisco from comment #2)
> > In the logs I see:
> > 
> > I/GeckoBluetooth(  261): OnError: BluetoothInterface::Init failed: 5
> > 
> > after which in the code sBtInterface is set to null
> 
> Hi Greg,
> Are you still using HAL interface (in-gecko loads bluedroid) instead of
> bluetooth daemon?

Hi Shawn,

no we're using bluetoothd.  But since we saw bug 1152095 with bluetoothd, we decided to remove bluetoothd to see if crash went away and saw this crash instead.

After applying patch to fix bug 1152095, we started seeing this crash even with bluetoothd running.
Whiteboard: [b2g-crash] → [CR 819587][b2g-crash]
Whiteboard: [CR 819587][b2g-crash] → [caf priority: p2][CR 819587][b2g-crash]
(In reply to Greg Grisco from comment #2)
> In the logs I see:
> 
> I/GeckoBluetooth(  261): OnError: BluetoothInterface::Init failed: 5
> 
> after which in the code sBtInterface is set to null

Hi Greg,
Do you mind providing logcat and trace based on bluetooth daemon?
Thanks.
Flags: needinfo?(ggrisco)
(In reply to Greg Grisco from comment #0)
It looks like previous disable bluetooth operation haven't finished and the next InitResultHandler init failed.
 
> libxul.so!mozilla::dom::bluetooth::BluetoothServiceBluedroid::
> ProfileDeinitResultHandler::Proceed [BluetoothServiceBluedroid.cpp : 1150 +
> 0x8]
>      r0 = 0x00000000    r1 = 0x00000000    r2 = 0x00000000    r3 = 0xb672a4e0
>      r4 = 0xb6a5d900    r5 = 0x00000001    r6 = 0xb6a5d8d0    r7 = 0xbe9f3564
>      r8 = 0x00000000    r9 = 0xbe9f35a7   r10 = 0x00000000   r12 = 0xbe9f3564
>      fp = 0xbe9f3548    sp = 0xbe9f3520    lr = 0xb564bec9    pc = 0xb565be56
>     Found by: given as instruction pointer in context
>  1 
> libxul.so!mozilla::dom::bluetooth::BluetoothA2dpManager::
> CleanupAvrcpResultHandler::Cleanup [BluetoothA2dpManager.cpp : 379 + 0x5]
>      r3 = 0x00000000    r4 = 0xb6a5d900    r5 = 0x00000001    r6 = 0xb6a5d8d0
>      r7 = 0xbe9f3564    r8 = 0x00000000    r9 = 0xbe9f35a7   r10 = 0x00000000
>      fp = 0xbe9f3548    sp = 0xbe9f3528    pc = 0xb564bec9
>     Found by: call frame info
>  2 
> libxul.so!mozilla::dom::bluetooth::BluetoothHALInterfaceRunnable0<mozilla::
> dom::bluetooth::BluetoothA2dpResultHandler, void>::Run
> [BluetoothHALHelpers.h : 916 + 0x15]
>      r3 = 0xb564beb5    r4 = 0xb6a5d900    r5 = 0x00000001    r6 = 0xb6a5d8d0
>      r7 = 0xbe9f3564    r8 = 0x00000000    r9 = 0xbe9f35a7   r10 = 0x00000000
>      fp = 0xbe9f3548    sp = 0xbe9f3530    pc = 0xb4d71869
>     Found by: call frame info
Maybe it's a race condition case, the previous profile level cleanup not yet finished and later init failed because the bluedroid stack does not allow, and since we only get sBtInterface once (in theory we get HAL library access) in constructor. Setting sBtInterface in  BluetoothServiceBluedroid::InitResultHandler OnError seems to be strange.
This bug looks very similar to bug 1152095. I wonder how it's possible to enable or disable Bluetooth while the opposite operation is still in progress (or seems to be). :/ That should actually not work by design. Very strange...
Flags: needinfo?(ggrisco)
Flags: needinfo?(ggrisco)
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #10)
> This bug looks very similar to bug 1152095. I wonder how it's possible to
> enable or disable Bluetooth while the opposite operation is still in
> progress (or seems to be). :/ That should actually not work by design. Very
> strange...

I will ask for more logs to clarify this bug.
Comment on attachment 8590241 [details] [diff] [review]
Bug 1152098 - Do not set sBtInterface to null if Init() fails

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

I'm rather skeptical about this change. Wouldn't it leave sBtInterface in an undefined state? That doesn't seem good. Can we first get some more information about what's going on?
Shawn Huang [:shawnjohnjr] from comment #3)
> Hi Greg,
> Are you still using HAL interface (in-gecko loads bluedroid) instead of
> bluetooth daemon?

(replying for Greg since it's on PTO until Monday)

No, we are not.  We noticed this crash while debugging the other BT crash with bluetoothd with similar STR, so wanted to report it as it probably needs to be fixed as well.

You should be able to reproduce this based on the STR in comment 0.
Flags: needinfo?(ggrisco)
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #12)
> Comment on attachment 8590241 [details] [diff] [review]
> Bug 1152098 - Do not set sBtInterface to null if Init() fails
> 
> Review of attachment 8590241 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I'm rather skeptical about this change. Wouldn't it leave sBtInterface in an
> undefined state? That doesn't seem good. Can we first get some more
> information about what's going on?

SBtInterface returned only when BluetoothServiceBluedroid constructs, if we set null to sBtInterface, there is no chance to do |init| again.
(In reply to Michael Vines [:m1] [:evilmachines] from comment #13)
> Shawn Huang [:shawnjohnjr] from comment #3)
> > Hi Greg,
> > Are you still using HAL interface (in-gecko loads bluedroid) instead of
> > bluetooth daemon?
> 
> (replying for Greg since it's on PTO until Monday)
> 
> No, we are not.  We noticed this crash while debugging the other BT crash
> with bluetoothd with similar STR, so wanted to report it as it probably
> needs to be fixed as well.
> 
> You should be able to reproduce this based on the STR in comment 0.

I understood that based your bug description this is 100% reproducible, however, I followed your steps (and with patch bug 1152095 applied) and test on device Orion, I cannot reproduce it.
Maybe I did not switch on/off fast enough (I tried my best), so I added some code to make the interval shorter.

--- a/dom/bluetooth/BluetoothService.cpp
+++ b/dom/bluetooth/BluetoothService.cpp
@@ -571,7 +571,10 @@ BluetoothService::HandleSettingsChanged(nsISupports* aSubject)
 
   sToggleInProgress = true;
 
-  nsresult rv = StartStopBluetooth(setting.mValue.toBoolean(), false);
+  nsresult rv = StartStopBluetooth(false, false);
+  StartStopBluetooth(true, false);
+  StartStopBluetooth(false, false);
+//  nsresult rv = StartStopBluetooth(setting.mValue.toBoolean(), false);
   NS_ENSURE_SUCCESS(rv, rv);
 
   return NS_OK;

After I added this incorrect code, I can easily hit the same pattern.

(gdb) bt
#0  0xb593048a in mozilla::dom::bluetooth::BluetoothServiceBluedroid::ProfileDeinitResultHandler::Proceed (this=<optimized out>)
    at /code/8909/gecko/dom/bluetooth/bluedroid/BluetoothServiceBluedroid.cpp:1150
#1  0xb5920500 in CleanupAvrcpResultHandler::OnError (this=<optimized out>, aStatus=<optimized out>)
    at /code/8909/gecko/dom/bluetooth/bluedroid/BluetoothA2dpManager.cpp:349
#2  0xb591fee4 in mozilla::dom::bluetooth::BluetoothHALInterfaceRunnable1<mozilla::dom::bluetooth::BluetoothA2dpResultHandler, void, mozilla::dom::bluetooth::BluetoothStatus, mozilla::dom::bluetooth::BluetoothStatus>::Run (this=<optimized out>) at /code/8909/gecko/dom/bluetooth/bluedroid/BluetoothHALHelpers.h:942
#3  0xb4fb57be in nsThread::ProcessNextEvent (this=0xb6902630, aMayWait=<optimized out>, aResult=0xbeda2547) at /code/8909/gecko/xpcom/threads/nsThread.cpp:855
#4  0xb4fc2820 in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /code/8909/gecko/xpcom/glue/nsThreadUtils.cpp:265
#5  0xb50c6964 in mozilla::ipc::MessagePump::Run (this=0xb698b280, aDelegate=0xb69a90c0) at /code/8909/gecko/ipc/glue/MessagePump.cpp:99
#6  0xb50bd038 in MessageLoop::RunInternal (this=this@entry=0xb69a90c0) at /code/8909/gecko/ipc/chromium/src/base/message_loop.cc:233
#7  0xb50bd0ec in RunHandler (this=0xb69a90c0) at /code/8909/gecko/ipc/chromium/src/base/message_loop.cc:226
#8  MessageLoop::Run (this=0xb69a90c0) at /code/8909/gecko/ipc/chromium/src/base/message_loop.cc:200
#9  0xb593ba9e in nsBaseAppShell::Run (this=0xb2615dc0) at /code/8909/gecko/widget/nsBaseAppShell.cpp:164
#10 0xb5bc9cc2 in nsAppStartup::Run (this=0xb269d850) at /code/8909/gecko/toolkit/components/startup/nsAppStartup.cpp:281
#11 0xb5bdfbec in XREMain::XRE_mainRun (this=this@entry=0xbeda26b8) at /code/8909/gecko/toolkit/xre/nsAppRunner.cpp:4141
#12 0xb5bdfe1e in XREMain::XRE_main (this=this@entry=0xbeda26b8, argc=argc@entry=1, argv=argv@entry=0xb6932188, aAppData=aAppData@entry=0xb6f51838 <_ZL8sAppData>)
    at /code/8909/gecko/toolkit/xre/nsAppRunner.cpp:4217
#13 0xb5bdffc6 in XRE_main (argc=1, argv=0xb6932188, aAppData=0xb6f51838 <_ZL8sAppData>, aFlags=<optimized out>) at /code/8909/gecko/toolkit/xre/nsAppRunner.cpp:4437
#14 0xb6f378f8 in do_main (argc=argc@entry=1, argv=argv@entry=0xb6932188) at /code/8909/gecko/b2g/app/nsBrowserApp.cpp:165
#15 0xb6f37a44 in b2g_main (argc=1, argv=<optimized out>) at /code/8909/gecko/b2g/app/nsBrowserApp.cpp:293
#16 0xb6f377a0 in RunProcesses (aReservedFds=..., argv=0xbeda3974, argc=1) at /code/8909/gecko/b2g/app/B2GLoader.cpp:225
#17 main (argc=1, argv=0xbeda3974) at /code/8909/gecko/b2g/app/B2GLoader.cpp:290
After applying the patch ( Attachment 8590241 [details] [diff] ), it can avoid the crash.
But i still saw daemon does not enable.

01-04 21:11:54.069 I/bluedroid( 6614): init
01-04 21:11:54.079 I/bte_conf( 6614): bte_load_conf attempt to load stack conf from /etc/bluetooth/bt_stack.conf
01-04 21:11:54.079 I/bte_conf( 6614): bte_load_ble_conf attempt to load ble stack conf from /etc/bluetooth/ble_stack.conf
01-04 21:11:54.079 E/bt_osi_config( 6614): config_new unable to open file '/etc/bluetooth/ble_stack.conf': No such file or directory
01-04 21:11:54.079 I/bte_conf( 6614): bte_load_ble_conf file >/etc/bluetooth/ble_stack.conf< not found
01-04 21:11:54.079 I/GKI_LINUX( 6614): gki_task_entry task_id=1 [BTIF] starting
01-04 21:11:54.079 I/bluedroid( 6614): get_profile_interface socket
01-04 21:11:54.399 E/HWComposer(  266): Non-uniform vsync interval: 116680833
01-04 21:11:54.699 I/GeckoBluetooth(  266): OnError: BluetoothInterface::Init failed: 1
01-04 21:11:54.709 I/GeckoBluetooth(  266): AdapterStateChangedNotification: BT_STATE: 0
01-04 21:11:54.739 I/I/O     (  266): Bluetooth daemon already connecting/connected!
(In reply to Shawn Huang [:shawnjohnjr] from comment #16)
> (gdb) bt
> #2  0xb591fee4 in
> mozilla::dom::bluetooth::BluetoothHALInterfaceRunnable1<mozilla::dom::
> bluetooth::BluetoothA2dpResultHandler, void,
I recompiled and test again now the backtrace seems more reasonable to me. I don't know why I get strange backtrace with HAL related code involved (Comment 16).

(gdb) bt
#0  0xb5930556 in mozilla::dom::bluetooth::BluetoothServiceBluedroid::ProfileDeinitResultHandler::Proceed (this=<optimized out>)
    at /code/8909/gecko/dom/bluetooth/bluedroid/BluetoothServiceBluedroid.cpp:1148
#1  0xb59204dc in CleanupAvrcpResultHandler::OnError (this=<optimized out>, aStatus=<optimized out>)
    at /code/8909/gecko/dom/bluetooth/bluedroid/BluetoothA2dpManager.cpp:349
#2  0xb592260c in mozilla::dom::bluetooth::BluetoothResultRunnable1<mozilla::dom::bluetooth::BluetoothA2dpResultHandler, void, mozilla::dom::bluetooth::BluetoothStatus, mozilla::dom::bluetooth::BluetoothStatus>::Run (this=<optimized out>) at /code/8909/gecko/dom/bluetooth/BluetoothInterfaceHelpers.h:138
#3  0xb4fb57be in nsThread::ProcessNextEvent (this=0xb6902630, aMayWait=<optimized out>, aResult=0xbea65557) at /code/8909/gecko/xpcom/threads/nsThread.cpp:855
#4  0xb4fc2820 in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=aMayWait@entry=false) at /code/8909/gecko/xpcom/glue/nsThreadUtils.cpp:265
Ok, I think I know how to manually reproduce this issue without adding any extra code.

STR:
1. Disable bluetoothd and reboot the phone
2. Go to settings/bluetooth page and make sure current status is disabled
3. Pull down the notification window
4. Quickly toggle the bluetooth icon at bottom of screen (faster is better), it depends on how to tap the icon, I tried over 2 mins
5. When you found notification window Bluetooth icon frozen, and then go to settings/bluetooth to enable Bluetooth again.
Based on attachment 8592211 [details], logcat shows it's possible that on/off internal operation interleaved. Settings can do UI level animation transition, so toggle button will be disabled for a few seconds however notification window does not provide this transition. ni? Thomas if he has different opinion from daemon side.
Comment on attachment 8592228 [details] [diff] [review]
Bug 1152098 - Do not execute multiple bluetooth toggle requests at the same time

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

That sounds like a plausible explanation. Thanks! I'm just surprised that the UI lets us do this. The proposed fix looks like a workaround. I suggest file a bug to look for a real solution.
Attachment #8592228 - Flags: feedback?(tzimmermann) → feedback+
Assignee: nobody → shuang
blocking-b2g: 2.2? → 2.2+
Comment on attachment 8592228 [details] [diff] [review]
Bug 1152098 - Do not execute multiple bluetooth toggle requests at the same time

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

r=me with comment addressed. Please file a bug for real solution as Thomas' suggestion, and inform system app gaia dev of possible UI inconsistency.

::: dom/bluetooth/BluetoothService.cpp
@@ +567,5 @@
>    if (!setting.mValue.isBoolean()) {
>      MOZ_ASSERT(false, "Expecting a boolean for 'bluetooth.enabled'!");
>      return NS_ERROR_UNEXPECTED;
>    }
> +  // Ignore duplicate toggle request

nit: newline before the section. Also revise comment:

  "Ignore subsequent toggling requests if toggling is already in progress"

@@ +569,5 @@
>      return NS_ERROR_UNEXPECTED;
>    }
> +  // Ignore duplicate toggle request
> +  if (sToggleInProgress) {
> +    BT_LOGR("Ignore bluetooth toggle request");

Revise the log:

  "Ignore bluetooth toggling request since toggling is already in progress."
Attachment #8592228 - Flags: review?(btian) → review+
Attachment #8592607 - Attachment description: Bug 1152098 - Ignore subsequent toggling requests if toggling is already in progress, r=btian → Bug 1152098 - Ignore subsequent toggling requests if toggling is already in progress, r=btian (for v2.2)
Attachment #8592610 - Attachment description: Bug 1152098 - Ignore subsequent toggling requests if toggling is already in progress, r=btian → Bug 1152098 - Ignore subsequent toggling requests if toggling is already in progress, r=btian (m-c)
Comment on attachment 8592607 [details] [diff] [review]
Bug 1152098 - Ignore subsequent toggling requests if toggling is already in progress, r=btian (for v2.2)

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 #): potential bug never been discovered
User impact if declined: b2g crash
Testing completed: Test on msm8909 device
Risk to taking this patch (and alternatives if risky): This patch rejects bluetooth toggle request if current status is in progress. This can avoid concurrent on/off operation.
String or UUID changes made by this patch:none
Attachment #8592607 - Flags: approval-mozilla-b2g37?
Comment on attachment 8592607 [details] [diff] [review]
Bug 1152098 - Ignore subsequent toggling requests if toggling is already in progress, r=btian (for v2.2)

Since this is a critical crash, and CAF needs to pick it up I am approving the landing in parallel to m-c landing.
Attachment #8592607 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
https://hg.mozilla.org/integration/b2g-inbound/rev/6d13676c54dd

Will land on b2g37 later when this push is sufficiently green.
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/6d13676c54dd
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S10 (17apr)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: