Closed Bug 980143 Opened 10 years ago Closed 9 years ago

[Sora][Certification][MMS]MS can't receive MMS continuously by teleca tool.

Categories

(Firefox OS Graveyard :: RIL, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: sync-1, Assigned: bevis)

Details

Attachments

(4 files)

Firefox OS v1.3
 Mozilla build ID: 20140226004002
 
 DEFECT DESCRIPTION:
 ->MS can't receive MMS continuously by teleca tool.
  REPRODUCING PROCEDURES:
 ->Use teleca tool send the MMS to our test MS;
 ->MS only received a MMS,and other MMS can't be received.(ko)
  
 note: We use teleca tool to send mms for test GCF case, if this function is block, we can't pass the GCF certification easily.
 
  EXPECTED BEHAVIOUR:
 ->Should received the MMS by teleca tool normally.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
Does this reproduce on 1.1 Buri?
Flags: needinfo?(sync-1)
We had some MMS issues with some CommRIL version, are we sure they have an uptodate version of CommRIL?
(In reply to Jason Smith [:jsmith] from comment #1)
> Does this reproduce on 1.1 Buri?

Yes.
Flags: needinfo?(sync-1)
This is the logcat about why teleca can't receive mms continuously.
Dear felash@gmail.com,

This function is important to us because all of the mms functions will be test by teleca in our lab.
But now this tools can't work normally on our FFOS system.
It will block our certification in the future.

During analyze ths logcat, I think most of the problems are in the MmsService.js in Gecko/dom/MobileMessage. 
Maybe it was caused by M-acknowledge.ind can't sent to MMSC after retrieve the the first mms. 
All of the follow mms have the same x-mms-transaction-id, thus the mms notification can't be deal with any longer.

BRs,
TIAN Min
Flags: needinfo?(felash)
Dear Julien Wajsberg,
I am waiting for your reply.
BRs,
TIAN Min
Bevis will help you here, I can't :)
Flags: needinfo?(felash) → needinfo?(btseng)
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.0?
(In reply to 田旻 from comment #5)
> Dear felash@gmail.com,
> 
> This function is important to us because all of the mms functions will be
> test by teleca in our lab.
> But now this tools can't work normally on our FFOS system.
> It will block our certification in the future.
> 
> During analyze ths logcat, I think most of the problems are in the
> MmsService.js in Gecko/dom/MobileMessage. 
> Maybe it was caused by M-acknowledge.ind can't sent to MMSC after retrieve
> the the first mms. 
> All of the follow mms have the same x-mms-transaction-id, thus the mms
> notification can't be deal with any longer.
> 
> BRs,
> TIAN Min

Hi 田旻,

Since this problem was targeted in 2.0, 
1. Can we reproduce this problem in 2.0 and have adb logcat & tcpdump for further analysis?
   (https://github.com/bevis-tseng/Debug_Tools)
2. From the log, I found that the ACK was rejected by network instead.
   (I/Gecko   (  284): -@- MmsService: xhr done, but status = 403, statusText = Forbidden)
   Is there any configuration problem about this testing tool instead?
   Or can the test tool identify why the ACK was rejected?

Thanks!
Flags: needinfo?(btseng)
Assignee: nobody → btseng
Flags: needinfo?(sync-1)
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #9)
> Hi 田旻,
> 
> Since this problem was targeted in 2.0, 
> 1. Can we reproduce this problem in 2.0 and have adb logcat & tcpdump for
> further analysis?
>    (https://github.com/bevis-tseng/Debug_Tools)
> 2. From the log, I found that the ACK was rejected by network instead.
>    (I/Gecko   (  284): -@- MmsService: xhr done, but status = 403,
> statusText = Forbidden)
>    Is there any configuration problem about this testing tool instead?
>    Or can the test tool identify why the ACK was rejected?
> 
> Thanks!

In addition, can we have MMS APN settings for this testing?

Thanks!
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #10)
> (In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #9)
> > Hi 田旻,
> > 
> > Since this problem was targeted in 2.0, 
> > 1. Can we reproduce this problem in 2.0 and have adb logcat & tcpdump for
> > further analysis?
> >    (https://github.com/bevis-tseng/Debug_Tools)
> > 2. From the log, I found that the ACK was rejected by network instead.
> >    (I/Gecko   (  284): -@- MmsService: xhr done, but status = 403,
> > statusText = Forbidden)
> >    Is there any configuration problem about this testing tool instead?
> >    Or can the test tool identify why the ACK was rejected?
> > 
> > Thanks!
> 
> In addition, can we have MMS APN settings for this testing?
> 
> Thanks!

Dear  Bevis Tseng,
1. Our lab can't test on v2.0 because they didn't have that kind of phone.
2. When mms if failed, there isn't any response on teleca tools.
2,Settings of APN:
APN:3gwap (our Unicom sim card)
MMS proxy: The IP address of our outer internet
MMS port:8080
MMSC:http://+ our computer's local IP address。
Comms triage: not blocking, no user impact, no regression.
blocking-b2g: 2.0? → ---
Hi 田旻,

There is one thing strange in your MMS configuration:
You said that the MMSC was set to "http://+ our computer's local IP address".
However, the MMSC from the log is the one for China Unicom "http://mmsc.myuni.com.cn" 
instead of your test MMSC.
The ACK is reasonable to be rejected by the China Unicom's MMSC if the retrieved Message was
not actually delivered from it.
It might also be the reason why the teleca tool didn't get any response from the device.

Here is the MMS configuration I saw from the log for your reference.
MMS Proxy: 222.66.88.205, Port: 8080
content location: http://172.31.2.27/tc30a
MMSC: http://mmsc.myuni.com.cn

Can you help to clarify if its the configuration problem instead?

If not, would you please help to 
1. collect the adb logcat with corresponding tcpdump and tell us which firefox os version did you test.
2. provide the tcpdump of other reference phone that pass the test case.

Thanks!
We use FFOS v1.3 (Mozilla build ID:20140422024003).
I will give you the compare file as soon as possible.
Attached file fire fox.tar.gz
Dear Bevis Tseng,

Please check the tcpdump and logcat of FFOS and android as comparison. 
BRs,
TIAN Min
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #13)
> Hi 田旻,
> 
> There is one thing strange in your MMS configuration:
> You said that the MMSC was set to "http://+ our computer's local IP address".
> However, the MMSC from the log is the one for China Unicom
> "http://mmsc.myuni.com.cn" 
> instead of your test MMSC.
> The ACK is reasonable to be rejected by the China Unicom's MMSC if the
> retrieved Message was
> not actually delivered from it.
> It might also be the reason why the teleca tool didn't get any response from
> the device.
> 
> Here is the MMS configuration I saw from the log for your reference.
> MMS Proxy: 222.66.88.205, Port: 8080
> content location: http://172.31.2.27/tc30a
> MMSC: http://mmsc.myuni.com.cn

Hi 田旻,

I still need your help to clarify if the configuration of the test device is correct.
It looks incorrect to me as mentioned in comment 13.
(The MMSC was set to the China Unicom's instead of your test server)
With the last ffos log in comment 15, the symptom is different now.
The root cause is that the message from test server always tagged with the same transaction id that has already be available in the message database.
That means the message is duplicated and will be ignored if received again. [1]

[1] http://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/MmsService.js#1904
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Flags: needinfo?(sync-1)
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #18)
> With the last ffos log in comment 15, the symptom is different now.
> The root cause is that the message from test server always tagged with the
> same transaction id that has already be available in the message database.
> That means the message is duplicated and will be ignored if received again.
> [1]
> 
> [1]
> http://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/
> MmsService.js#1904

But why the server always send the same transaction id to FFOS phoen but not other phone?
It behaves ok on other phone.
What's more, the first log I give you has the same reason which is always have the same transaction id.
Thus please don't close this bug.
(In reply to 田旻 from comment #19)
> But why the server always send the same transaction id to FFOS phoen but not
> other phone?
> It behaves ok on other phone.

For this 1st ffos log, the problem shall be caused by incorrect mmsc configuration. That cause the ACK sent to the wrong server.
For 2nd ffos log provided today, the ACK was sent properly but the next incoming message is duplicated and has been rejected in purpose.

Did you double confirm if the test server sent multiple messages to other reference phone with different transaction id?
I didn't see any information about this from the android log.
In addition, I didn't found the tcpdump from the android logs to prove this as well. :(
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: INVALID → ---
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #21)
> For this 1st ffos log, the problem shall be caused by incorrect mmsc
> configuration. That cause the ACK sent to the wrong server.
> For 2nd ffos log provided today, the ACK was sent properly but the next
> incoming message is duplicated and has been rejected in purpose.
> 
> Did you double confirm if the test server sent multiple messages to other
> reference phone with different transaction id?
> I didn't see any information about this from the android log.
> In addition, I didn't found the tcpdump from the android logs to prove this
> as well. :(

In addition, we can double check what's going on in the test server side as well?
1. Did test server receive the corresponding ACK?
2. Did the test server always deliver MMS with different transaction-id?

Thanks!
Flags: needinfo?(sync-1)
2 Wap Push received in android's log contains the same raw PDU of the MMS notification:
09-24 10:29:50.556  1291  1665 D WAP PUSH: Rx: 0406376170706c69636174696f6e2f766e642e7761702e6d6d732d6d65737361676500456e636f64696e672d76657273696f6e00312e3100af848c82983132008d928910802b38363133393136313337313435009605804d4d53008a808e02255f88058103093a8083687474703a2f2f3137322e32342e3231322e32362f746333306100
09-24 10:31:50.764  1291  1665 D WAP PUSH: Rx: 0406376170706c69636174696f6e2f766e642e7761702e6d6d732d6d65737361676500456e636f64696e672d76657273696f6e00312e3100af848c82983132008d928910802b38363133393136313337313435009605804d4d53008a808e02255f88058103093a8083687474703a2f2f3137322e32342e3231322e32362f746333306100

This indirectly proves the transaction-id of the incoming messages are delivered with the same transaction -id.

The reasonable explanation is that android device didn't use the transaction-id to check the duplicated mms message. :(

I've no idea what is the test criteria of this test case.
Another way to pass the test case is to always delete the received message before running next test case.
Component: Gaia::SMS → RIL
Dear  Bevis Tseng,
All of these two FFOS logs are fail, their root cause is "MmsService: xhr success, response headers....". 
This is what I guess:
All the content could be retreived, but a ack (which is just header information) should be give to the mmsc about the retrieve is ok, and then next transaction-id could be added by itself.
BRs,
TIAN Min
Maybe it was caused by M-acknowledge.ind can't sent to MMSC after retrieve the the first message.
Hi 田旻,

From both the tcpdump and the logcat, the m-ack-ind was sent successfully from FFOS device to the mmsc with postive status 200 OK.
The "MmsService: xhr success" indicates positive response appended with ResponseHeaders dump to the logs.

By my understanding, the difference between FFOS & AOSP is what I mentioned in comment 23 about how the duplicated messages are identified, and the implementation in FFOS is located at [1].

Regards,
Bevis Tseng

[1] http://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/MmsService.js#1904
Dear  Bevis Tseng,

Why mms with same transaction -id can't be received?
I check the android tcpdump which I add in the attachment, while it can retrive the mms with same transaction -id.

Can we modified our mms database and support this kind of message with the same transaction -id?

BRs,
TIAN Min
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #26)
> Hi 田旻,
> 
> From both the tcpdump and the logcat, the m-ack-ind was sent successfully
> from FFOS device to the mmsc with postive status 200 OK.
> The "MmsService: xhr success" indicates positive response appended with
> ResponseHeaders dump to the logs.
> 
> By my understanding, the difference between FFOS & AOSP is what I mentioned
> in comment 23 about how the duplicated messages are identified, and the
> implementation in FFOS is located at [1].
> 
> Regards,
> Bevis Tseng
> 
> [1]
> http://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/
> MmsService.js#1904
Why I can't see "M-acknowledge.ind" in Android log?
Hi 田旻,

The transaction-id is the unique identifier between MMS Client & MMSC/MMS Proxy.
Due to unstable network environment, it is possible to receive the same MMS notification multiple times.
That's why we address this in bug 810091.

Regards,
Bevis Tseng
(In reply to 田旻 from comment #28)
> Why I can't see "M-acknowledge.ind" in Android log?
There is no corresponding tcpdump from Android device.
I don't have too much information to know what's going on.
This compression bag contains the android tcp dump file as a comparison.
According to the transactions in the tcpdump of Android device:
1. all the received message are delivered with the same transaction-id == 12 as well.
(This is test suite problem.)
2. There is no M-Acknowledge.ind but only M-NotifyResp.ind because auto-retrieval is applied.
(The call flow is compliant with Figure 5: Example MMSM Transaction Flow – Immediate Retrieval in [1])

In FFOS, we have M-Acknowledge.ind because from the logcat, I saw that the message was manually retrieved instead which is compliant with Figure 6: Example MMSM Transaction Flow – Deferred Retrieval in [1].

[1] http://technical.openmobilealliance.org/Technical/release_program/docs/MMS/V1_3-20110913-A/OMA-TS-MMS_CTR-V1_3-20110913-A.pdf
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #32)
> According to the transactions in the tcpdump of Android device:
> 1. all the received message are delivered with the same transaction-id == 12
> as well.
> (This is test suite problem.)
> 2. There is no M-Acknowledge.ind but only M-NotifyResp.ind because
> auto-retrieval is applied.
> (The call flow is compliant with Figure 5: Example MMSM Transaction Flow –
> Immediate Retrieval in [1])
> 
> In FFOS, we have M-Acknowledge.ind because from the logcat, I saw that the
> message was manually retrieved instead which is compliant with Figure 6:
> Example MMSM Transaction Flow – Deferred Retrieval in [1].
> 
> [1]
> http://technical.openmobilealliance.org/Technical/release_program/docs/MMS/
> V1_3-20110913-A/OMA-TS-MMS_CTR-V1_3-20110913-A.pdf

1. No, it's not test suite problem, because validation partner just send the same test case twice.
2. Our FFOS phone is also auto-retrieval in the second FFOS log.
3. Because MMSC can't get the right ack, thus the same message with transaction-id is send once more for our FFOS phone, it's the same messsage. 
All of the errors are like this:
"xhr success, response headers....X-Cache: MISS from squid-sh"
OR 
“xhr done, response headers...403 error"

Last and the most important, our mms version is v1.1.
(In reply to 田旻 from comment #33)
> 1. No, it's not test suite problem, because validation partner just send the
> same test case twice.
> 2. Our FFOS phone is also auto-retrieval in the second FFOS log.
> 3. Because MMSC can't get the right ack, thus the same message with
> transaction-id is send once more for our FFOS phone, it's the same messsage. 
> All of the errors are like this:
> "xhr success, response headers....X-Cache: MISS from squid-sh"
> OR 
> “xhr done, response headers...403 error"
> 
> Last and the most important, our mms version is v1.1.

Let me list what I saw from the 2nd ffos logs/tcpdump (It's manually retrieval) and 
what it represents to you again:
1. MmsService received a WapPush message which represents a MMS-Notification:

09-24 09:51:21.830    88    88 I Gecko   : -@- MmsService: receiveWapPush: msg = {"headers":{"x-mms-message-type":130,"x-mms-transaction-id":"12","x-mms-mms-version":18,"from":{"address":"+8613916137145","type":"num"},"x-mms-message-class":"personal","x-mms-message-size":9567,"x-mms-expiry":604800,"x-mms-content-location":{"uri":"http://172.31.2.27/tc30a"}},"type":130}

2. MmsService reply M-NotifyResp.ind to MMSC with positive response due to deferred download is set.

09-24 09:51:25.640    88    88 I Gecko   : -@- MmsService: xhr success, response headers: X-Cache: MISS from squid-sh

3. User clicked download button after 9 seconds, as message was downloaded successfully:

09-24 09:51:33.220    88    88 I Gecko   : -@- MmsService: Retrieving message with ID 16
09-24 09:51:33.280    88    88 I Gecko   : -@- MmsService: sendRequest: register proxy filter to http://172.31.2.27/tc30a
09-24 09:51:35.310    88    88 I Gecko   : -@- MmsService: xhr success, response headers: Content-Type: application/vnd.wap.mms-message
09-24 09:51:35.310    88    88 I Gecko   : Content-Length: 124
09-24 09:51:35.310    88    88 I Gecko   : X-Cache: MISS from squid-sh

4. MmsSerive sends M-acknowledge-ind to MMSC with positive response:

09-24 09:51:35.540    88    88 I Gecko   : -@- MmsService: sendRequest: register proxy filter to http://172.31.2.27
09-24 09:52:17.930    88    88 I Gecko   : -@- MmsService: xhr success, response headers: X-Cache: MISS from squid-sh

5. MmsService receives 2nd MMS notification with the same transaction-id and we reject it:

09-24 09:53:38.460    88    88 I Gecko   : -@- MmsService: receiveWapPush: msg = {"headers":{"x-mms-message-type":130,"x-mms-transaction-id":"12","x-mms-mms-version":18,"from":{"address":"+8613916137145","type":"num"},"x-mms-message-class":"personal","x-mms-message-size":9567,"x-mms-expiry":604800,"x-mms-content-location":{"uri":"http://172.31.2.27/tc30a"}},"type":130}
09-24 09:53:38.480    88    88 I Gecko   : -@- MmsService: We already got the NotificationIndication with transactionId = 12 before.

In addition, we set MMS version to v1.1 because vCal/vCard required in 1.3 was not supported from application level yet.

No matter it's v1.1 or v1.3, the Transaction flow are the same for immediate/deffered retrieval:
Please see follow figures in 1.1v as well [1]:
Figure 5. Example MMSM Transaction Flow – Immediate Retrieval
MMSC/Proxy                          MMS Client
           - M-Notification.ind ->
           <-   HTTP GET.req     -
           -   M-retrieve.conf  ->
           <  M-NotifyResp.ind   -
Figure 6. Example MMSM Transaction Flow – Deferred Retrieval
MMSC/Proxy                          MMS Client
           - M-Notification.ind ->
           -  M-NotifyResp.ind   -
                      ...
           <-   HTTP GET.req     -
           -   M-retrieve.conf  ->
           <- M-Acknowledge.ind  -

[1] http://technical.openmobilealliance.org/Technical/Release_Program/docs/MMS/V1.1-29949715-A/OMA-WAP-MMS-CTR-V1_1-20040715-A.pdf
Dear Bevis Tseng,
 What dose "xhr success, response headers: X-Cache: MISS from squid-sh" mean?
I think MMSC didn't receive a right M-Acknowledge.ind according this.
Look at your point 5, MmsService receives 2nd MMS notification. Actually, they are the same one.
Because they have the same content.
But When I ask our validation partner, she said she send different MMS.
My skype account is "tianmin17", if you like we can talk with skype.
It will be much easier to communicate.
BRs,
TIAN Min
(In reply to 田旻 from comment #35)
> Dear Bevis Tseng,
>  What dose "xhr success, response headers: X-Cache: MISS from squid-sh" mean?
> I think MMSC didn't receive a right M-Acknowledge.ind according this.
This has been explained in comment 26.
If you look into both FFOS/Android's tcpdump for the "HTTP 200 OK" response,
it just the first line of this response content printed out by the log.
The thing we need to care is whether the Status Code is 200 OK, 
and it is 200 OK for both FFOS and Android.

> Look at your point 5, MmsService receives 2nd MMS notification. Actually,
> they are the same one.
> Because they have the same content.
> But When I ask our validation partner, she said she send different MMS.
No, as what I mentioned in comment 32, even in the tcpdump from Android, these 2 MMS are the same with a drm image called "int-3.dm".

The only reason that FFOS/Android behave different has already been mentioned in comment 23 is whether we want to identify the duplicated message by transaction id.
(In reply to 田旻 from comment #36)
> My skype account is "tianmin17", if you like we can talk with skype.
> It will be much easier to communicate.
> BRs,
> TIAN Min

Probably easier for you to discuss in chinese ;) but please update the bug once you found the issue.
(In reply to Julien Wajsberg [:julienw] from comment #38)
> (In reply to 田旻 from comment #36)
> > My skype account is "tianmin17", if you like we can talk with skype.
> > It will be much easier to communicate.
> > BRs,
> > TIAN Min
> 
> Probably easier for you to discuss in chinese ;) but please update the bug
> once you found the issue.
ok.
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #37)
> (In reply to 田旻 from comment #35)
> > Dear Bevis Tseng,
> >  What dose "xhr success, response headers: X-Cache: MISS from squid-sh" mean?
> > I think MMSC didn't receive a right M-Acknowledge.ind according this.
> This has been explained in comment 26.
> If you look into both FFOS/Android's tcpdump for the "HTTP 200 OK" response,
> it just the first line of this response content printed out by the log.
> The thing we need to care is whether the Status Code is 200 OK, 
> and it is 200 OK for both FFOS and Android.
> 
> > Look at your point 5, MmsService receives 2nd MMS notification. Actually,
> > they are the same one.
> > Because they have the same content.
> > But When I ask our validation partner, she said she send different MMS.
> No, as what I mentioned in comment 32, even in the tcpdump from Android,
> these 2 MMS are the same with a drm image called "int-3.dm".
> 
> The only reason that FFOS/Android behave different has already been
> mentioned in comment 23 is whether we want to identify the duplicated
> message by transaction id.
I think you are right.
Can we hace some ways to deal with this problems?
(In reply to 田旻 from comment #40)
> (In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #37)
> > (In reply to 田旻 from comment #35)
> > > Dear Bevis Tseng,
> > >  What dose "xhr success, response headers: X-Cache: MISS from squid-sh" mean?
> > > I think MMSC didn't receive a right M-Acknowledge.ind according this.
> > This has been explained in comment 26.
> > If you look into both FFOS/Android's tcpdump for the "HTTP 200 OK" response,
> > it just the first line of this response content printed out by the log.
> > The thing we need to care is whether the Status Code is 200 OK, 
> > and it is 200 OK for both FFOS and Android.
> > 
> > > Look at your point 5, MmsService receives 2nd MMS notification. Actually,
> > > they are the same one.
> > > Because they have the same content.
> > > But When I ask our validation partner, she said she send different MMS.
> > No, as what I mentioned in comment 32, even in the tcpdump from Android,
> > these 2 MMS are the same with a drm image called "int-3.dm".
> > 
> > The only reason that FFOS/Android behave different has already been
> > mentioned in comment 23 is whether we want to identify the duplicated
> > message by transaction id.
> I think you are right.
> Can we hace some ways to deal with this problems?

Hi 田旻,

As pointed out in comment 26, this is where we identify the duplicated MMS. [1]

If you don't like this check, maybe you can have your-own logic to pass the test tool.
for example, you can change it from:
  if (Components.isSuccessCode(aRv) && aMessageRecord)
to
  if (Components.isSuccessCode(aRv) && aMessageRecord && (aMessageRecord.delivery === DELIVERY_NOT_DOWNLOADED))
  - to lose the condition of the duplicated message only if it was not downloaded.
Or something else.

[1] http://dxr.mozilla.org/mozilla-central/source/dom/mobilemessage/gonk/MmsService.js#1902
Dear  Bevis Tseng,
I modified this if (Components.isSuccessCode(aRv) && aMessageRecord) as if (Components.isSuccessCode(aRv) && aMessageRecord && transactionId != '12'), but it not work.
Dear  Bevis Tseng,
I modified this if (Components.isSuccessCode(aRv) && aMessageRecord) as if (Components.isSuccessCode(aRv) && aMessageRecord && transactionId !== '12'), but it not work.
no further action on this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(sync-1)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: