810099 - B2G MMS: support onretrieving event

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[Vicamo Yang [:vicamo][:vyang]]

Notify user whenever a retrieval is on going.

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

this is extracted from carrier requirement

Comment 2

[Dietrich Ayala (:dietrich)]

We can't block unless this is a P1 requirement. What's the user-story ID that this supports?

Comment 3

[Vicamo Yang [:vicamo][:vyang]]

Then let's wait for a user story first.

Comment 4

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 1/2: Interface v1.0

Comment 5

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.0

Comment 6

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Comment on attachment 747181 [details] [diff] [review]
Part 2/2: Patch v1.0

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

::: dom/mms/src/ril/MmsService.js
@@ +1466,5 @@
>  
>        let url =  aMessageRecord.headers["x-mms-content-location"].uri;
>        // For X-Mms-Report-Allowed
>        let wish = aMessageRecord.headers["x-mms-delivery-report"];
> +      Services.obs.notifyObservers(aDomMessage, kSmsReceivedObserverTopic, null);

It seems I can't get domMessage in current design.....Can Gene and Vicamo provide some suggestion?

Comment 7

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

We might need a new function |getDomMessageById| in MobileMessageDatabaseService.js.

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #6)
> Comment on attachment 747181 [details] [diff] [review]
> Part 2/2: Patch v1.0
> 
> Review of attachment 747181 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/mms/src/ril/MmsService.js
> @@ +1466,5 @@
> >  
> >        let url =  aMessageRecord.headers["x-mms-content-location"].uri;
> >        // For X-Mms-Report-Allowed
> >        let wish = aMessageRecord.headers["x-mms-delivery-report"];
> > +      Services.obs.notifyObservers(aDomMessage, kSmsReceivedObserverTopic, null);
> 
> It seems I can't get domMessage in current design.....Can Gene and Vicamo
> provide some suggestion?

Comment 8

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

BTW, this bug might be needed for bug Bug 868218.

Comment 9

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

