[b2g-bluetooth] follow-up to bug 730992 (event codegen and value initialization)

RESOLVED FIXED in mozilla17

Status

()

Core
DOM: Device Interfaces
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: ericchou, Assigned: ericchou)

Tracking

unspecified
mozilla17
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

5 years ago
1. mPasskey & mUuid are not initialized in create() of BluetoothPairingEvent.
2. Use event codegen to implement BluetoothPairingEvent? 

(According to comment: https://bugzilla.mozilla.org/show_bug.cgi?id=730992#c62)
(Assignee)

Updated

5 years ago
Assignee: nobody → echou
(Assignee)

Comment 1

5 years ago
About item (1), I'll separate BluetoothPairingEvent into two events. One contains deviceAddress & uuid, the other one contains deviceAddress & passkey.
(Assignee)

Comment 2

5 years ago
Created attachment 653701 [details] [diff] [review]
v1: used codegen and add BluetoothAuthorizeEvent

Used event generator to create BluetoothPairingEvent and BluetoothAuthorizeEvent & avoid passing non-initialized or no-value property in an event.
Attachment #653701 - Flags: review?(kyle)
(Assignee)

Comment 3

5 years ago
Created attachment 653702 [details] [diff] [review]
v1: used codegen and add BluetoothAuthorizeEvent

Redundant modification removed.
Attachment #653701 - Attachment is obsolete: true
Attachment #653701 - Flags: review?(kyle)
Attachment #653702 - Flags: review?(kyle)
Comment on attachment 653702 [details] [diff] [review]
v1: used codegen and add BluetoothAuthorizeEvent

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

::: dom/bluetooth/BluetoothAdapter.cpp
@@ +339,5 @@
> +    e->InitBluetoothPairingEvent(NS_LITERAL_STRING("requestconfirmation"),
> +                                 false,
> +                                 false,
> +                                 arr[0].value().get_nsString(),
> +                                 arr[1].value().get_uint32_t());

Nit: Might want to put NS_ASSERTION checks on array length and value types.
Attachment #653702 - Flags: review?(kyle) → review+
Blocks: 727618
(Assignee)

Comment 5

5 years ago
Created attachment 654121 [details] [diff] [review]
Final: used codegen and add BluetoothAuthorizeEvent

Used NS_ASSERTION to verify parameter length and type.
Attachment #653702 - Attachment is obsolete: true
(Assignee)

Comment 6

5 years ago
Try: https://tbpl.mozilla.org/?tree=Try&rev=c05e571d1fe5
(Assignee)

Comment 7

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e8e54b17e6f2
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
(Assignee)

Comment 8

5 years ago
This patch was uploaded to inbound yesterday (See comment 7), but has not been merged to m-c. So added the "checkin-needed" label to notify.

Comment 9

5 years ago
Patches aren't checked in a second time to mozilla-central - someone just has to manually merge inbound to mozilla-central (which typically happens once a day). We have to wait for a green PGO run (which doesn't happen on every push), which when combined with discovering bustage/backing that out/waiting for green again (PGO runs take up to 4-5 hours), can mean merges are often delayed.

When this merges the mozilla-central changeset will be posted in the bug, and the bug marked fixed :-)
Keywords: checkin-needed
(Assignee)

Comment 10

5 years ago
Thank you, Ed. My bad. I did understand how this worked. I asked this question is because this morning I found there's a patch already in m-c, was submitted later than mine. However, I just checked again and couldn't find that patch anymore. I must be so tired. :P

Thanks again. :)
https://hg.mozilla.org/mozilla-central/rev/e8e54b17e6f2
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.