Closed
Bug 977533
Opened 11 years ago
Closed 11 years ago
[SMS] Notification does not vanish when the SMS is read
Categories
(Firefox OS Graveyard :: Gaia::SMS, defect)
Firefox OS Graveyard
Gaia::SMS
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 855165
People
(Reporter: flaburgan, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [closeme 3/12/2014])
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140226030202
Steps to reproduce:
On keon 1.3 today's build by geeksphone
Open the SMS app
Open a conversation with a contact
Receive a SMS from another contact => a notification appears
Quit the actual conversation going back to the list of conversations
Open the conversation where you received the new SMS and read it
You can also reproduce that way, writing to yourself:
Write a SMS to yourself
Quit quickly the conversation, going back to the conversations list, before the SMS is received
Receive your own SMS, a notification is displayed
Open the conversation to read the SMS you just send
Actual results:
The notification is still there even if you read the SMS
Expected results:
The notification should vanish when you open the conversation where you received the SMS
Summary: [SMS] Notification doesn't not vanish when the SMS is read → [SMS] Notification does not vanish when the SMS is read
Updated•11 years ago
|
blocking-b2g: --- → 1.3?
I couldn't reproduce this bug on the latest Buri 1.3
After received a SMS notification and then read it, the notification disappears every time when received
1.3 Environmental Variables:
Device: Buri 1.3
BuildID: 20140227004003
Gaia: ad504390a7a5f094f8967f80a0f29a1e6552535e
Gecko: 6bd9b70a1b6c
Version: 28.0
Firmware Version: v1.2-device.cfg
Keywords: qawanted
Comment 4•11 years ago
|
||
Flaburgan, I think we'll need a little more information from you. For example, do you see the notification vanish sometimes? Can you share more precise steps to reproduce it?
blocking-b2g: 1.3? → ---
Flags: needinfo?(flaburgan)
Hm, is there something more that I described I can say to reproduce?
IMO it could be summarize like this: if you are in the SMS app when you receive a message, and then without exiting the app you open the message, the notification will still be there.
Do you need a logcat or something else?
Flags: needinfo?(flaburgan)
Updated•11 years ago
|
Whiteboard: [closeme 3/12/2014]
Comment 6•11 years ago
|
||
Flaburgan> in which panel are you in the SMS App, when you receive the message? In the thread list? In the "good" thread for the received message? In another thread?
Flags: needinfo?(flaburgan)
In the thread list or in another thread, it doesn't matter. Just don't be in the good thread for the received message, there will be not notification.
Flags: needinfo?(flaburgan)
Updated•11 years ago
|
Comment 9•11 years ago
|
||
I found at least a case where the notification is not removed.
STR:
* be on the thread for number A
* press the "power" button to put the phone in sleep mode
* receive a message from number A
* wake up the phone
* unlock the device
=> the notification should be removed
_this_ is a regression, and we can fix this case in this bug.
blocking-b2g: --- → 1.4?
Whiteboard: [closeme 3/12/2014]
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•11 years ago
|
||
After further thinking, filed bug 981401 instead.
Status: NEW → UNCONFIRMED
blocking-b2g: 1.4? → ---
Ever confirmed: false
Whiteboard: [closeme 3/12/2014]
Should this be marked as a duplicate of bug 979462 or vice versa?
Flags: needinfo?(felash)
Comment 12•11 years ago
|
||
We have several bugs regarding notifications, most of them are not reproducible by us, so.. yeah, I don't know, I'd say it's all dupes.
Flags: needinfo?(felash)
Comment 13•11 years ago
|
||
Ah no sorry this one is 1.3, so maybe it's different. Let's keep it open a little more.
Comment 14•11 years ago
|
||
From the start here I assumed it was due to the work around the new Notification API, but I missed this was happening on 1.3, and therefore we still used the old Notification API.
Now I can definitely reproduce on 1.3. I don't know why QA didn't reproduce, maybe they didn't follow correctly the STR.
This bug is a consequence of using the old Notification API. We had to take decisions around the limitations of the old API.
The main limitation is: there is no way to close a notification from the application using the old API. The notifications are cleared by the system app only. Therefore, in the case we have here, there are 2 solutions:
* we don't send a notification. (a solution could be to use in-app notifications)
* we send a notification but we can't clear it.
We chose the second solution, and it worked like this since version 1.0.
Now, we fixed this in 1.4 (even if we still have some bugs resulting from this work). So I'm gonna dupe against the bug that fixed it in 1.4.
Thanks Flaburgan, and sorry again for not paying attention enough ;)
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 15•11 years ago
|
||
No problem, if it's fixed in 1.4 it's really cool :) Sorry for the 1.3 users :p
You need to log in
before you can comment on or make changes to this bug.
Description
•