OK, I think I can use getMessage to getDomMessage.
But that seems be wierd to use getMessage in getMessageRecordById's callback.

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #7)
> We might need a new function |getDomMessageById| in
> MobileMessageDatabaseService.js.
> 
> (In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #6)
> > Comment on attachment 747181 [details] [diff] [review]
> > Part 2/2: Patch v1.0
> > 
> > Review of attachment 747181 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > ::: dom/mms/src/ril/MmsService.js
> > @@ +1466,5 @@
> > >  
> > >        let url =  aMessageRecord.headers["x-mms-content-location"].uri;
> > >        // For X-Mms-Report-Allowed
> > >        let wish = aMessageRecord.headers["x-mms-delivery-report"];
> > > +      Services.obs.notifyObservers(aDomMessage, kSmsReceivedObserverTopic, null);
> > 
> > It seems I can't get domMessage in current design.....Can Gene and Vicamo
> > provide some suggestion?

Comment 10

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.1

Comment 11

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.2

Comment 12

[Gene Lian (I already quit Mozilla)]

Comment on attachment 747215 [details] [diff] [review]
Part 2/2: Patch v1.2

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

Addressing comment #9. I think we could have 2 solutions to solving that:

1. Expose .createDomMessageFromRecord() by nsIRilMobileMessageDatabaseService.idl so that you can call it to generate a DOM message in MmsService.js.
2. Let the nsIRilMobileMessageDatabaseRecordCallback carry one more DOM message:

   interface nsIRilMobileMessageDatabaseRecordCallback : nsISupports
   {
     void notify(in nsresult aRv, in jsval aMessageRecord, in nsISupports aDomMessage);
   };
   
   where the aDomMessage can be generated within the MobileMessageDatabaseService.js.

Both work for me but I'd prefer solution #2.

::: dom/mms/src/ril/MmsService.js
@@ +1470,5 @@
> +      gMobileMessageDatabaseService.getMessage(id, {
> +        notifyMessageGot: function notifyMessageGot(aDomMessage) {
> +          Services.obs.notifyObservers(aDomMessage, kSmsReceivingObserverTopic, null);
> +        },
> +        notifyGetMessageFailed: function notifyGetMessageFailed(aRv, aDomMessage) {

This is wrong. The only parameter is |aRv|. Also, you cannot proceed to do the retrieving process. You need to call:

aRequest.notifyGetMessageFailed(aRv);

and return the .retrieve(...). Anyway, please see my suggestion on the top of the review. You don't need these codes.

Comment 13

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 1/2: Interface v1.1

Comment 14

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.3

Comment 15

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 1/2: Interface v1.2

Comment 16

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.4

Comment 17

[Gene Lian (I already quit Mozilla)]

Comment on attachment 747727 [details] [diff] [review]
Part 2/2: Patch v1.4

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

Looks good!

::: dom/mobilemessage/src/ril/MobileMessageDatabaseService.js
@@ +1290,4 @@
>            return;
>          }
> +        let domMessage = self.createDomMessageFromRecord(messageRecord);
> +        aCallback.notify(Ci.nsIMobileMessageCallback.SUCCESS_NO_ERROR, messageRecord, domMessage);

Fold this a bit:

aCallback.notify(Ci.nsIMobileMessageCallback.SUCCESS_NO_ERROR,
                 messageRecord, domMessage);

@@ +1336,4 @@
>            return;
>          }
> +        let domMessage = self.createDomMessageFromRecord(messageRecord);
> +        aCallback.notify(Ci.nsIMobileMessageCallback.SUCCESS_NO_ERROR, messageRecord, domMessage);

Fold this a bit:

aCallback.notify(Ci.nsIMobileMessageCallback.SUCCESS_NO_ERROR,
                 messageRecord, domMessage);

@@ +1355,5 @@
>     */
>  
>    getMessage: function getMessage(aMessageId, aRequest) {
>      if (DEBUG) debug("Retrieving message with ID " + aMessageId);
>      let self = this;

You don't need |self|.

@@ +1357,5 @@
>    getMessage: function getMessage(aMessageId, aRequest) {
>      if (DEBUG) debug("Retrieving message with ID " + aMessageId);
>      let self = this;
>      let notifyCallback = {
> +      notify: function notify(aRv, aMessageRecord, domMessage) {

s/domMessage/aDomMessage

@@ +1363,1 @@
>            aRequest.notifyMessageGot(domMessage);

s/domMessage/aDomMessage

Comment 18

[Gene Lian (I already quit Mozilla)]

Comment on attachment 747727 [details] [diff] [review]
Part 2/2: Patch v1.4

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

Wait! It's impossible to work without IPC. Please see SmsParent.cpp.

Comment 19

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.5

Comment 20

[Gene Lian (I already quit Mozilla)]

Comment on attachment 748296 [details] [diff] [review]
Part 2/2: Patch v1.5

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

Overall, it looks good. I'll then look into the IPC details when you come back with a formal patch that is verified on the device.

Comment 21

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.6

Comment 22

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Verified by adding onreceiving callback function in message_manager.js in Gaia AP.
Can received this event in Gaia side.

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #21)
> Created attachment 749734 [details] [diff] [review]
> Part 2/2: Patch v1.6

Comment 23

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 747726 [details] [diff] [review]
Part 1/2: Interface v1.2

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

We're adding "onretrieving" event, not "onreceiving", right?

Comment 24

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Now bug 868218 query the delivery status to know retrieving or not. Support onretrieving event let developer can add callback function to know retrieving or not.

Comment 25

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Block leo+ bug 868218.

Comment 26

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 1/2: Interface v1.3

Change to onretrieving event.

Comment 27

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.7

Change to onretrieving event.

Comment 28

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.8

Comment 29

[Gene Lian (I already quit Mozilla)]

Patches look good, but we had a conclusion to expose .createDomMessageFromRecord(...). Right?

Comment 30

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

After talk with Vicamo, he think current implmentation is OK.
No need to expose |createDomMessageFromRecord|.

(In reply to Gene Lian [:gene] from comment #29)
> Patches look good, but we had a conclusion to expose
> .createDomMessageFromRecord(...). Right?

Comment 31

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

:gnarf, according the conversation in Portland MMS work week, you said you might need this event "onRetrieving". This bug is for supporting onRetrieving while you call retrieveMMS. Could you please help to confirm this need?

Comment 32

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 749794 [details] [diff] [review]
Part 2/2: Patch v1.8

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

::: dom/mms/src/ril/MmsService.js
@@ +1067,3 @@
>      // TODO: bug 809832 - support customizable max incoming/outgoing message size.
> +    Services.obs.notifyObservers(aDomMessage, kSmsRetrievingObserverTopic, null);
> +    let transaction = new RetrieveTransaction(aContentLocation);

nit: please have:

  // TODO: bug 809832 ...

  // Notifying observers an MMS message is retrieving.
  Services.obs.notifyObservers(aDomMessage, kSmsRetrievingObserverTopic, null);

  let transaction ...

I'd always want the reader know there are several independent small steps in this function.

::: dom/mobilemessage/src/ril/MobileMessageDatabaseService.js
@@ +1290,5 @@
>            return;
>          }
> +        let domMessage = self.createDomMessageFromRecord(messageRecord);
> +        aCallback.notify(Ci.nsIMobileMessageCallback.SUCCESS_NO_ERROR,
> +                         messageRecord, domMessage);

We never need a DOM message instance when calling `getMessageRecordByTransactionId`, and actually we don't need that message record, either.  I'd rather have some more comments on that callback interface and save extra work to do here.

Comment 33

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #32)
>   // TODO: bug 809832 ...

Just found bug 809832 has been resolved, please also removes this line.  Thank you :)

Comment 34

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 1/2: Interface v1.4

Add some comments in nsIRilMobileMessageDatabaseRecordCallback.

Comment 35

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 1/2: Interface v1.4

Comment 36

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.9

Comment 37

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Comment on attachment 752071 [details] [diff] [review]
Part 2/2: Patch v1.9

Modified according to comment 32.

Comment 38

[Corey Frang [:gnarf]]

I worked around this in my not-downloaded patch, but I would actually prefer to see it in the API.  I think it makes more sense to have it in the API, anytime any message changes for any reason, there should be an event to listen to.

For reference, bug 868218 is the not-downloaded patch - currently whenever you tap on a not downloaded, i call retrieve and manually have to update the status

Comment 39

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Thanks for your supplement. :)

(In reply to Corey Frang [:gnarf] [:gnarf37] from comment #38)
> I worked around this in my not-downloaded patch, but I would actually prefer
> to see it in the API.  I think it makes more sense to have it in the API,
> anytime any message changes for any reason, there should be an event to
> listen to.
> 
> For reference, bug 868218 is the not-downloaded patch - currently whenever
> you tap on a not downloaded, i call retrieve and manually have to update the
> status

Comment 40

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Comment on attachment 752070 [details] [diff] [review]
Part 1/2: Interface v1.4

Could you please do a superreview for this DOM API change? Gaia developers need this event for their development (see comment 38). In this patch, we add onretrieving event to notify Gaia AP when gecko start to actually retrieving the MMS. Thanks.

Comment 41

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 752071 [details] [diff] [review]
Part 2/2: Patch v1.9

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

Thank you :)

::: dom/mms/src/ril/MmsService.js
@@ +27,5 @@
>  const kSmsSendingObserverTopic           = "sms-sending";
>  const kSmsSentObserverTopic              = "sms-sent";
>  const kSmsFailedObserverTopic            = "sms-failed";
>  const kSmsReceivedObserverTopic          = "sms-received";
> +const kSmsRetrievingObserverTopic         = "sms-retrieving";

nit: alignment.

Comment 42

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.10

Fix alignment.

Comment 43

[Mounir Lamouri (:mounir)]

Comment on attachment 752070 [details] [diff] [review]
Part 1/2: Interface v1.4

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

Why can't we rely on retrieveMMs() returned request?

Comment 44

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

:mounir, thanks for your question.
The reasons are below:
1. DomRequest only has two function: onsuccess and onerror.
2. The purpose of |retrieveMMs| is download MMS entity form MMS proxy in manually download mode. So the onsuccess is for the event we successfully download the message. onerror is for any error in that process.
3. The requirement of onretrieving event is Gaia developer want to listen the message status changed to retrieving. It is neither success nor error. So I don't think we can only rely on the dom request.

(In reply to Mounir Lamouri (:mounir) from comment #43)
> Comment on attachment 752070 [details] [diff] [review]
> Part 1/2: Interface v1.4
> 
> Review of attachment 752070 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Why can't we rely on retrieveMMs() returned request?

Comment 45

[Mounir Lamouri (:mounir)]

(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #44)
> :mounir, thanks for your question.
> The reasons are below:
> 1. DomRequest only has two function: onsuccess and onerror.
> 2. The purpose of |retrieveMMs| is download MMS entity form MMS proxy in
> manually download mode. So the onsuccess is for the event we successfully
> download the message. onerror is for any error in that process.
> 3. The requirement of onretrieving event is Gaia developer want to listen
> the message status changed to retrieving. It is neither success nor error.
> So I don't think we can only rely on the dom request.

Isn't a message moving to 'retrieving' state when retriveMMS() is called on it?

Comment 46

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

The current implementation of retriveMMS is below:
1. In nsIDOMMobileMessageManager.idl has nsIDOMDOMRequest retrieveMMS(in long id);

2. MobileMessageManager::RetrieveMMS will new a object "MobileMessageCallback" which take nsIDOMDOMRequest as argument.

3. nsIMmsService.idl has void retrieve(in long id, in nsIMobileMessageCallback request);
MobileMessageManager::RetrieveMMS pass the object of "MobileMessageCallback" into |retrieve| in MmsService.js

4. When |retrieve| in MmsService.js is called. It will change the delivery status from manual to pending. In the mean time should notify the Gaia AP this change. Should we trigger the event onsuccess/onerror of dom request in this moment?

5.In |retrieve|, it will call MobileMessageCallback::notifyGetMessageFailed when error occurred. MobileMessageCallback::notifyGetMessageFailed will call mDOMRequest->FireError eventually. Otherwise, we should successfully retrieved the message. It will call MobileMessageCallback::notifyMessageGot which call mDOMRequest->FireSuccess in the end.

I have no idea how to moving the 'retrieving' state in this flow. Should we trigger the event onsuccess/onerror of dom request in step 4. Or, could you please give me some suggestions? Thanks.



(In reply to Mounir Lamouri (:mounir) from comment #45)
> (In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #44)
> > :mounir, thanks for your question.
> > The reasons are below:
> > 1. DomRequest only has two function: onsuccess and onerror.
> > 2. The purpose of |retrieveMMs| is download MMS entity form MMS proxy in
> > manually download mode. So the onsuccess is for the event we successfully
> > download the message. onerror is for any error in that process.
> > 3. The requirement of onretrieving event is Gaia developer want to listen
> > the message status changed to retrieving. It is neither success nor error.
> > So I don't think we can only rely on the dom request.
> 
> Isn't a message moving to 'retrieving' state when retriveMMS() is called on
> it?

Comment 47

[Mounir Lamouri (:mounir)]

Sorry, I do not understand the previous comment. After reading the code, it seems that calling retrieveMMS() on m-c will do an HTTP GET on a resource. Is that correct? When is the message being on the retrieving state? When the HTTP GET starts? Is there other situations when a message can be retrieving?

Comment 48

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Try to answer your question.
1. retrieveMMS do an HTTP GET on an uri(content location).
2. Before calling retrieveMMS, the state of an incoming MMS notification in Manual mode is delivery=DELIVERY_NOT_DOWNLOADED and delivery_status=DELIVERY_STATUS_MANUAL.
3. The |retrieveMMS| checks some status and changes the delivery_status to DELIVERY_STATUS_PENDING. Then we need to notify the Messaging AP this status change. It is the moment of onretrieving event fired.
4. After that, retrieveMMS is trying to build a data connection and do a HTTP request "POST" on a content location.
5. If everything is good, we get the message and save the retrieved message and change the delivery=DELIVERY_RECEIVED and delivery_status =DELIVERY_STATUS_SUCCESS. Then notify the Messaging AP the retrieved message via aRequest.notifyMessageGot(domMessage).
6. The flow of aRequest.notifyMessageGot is MobileMessageCallback::notifyMessageGot -> mDOMRequest->FireSuccess -> request.onsuccess in |retrieveMMS| of gaia/apps/sms/js/thread_ui.js. 

Do you mean we should use notifyMessageGot to notify in step 3? The current patch uses Services.obs.notifyObservers(aDomMessage, kSmsRetrievingObserverTopic, null) in step 3.



(In reply to Mounir Lamouri (:mounir) from comment #47)
> Sorry, I do not understand the previous comment. After reading the code, it
> seems that calling retrieveMMS() on m-c will do an HTTP GET on a resource.
> Is that correct? When is the message being on the retrieving state? When the
> HTTP GET starts? Is there other situations when a message can be retrieving?

Comment 49

[Mounir Lamouri (:mounir)]

After discussing with Chia-Hung my feeling is that this isn't needed but if you guys want it to make your life easier, feel free to do so. This API isn't going to be exposed to anything but the Messaging application anyway.

No need to ask for a sr.

Comment 50

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Part 2/2: Patch v1.11

Rebased...

Comment 51

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: b2g18-Part 1/2: Interface v1.0

For uplift to b2g18.

Comment 52

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: b2g18-Part 2/2: Patch v1.0

For uplift to b2g18.

Comment 53

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/projects/birch/rev/a3fcf6de6388
https://hg.mozilla.org/projects/birch/rev/457c9f9544bd

No tests?

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a3fcf6de6388
https://hg.mozilla.org/mozilla-central/rev/457c9f9544bd

Comment 55

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/d0089d140ecb
https://hg.mozilla.org/releases/mozilla-b2g18/rev/cc2546f8a775

Comment 56

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/d0089d140ecb
https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/cc2546f8a775

Comment 57

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Attachment: Follow-up-810099-v1.0

Comment 58

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Comment on attachment 757785 [details] [diff] [review]
Follow-up-810099-v1.0

Fix the rebased error.

Comment 59

[Chia-hung Tai [:ctai :ctai_mozilla :cht]]

Introduce new bug during re-based. Has a follow-up fix "Follow-up-810099-v1.0" to fix it.

Comment 60

[Gene Lian (I already quit Mozilla)]

https://hg.mozilla.org/projects/birch/rev/83b67d255bf3
https://hg.mozilla.org/releases/mozilla-b2g18/rev/997cdbf5d012
https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/8d75614010e4

Comment 61

[Ryan VanderMeulen [:RyanVM]]

(In reply to Gene Lian [:gene] from comment #60)
> https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/8d75614010e4

Unless the patch is v1.1hd-specific or specifically requested, please don't land on v1.1hd. I am merging patches from b2g18 over to it, which makes for cleaner history and avoid missing anything. Double-landing complicates it.

Comment 62

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/83b67d255bf3

Comment 63

[Gene Lian (I already quit Mozilla)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #61)
> (In reply to Gene Lian [:gene] from comment #60)
> > https://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/rev/8d75614010e4
> 
> Unless the patch is v1.1hd-specific or specifically requested, please don't
> land on v1.1hd. I am merging patches from b2g18 over to it, which makes for
> cleaner history and avoid missing anything. Double-landing complicates it.

Got it! Sorry for confusing you. I won't do this next time.