962974 - [WAP push] Opening WAP push/CP message via tapping new message notification directly without scroll down utility tray first, then exit message via power or home key, an expired message will be kept on notification bar.

Status: RESOLVED FIXED

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

Description

[Enpei]

Attachment: time stamp: 14:32, 1/23.

When screen timeout while one CP message is opened, the message will be gone after resume device.

Probably this is current notification design but it's really not user friendly. If user has opened the CP message but then is interrupted by other things, once he/she comes back and tries to re-read the message, message is gone. 

* Build Number  
Fugu
Gaia      6fbeac2415f07f10de181f0877ddf67ee299b885
Gecko     086e69971516130ad297c7f950dfb42a995217e9
BuildID   20140123115514
Version   28.0a2

* Reproduce Steps
1. Got a OMA CP message from carrier. (or send a OMA CP message to DUT via NowSMS)
2. Open the CP message.
3. Press power key to suspend device.
4. Resume device

* Expected Result
CP message opened in step 2 is still there.

* Actual Result
CP message will be gone from notification bar.

* Occurrence rate
100%

Comment 1

[Enpei]

Build number is not correct on previous comment. It's tested on Buri.

* Build Number  
Gaia      a6f1bc96ac9e0a32022c75f0ee7771a2ab9050db
Gecko     http://hg.mozilla.org/mozilla-central/rev/b739b3354222
BuildID   20140122154850
Version   29.0a1

Comment 2

[Enpei]

Update occurrence rate, it's not 100%, I found this bug twice(including once after reset phone), other time the behavior is the same as bug 962977.

Comment 3

[Julien Wajsberg [:julienw]]

When you say "suspend", do you mean "power down" ?
Then it's really bug 874364.

If you merely disable the screen without stopping the device, I really think the notification should not leave, and it would be a System app bug.

Can you look if that happen for other notifications (eg SMS?)

Comment 4

[Enpei]

(In reply to Julien Wajsberg [:julienw] from comment #3)
> When you say "suspend", do you mean "power down" ?
> Then it's really bug 874364.
> 
> If you merely disable the screen without stopping the device, I really think
> the notification should not leave, and it would be a System app bug.
> 
> Can you look if that happen for other notifications (eg SMS?)

Hi Julien, suspend here means turn off display, that's it. The reason why I open this bug is more like user experience bug. I met the bug when I got a CP message from carrier, then I opened it and entered PIN code, before next step to apply it, I was interrupted by other thing and took some time which is over device display timeout. When I came back and would like to proceed CP message saved job, I resumed display by pressing power key, but the message is gone, can't be found on notification bar anymore. 

The CP message I got is not sent by what I've done to trigger it. It's sent by carrier automatically the first time I insert this SIM to device. So for some users they might just lose the messages and don't know how to get the message again. That's why I file this bug.

Comment 5

[Julien Wajsberg [:julienw]]

Yes I understand better now, and I perfectly agree with you.

I think I got the same issue when I was in Taipei too, and it was very confusing and frustrating.

Using the new Notification API it should be easy to remove the notification only when the message is deleted from the DB.

Gabriele, Alexandre, what do you think ?

Comment 6

[:gerard-majax]

I'm wondering if after all it's not a dupe of bug 962977 ... Looking at the logcat attached:

01-23 14:29:17.942 E/GeckoConsole(  136): [JavaScript Error: "A promise chain failed to handle a rejection.
01-23 14:29:17.942 E/GeckoConsole(  136): 
01-23 14:29:17.942 E/GeckoConsole(  136): Date: Thu Jan 23 2014 14:20:14 GMT+0800 (CST)
01-23 14:29:17.942 E/GeckoConsole(  136): Full Message: Error: Cannot reset worker: The following files are still open:
01-23 14:29:17.942 E/GeckoConsole(  136): /data/b2g/mozilla/j5swamvm.default/notificationstore.json
01-23 14:29:17.942 E/GeckoConsole(  136): Full Stack: File.resetWorker/<@resource://gre/modules/osfile/osfile_async_front.jsm:1129
01-23 14:29:17.942 E/GeckoConsole(  136): Handler.prototype.process@resource://gre/modules/Promise.jsm:767
01-23 14:29:17.942 E/GeckoConsole(  136): this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm:531
01-23 14:29:17.942 E/GeckoConsole(  136): " {file: "resource://gre/modules/osfile/osfile_async_front.jsm" line: 1129 column: 0 source: "1129"}]
01-23 14:29:17.942 E/GeckoConsole(  136): [JavaScript Error: "A promise chain failed to handle a rejection.

Comment 7

[:gerard-majax]

And by a dupe, I mean "the notification does not disappears because somehow we don't call .close()"

Comment 8

[:gerard-majax]

Enpei, could you retry after applying the gecko patch of bug 963035 and making sure you start with a clean profile ?

My expectation is that the cause of the issue is this missing file.close() bug.

Comment 9

[Gabriele Svelto [:gsvelto]]

Actually this is more likely to be a UX workflow bug and I think it's reproducible simply by tapping the home key (the effect is the same: the change of visibility makes the app close itself and discard the message). We fixed it in 1.3 only in bug 934354 and we were waiting on the new notification API to land for a proper fix in bug 961064. If I'm right and the two bugs have the same cause then I'd like to close this one as a dup of bug 961064.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Alexandre LISSY :gerard-majax from comment #8)
> Enpei, could you retry after applying the gecko patch of bug 963035 and
> making sure you start with a clean profile ?
> 
> My expectation is that the cause of the issue is this missing file.close()
> bug.

One thing we should try here is test this on a build before the new notification API pieces landed for WAP Push. That will determine if it was caused by that work or not.

Enpei - Can you check if this reproduces on a 1/16/2014 build?

Comment 11

[Enpei]

Hi all,

Just like Gabriele's comment 9, this bug can be fixed once bug 934354 landed on master, which is bug 961064. 

And I found how to reproduce this bug with earlier master build:
Gaia      255a56ac67e5b28f1fc78307969cc83391c9652f
Gecko     http://hg.mozilla.org/mozilla-central/rev/81bced59e8b3
BuildID   20140115041401
Version   29.0a1
Case 1:
1. Send CP or WAP push to device.
2. Wait till notification which scroll down and cover entire status bar disappear.
3. Scroll down notification bar and open the message.
4. Short press power key to turn off display.
5. Press power key again and unlock screen, the message will be gone from notification bar. (Video:https://drive.google.com/a/mozilla.com/file/d/0B9xm__wv35oEZ3czbjU0aF9ibVk/edit?usp=sharing)

But if in step 2, you click the new incoming message notification without waiting it disappearing, it will go to another situation. (Video:https://drive.google.com/a/mozilla.com/file/d/0B9xm__wv35oETEN6bllsZlVwYzA/edit?usp=sharing) 
Case 2:
1. Send CP or WAP push to device.
2. Tap the new message notification before it disappears.
3. Once message is opened, press power key to turn off display.
4. Press power key again and unlock screen, message is closed but still stays on notification bar.
5. Open the message again from notification bar, it opens the message with "expired" information within it. 
6. Press close "x" button, message will be removed from notification bar. 20140115041401 build does not have bug 962977 yet.

So based on above test result, I would like to modify this bug to track case 2 bug, since original one is the same as bug 961064.

Comment 12

[Gabriele Svelto [:gsvelto]]

This was fixed a while ago though I cannot remember in which bug. Basically the notification for CP messages now remain until the message is explicitly accepted or rejected.