When the remote transfer multiple files at a time, in the current implementation, we will only notify bluetooth app once by a transfer-start and a transfer-complete. However, this is not the expected behavior. We should notify bluetooth app with a pair of transfer-start and tranfer-complete for each file. In this way, bluetooth app can show the progress bar for each file, too.

Comment on attachment 688144 [details] [diff] [review] Patch 1(v1): Support for receiving multiple files sequentially Review of attachment 688144 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. r=me with nits addressed. ::: dom/bluetooth/BluetoothOppManager.cpp @@ +374,2 @@ > success = WriteToFile(mBodySegment.get(), mBodySegmentLength); > } The logic seems a little complicated here, let's simplify it: bool success = false; if (aConfirm) { StartFileTransfer(); if (CreateFile()) { success = WriteToFile(mBodySegment.get(), mBodySegmentLength); } } ReplyToPut(mPutFinalFlag, success); return true; @@ +657,5 @@ > NS_WARNING("[OPP] Abort failed"); > } > SendDisconnectRequest(); > + return; > + } Instead of calling return in each block, I'd suggest that using another function to handle incoming messages when mLastCommand has value. @@ +691,5 @@ > + opCode == ObexRequestCode::PutFinal) { > + int headerStartIndex = 0; > + // When there's a Put packet right after a PutFinal packet, > + // which means it's the start point of a new file. > + if (mPutFinalFlag && opCode == ObexRequestCode::Put) { What would it happen if some of files could be filled into a PutFinal packet? For example, if the remote device sends three .txt files continuously, and each file is around 200 bytes, then I guess PutFinal would be used. In this case, it won't pass the condition check because opCode != ObexRequestCode::Put. ::: dom/bluetooth/BluetoothOppManager.h @@ +61,5 @@ > bool aFinal); > void SendDisconnectRequest(); > void SendAbortRequest(); > > + void ExtractHeaders(const mozilla::dom::bluetooth::ObexHeaderSet& aHeader); Nit: "mozilla::dom::bluetooth::" can be removed @@ +84,5 @@ > virtual void OnDisconnect() MOZ_OVERRIDE; > > + /** > + * RFCOMM socket status. > + */ Nit: trailing whitespaces

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment on attachment 689546 [details] [diff] [review] Patch 1(v3): Support for receiving multiple files sequentially Review of attachment 689546 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/bluetooth/BluetoothOppManager.cpp @@ +1025,5 @@ > > void > BluetoothOppManager::FileTransferComplete() > { > + Nit: additional empty line

try: https://tbpl.mozilla.org/?tree=Try&rev=9a75c7723de2 https://tbpl.mozilla.org/?tree=Try&rev=f7d8849e561c

Please apply this patch to mozilla 18 since there will be a conflict in gecko/dom/bluetooth/BluetoothOppManager.h when you try to use the other patch.

https://hg.mozilla.org/releases/mozilla-aurora/rev/ac958f6f2e2f https://hg.mozilla.org/releases/mozilla-beta/rev/d30575cfa8d8