[bluetooth] onadapteradded event sometimes won't be fired when quick tapping on setting toggle.

RESOLVED FIXED in Firefox 21


Firefox OS
5 years ago
5 years ago


(Reporter: Evelyn Hung, Assigned: ericchou)


B2G C4 (2jan on)
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed)



(1 attachment)



5 years ago
related to bug 826345. STR:
1. Launch Settings app and choose Bluetooth
2. Quick click on Bluetooth toggle several times
3. Click the "<" to back to menu right previous steps
4. Enter Bluetooth settings and examine the toggle.
Expected Result:
*. The toggle is active for the user input after a while
Actual Result:
*. The toggle is inactive and never go back.

Comment 1

5 years ago
Gaia listens to onadapteradded or ondisabled events to active the toggle.

Comment 2

5 years ago
Nominate as a bb+ because this is the Gecko part of bb+ bug 826345.
Assignee: nobody → echou
Blocks: 808607
blocking-basecamp: ? → +
OS: All → Gonk (Firefox OS)
Hardware: x86 → ARM

Comment 3

5 years ago
Created attachment 699819 [details] [diff] [review]
patch 1: v1: left BluetoothManager objects in the observer table when turning off the Bluetooth

When turning on Bluetooth, parent process would do the following things:

  (1) Call bt_enable() to enable Bluetooth
  (2) Notify child process by calling childActors[index]->SendEnabled(aEnabled);
      Then SetEnabled() on parent process would be called to register 
      |child| bluetooth managers to the observer table.
  (3) Register |parent| bluetooth managers.
Once Bluetooth is enabled, after a short period of time, an 'AdapterAdded' event would be fired. Each observing bluetooth managers should get the event.

The root cause of this problem is that the 'AdapterAdded' event may be fired before |child| bluetooth managers is registered. In order to solve this, the intuitive solution may be that ensuring all live managers are registered before event firing. However, it's not an easy fix on this way because of the current architecture.

My solution is to handle BluetoothManager specifically. We don't really need to remove bluetooth managers from the observer table when turning off Bluetooth. In that case, when turning on Bluetooth, we need to call RemoveObserver() before AddObserver() to ensure that the table won't contain two identical bluetooth managers.

I've tested with this patch applied, looked good.
Attachment #699819 - Flags: review?(kyle)
status-b2g18: --- → fixed
status-firefox19: --- → wontfix
status-firefox20: --- → wontfix
Marking FIXED as this is landed on inbound and b2g18.
Last Resolved: 5 years ago
Resolution: --- → FIXED
status-firefox21: --- → fixed
Target Milestone: --- → B2G C4 (2jan on)
You need to log in before you can comment on or make changes to this bug.