12.92 KB, patch
|Details | Diff | Splinter Review|
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)
About item (1), I'll separate BluetoothPairingEvent into two events. One contains deviceAddress & uuid, the other one contains deviceAddress & passkey.
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.
Created attachment 653702 [details] [diff] [review] v1: used codegen and add BluetoothAuthorizeEvent Redundant modification removed.
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.value().get_nsString(), > + arr.value().get_uint32_t()); Nit: Might want to put NS_ASSERTION checks on array length and value types.
5 years ago
Created attachment 654121 [details] [diff] [review] Final: used codegen and add BluetoothAuthorizeEvent Used NS_ASSERTION to verify parameter length and type.
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.
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 :-)
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. :)