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
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: firstname.lastname@example.org
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
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+ → ---
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.
Leo please check the time range if you can reproduce this.
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,
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
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)
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+]
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.