1084126 - [WAP Push] No message is received if a new message is pushed that shares the same SI ID and creation date as an existing message.

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::Wappush, defect)

Description

[Robert Mead [:RobertM]]

Description:
If the device currently has a WAP pushed message with a specific SI ID and creation time and date, and the user creates another WAP push message with the same SI ID and creation time and date, the new message is never received.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141015001201
2) Create a WAP Push message with SI ID and creation time and date and send it to device.
3) Phone should receive message. Do not open it.
4) Create another WAP Push message with same SI ID and creation time and date, but with a different URL and send it.
  
Actual:
The new message is never received.
  
Expected: 
The old message should have been replaced by the new message.
  

Flame 2.1(319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.1
BuildID: 20141015001201
Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3
Gecko: 4853208cb48a
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Notes: I could not make a Logcat as the problem is I never receive the message so there is nothing to log. For this same reason, I did not make a video.
  
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/9370/

Comment 1

[Robert Mead [:RobertM]]

This issue also occurs on Flame 2.2(319mb) and Flame 2.0(319mb)

No WAP push message is received if a new WAP push message is pushed that shares the same SI ID and creation date as an existing WAP push message.

Flame 2.2 

Device: Flame 2.2 Master KK (319mb) (Full Flash)
Build ID: 20141015040201
Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6
Gecko: 62f0b771583c
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 36.0a1 (Master)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


Flame 2.0

Environmental Variables:
Device: Flame 2.0 KK (319mb) (Full Flash)
Build ID: 20141015000206
Gaia: c6c6116ca225c2c934220ae6867e5a3256d65e00
Gecko: 24a2aa6bf1c4
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Unsure if this should be nominated to block. NI for someone else to weigh in on this

Comment 3

[Eric Chang [:ericcc] [:echang]]

Attachment: ril.log

2nd WAP push messages with the same ID is never received, it seems to be normal for a nokia old 3G phone. Flame has the same behavior, logcat attached.
Hi Hsinyi, is that expected?

Comment 4

[Hsin-Yi Tsai (she/her)[:hsinyi]]

Attachment: Duplicate SI - WAP 167 SERVICEEND, 6.2

Per spec,  the old one should be deleted, and the new one is displayed as comment 0.

Comment 5

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Eric & Robert,

After further study of WAP Service Indication [1], there is some thing confusing regarding to the case  when received SI with identical |si-id| and |created| attributes.
In the step (3) of |Figure 2 Steps involved in processing a received SI| in 6.2 Reception: 
"
  "Received SI newer (or of the same age) than other SI with identical si-id? Y-> Deleted Old SI.
"

However, in sub-clause |3. Replacement| in 6.2 Reception:
"
  ....... MUST replace the old SI. If the received SI and another SI with identical |si-id| contain 
  identical values for the |created| attribute, the received SI MUST be silently discarded.
"

We are not able to verdict that, in this case, the received SI with identical |si-id| and |created| attribute shall be displayed or not.

The only thing that is confirmed according to the spec is to delete the old SI with the newer one according to the |created| attribute if their si-id are identical.

For this bug, what we can discuss in advance is that
1. Is this test case reasonable? Is this a real use case?
2. If yes, we might need UX's help to define a reasonable behavior for this scenario for Gaia to follow up.
3. What's the behavior on other reference phones?
   The more we compare; the the more reasonable behavior we can define.

[1] http://technical.openmobilealliance.org/Technical/Release_Program/docs/Push/V2_3-20111122-A/WAP-167-ServiceInd-20010731-a.pdf

Comment 6

[Eric Chang [:ericcc] [:echang]]

Checked on several devices.
1. Sony 4.4.4 - not receiving any WAP push
2. iPhone 8.1 - not receiving any WAP push
3. Nexus 4.4.4 - not receiving any WAP push 

4. Samsung 4.4.2 - The old message has been replaced by the new message(as comment #0 suggested)

5. Nokia feature phone - not receiving the 2nd WAP push, just the 1st one
6. Flame v2.1 - not receiving the 2nd WAP push, just the 1st one
7. HTC 4.4.4 - not receiving the 2nd WAP push, just the 1st one 
  
Hi Steve, Need your help to fix here on the WAP push, here are the behavior on different platforms, thanks..

Comment 7

[Steve Chung [:steveck]]

Gabriele is definitely a better candidate than me to answer the detail wap push implementation.

Comment 8

[Gabriele Svelto [:gsvelto]]

Indeed I misunderstood subclause 3 in paragraph 6.2 of the spec when implementing the patch for bug 911947. The offending line is this one:

https://github.com/mozilla-b2g/gaia/blob/84a5bf6632d559bb690d2134fc4b9ef19d9b78cc/apps/wappush/js/messagedb.js#L170

I'll prepare a (one-line) fix ASAP.

Comment 9

[Gabriele Svelto [:gsvelto]]

Attachment: [PATCH] Do not discard incoming messages with the same 'si-id' and 'created' fields as an already received one

Super-easy fix, it's just a one-line change but I've made sure that we've got a new unit-test covering this particular scenario.

Comment 10

[Julien Wajsberg [:julienw]]

From comment 5 and comment 6, I think we behave correctly.

As far as I understand, in the spec, the image is not authoritative, but the text is. Therefore we should conform to the text, and the text says we should discard the received SI, which is our current behavior.

What do you think Gabriele?

Comment 11

[Gabriele Svelto [:gsvelto]]

(In reply to Julien Wajsberg [:julienw] from comment #10)
> What do you think Gabriele?

Now that you mention it yes, we're already compliant with the text. Subclause 3 is worded in such a way that it confuses me :-/

Comment 12

[Gabriele Svelto [:gsvelto]]

Closing as invalid as per the discussion above, reopen with a comment describing why if you feel that this is the wrong decision.