Closed Bug 889207 Opened 7 years ago Closed 7 years ago

[leo-pre-iot-br] [SMS] The message received before 12:00(AM) midnight is shown as TODAY in thread_list

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect, P2)

ARM
Gonk (Firefox OS)

Tracking

(blocking-b2g:leo+, b2g18 fixed, b2g-v1.1hd fixed)

RESOLVED FIXED
1.1 QE4 (15jul)
blocking-b2g leo+
Tracking Status
b2g18 --- fixed
b2g-v1.1hd --- fixed

People

(Reporter: leo.bugzilla.gaia, Assigned: oconnore)

References

Details

(Whiteboard: [u=commsapps-user c=messaging p=0.1], TaipeiMMS, [LeoVB+] )

Attachments

(2 files)

1. Title: The message received before 12:00(AM) midnight is shown as TODAY in thread_list
2. Precondition: Device should be able to send and receive SMS
3. Tester's Action: 1) Receive a message during 11:59 PM
                                 2) Open the message after sometime (12:00AM).
4. Detailed Symptom (ENG.) : The received message is shown as TODAY in thread_list but this is shown with proper timing in the particular thread
5. Expected: The received message should be shown with proper timing even in the thread_list 
6. Reproducibility: Y
1) Frequency Rate : 100%
7. Gaia Master/v1-train: Reproduced on v1-train
8. Gaia Revision:  613e69ee0a009399130ad2cbb8b9d0462cd1fc70
9. Personal email id: sasikala.paruchuri8@gmail.com
blocking-b2g: --- → leo+
Summary: [SMS] The message received before 12:00(AM) midnight is shown as TODAY in thread_list → [leo-pre-iot-br] [SMS] The message received before 12:00(AM) midnight is shown as TODAY in thread_list
Assignee: nobody → eric
Priority: -- → P2
Whiteboard: [u=commsapps-user c=messaging p=0]
Priority: P2 → P1
QAWANTED - can we check if this only occurs to sms's received during 11:59 or if the problem timespan is longer.

Leo- for now, if the timespan is larger than the 1 minute, please renom
blocking-b2g: leo+ → ---
Flags: needinfo?(pyang)
Keywords: qawanted
I've tried
gaia 1436e2778b90bd74635b0b94d1cf8ccb0d71b60c
build id = 201306250702

Can't reproduce this issue.
leo, can you try latest build and see if it is reproducible? thanks.
Flags: needinfo?(pyang)
Keywords: qawanted
Leo please check the time range if you can reproduce this.
Flags: needinfo?(leo.bugzilla.gaia)
Attached image unagi screenshot
Wayne: I tested with -5 / +5 minutes today on master.
Hi Wayne,
This issue is reproducible even with other timings.
Tried reproducing with 9:30 PM,10:00PM and 11:25PM.
Thanks,
Flags: needinfo?(leo.bugzilla.gaia)
Leo+ing per previous triage agreement, the bug gives false information to the user.

Eric, if you are able to consistently reproduce this, can you check if you're able to take it?
blocking-b2g: --- → leo+
Whiteboard: [u=commsapps-user c=messaging p=0] → [u=commsapps-user c=messaging p=0], TaipeiMMS
Priority: P1 → P2
Target Milestone: --- → 1.1 QE4 (15jul)
Attached file Pull request on github
This pull request also relies on commits:

5b1eb2258d7ef6c184a098b71705bf67f913af47
cae0a723b823ed86048a0dec7073b34cae137bb9

for bugs 890460 and 885278, respectively, being uplifted into v1-train.
Attachment #775040 - Flags: review?(gnarf37)
Depends on: 890460, 885278
Comment on attachment 775040 [details] [review]
Pull request on github

Because I worked on this lately, I added comments on github (but have not actually tried the code so Corey please do a full review :) )
After the work done by Julien, probably this fix should be only to modify the param of the `setInterval` to 60000 instead of 50000. Wdyt?
Comment on attachment 775040 [details] [review]
Pull request on github

We had some issues related with the updating of the `fixedHeaders`, that's why we had the `today` header stuck in SMS App. Currently we need only to adjust the setInterval param to be 60s (actually Julien did some tests about this functionality!). I would modify only this param for having the sync. between updates.
Attachment #775040 - Flags: review?(gnarf37) → review-
Whiteboard: [u=commsapps-user c=messaging p=0], TaipeiMMS → [u=commsapps-user c=messaging p=0.1], TaipeiMMS
Borja, what would changing setInterval to 60000 accomplish? setInterval is not synchronized to the clock. The situation would just be slightly worse than it is now. 

The patch I supplied updates the header at 12:00:00, as the user would expect.
Attachment #775040 - Flags: review- → review?(fbsc)
I just noticed you cleared the review require I made of Corey. Would you mind revisiting this?
Comment on attachment 775040 [details] [review]
Pull request on github

r=me
Attachment #775040 - Flags: review?(fbsc) → review+
What about using navigator.mozAlarms? Check https://developer.mozilla.org/es/docs/WebAPI/Alarm
I'm not sure that we need mozAlarms - That is going to be a little overkill for the situation.  From what I understand about that API, it will actually wake the phone back up to fire that alarm.   If the phone is sleeping, we should let it sleep with the occasional timeout to handle the updates.  setTimeout works fine for our situation here, and I'd rather see a setTimeout loop than a setInterval any day.
Let's move forward and merge this if is reviewed! It's ok for me.
Whiteboard: [u=commsapps-user c=messaging p=0.1], TaipeiMMS → [u=commsapps-user c=messaging p=0.1], TaipeiMMS, [LeoVB+]
v1.1.0hd: 1814390e37f840ba7116bc400b628199d63440ea
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.