1084247 - [Midori 2.0][System][Notification] After rebooting, the screenshot preview window can't be launched by tapping the resending notifications

Status: RESOLVED FIXED

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

Description

[sync-1]

version: FFOS 2.0 
 BuildID: 20140916000205
 
 
 DEFECT DESCRIPTION:
  Can not view screenshot by click notifications at notification bar
 
  REPRODUCING PROCEDURES:
  1.press home key and power key to make a screenshot
  2.drag down the notification bar then click screenshot notification
  3.screenshot notification don't disappeared. -> ko1
  4.restart device, the notification is resend, but user can not view screenshot  by click the notification. -> ko2
 
 
  EXPECTED BEHAVIOUR:
    Can view screenshot and notification should disappear after click the notification.
 
  USER IMPACT:
  Mid
 
  REPRODUCING RATE:
  5/5

Comment 1

[sync-1]

Attachment: log

Comment 2

[xiupinglong]

KO3 -> We have many screenshot notifications in notification bar, 
1. open a screenshot by click the first notification,
2. click the second notification, but user can not open it.

Comment 3

[Wesly Huang (EPM)]

I can repro. all 3 symptoms (K01~K03) with Flame v188 based image. Feel there is something strange at least about screenshot notification handling. (ex: if follow comment#0 have 1 screenshot first I can repro. KO1&2, then I screen captured another 2 so in total 3 screenshots/notifications, it becomes I can click and see screenshot#1 & #2, but fail for screenshot #3, meaning the behavior of screenshot#1 is changed)

Hi Evelyn:

Looks like Gaia level issue but not sure, would you help judge, if agree then assign people to look into? Thank you.

Comment 4

[Evelyn Hung]

Luke, is this the similar issue to bug 1083053?

Comment 5

[Luke Chang [:lchang] (inactive)]

It should be a different issue related to notification handler instead of window manager. Also, it can't be reproduced on flame with latest master branch.

Comment 6

[Luke Chang [:lchang] (inactive)]

Hi Wesly,

This bug is a duplicate of bug 1004985. I've confirmed that the patch of that bug can fix these 3 symptoms. Do we need to request the approval for v2.0?

Comment 7

[xiupinglong]

(In reply to Luke Chang [:lchang] from comment #6)
> Hi Wesly,
> 
> This bug is a duplicate of bug 1004985. I've confirmed that the patch of
> that bug can fix these 3 symptoms. Do we need to request the approval for
> v2.0?

Dear Luke,

With the patch for bug 1004985, it can just solve the KO1, other issues still can reproduce.

Steps:
1. take two screenshot
2. open messages app
3. pull down the notification bar, click to open one screenshot, note: don't press the back button on screenshot
4. and then press home key go back to homescreen
5. pull down the notification bar againg, click to open another screenshot, the screenshot can not open.
-> KO3

6. take a screenshot, don't click the notification to view it
7. resart the phone
8. the screenshot notification resend, but user can not open it by click -> KO2

Comment 8

[Wesly Huang (EPM)]

Hi Luke:

Let me check more about the approval process now then give you confirmation, in the mean time would you take a look at comment#7 and comment? Thank you.

Comment 9

[Wesly Huang (EPM)]

Hi Luke: 

1. I believe this is a common use case thus good to fix it in v2.0, once other product meet same issue there is a patch available. Please request approval for v2.0. And feel free to let me know if any question. 

Also would you help clarify with Xiuping about his KO2 & KO3? Thank you.
Thank you.

Comment 10

[Luke Chang [:lchang] (inactive)]

Per STR in comment7, I can reproduce KO2 & KO3, too.

KO3 should be fixed by the patch of Bug 1032068. I'll check that later.

Comment 11

[Luke Chang [:lchang] (inactive)]

(In reply to Luke Chang [:lchang] from comment #10)
> KO3 should be fixed by the patch of Bug 1032068. I'll check that later.

Thanks to Alive, we found that to fix KO3 also needs Bug 1075353.

Fortunately, it's already marked 2.0+ but it should also depend on bug 1032068. I'll request the approval of bug 1032068 as well.

Comment 12

[Luke Chang [:lchang] (inactive)]

Since KO1 can be fixed by bug 1004985 and KO3 can be tracked by bug 1032068 and bug 1075353, I would suggest focusing KO2 in this bug. Change the title accordingly.

Comment 13

[Luke Chang [:lchang] (inactive)]

Hi Xiuping,

Bug 1004985, bug 1032068 and bug 1075353 have been landed on v2.0. Could you please verify if KO1 and KO3 are fixed or not? Thanks.

Comment 14

[xiupinglong]

(In reply to Luke Chang [:lchang] from comment #13)
> Hi Xiuping,
> 
> Bug 1004985, bug 1032068 and bug 1075353 have been landed on v2.0. Could you
> please verify if KO1 and KO3 are fixed or not? Thanks.

Hi  Luke Chang,

I test it with the three patch, the KO1 and KO3 are fixed by them.
Thank you for your strongly support!

Comment 15

[Wesly Huang (EPM)]

Thanks to Luke's effort and Xiuping's good news! Since the fixes are available I set it as a candidate to tag in coming Triage.

Comment 16

[Luke Chang [:lchang] (inactive)]

Correct the title because I misunderstood the symptom of KO2.

Comment 17

[Luke Chang [:lchang] (inactive)]

Hi Wesly,

This bug (KO2) may be a Gecko issue.

In Gaia, we can register an event handler on the click event of notifications. This kind of handlers are recorded in Gecko and Gaia just uses mozContentEvent to trigger it. Also, we have a Gecko API called "mozResendAllNotifications" by which we ask Gecko to resend the notifications after rebooting. This bug seems to be caused by that the handlers can't be triggered by Gecko after rebooting.

Hence, we may need help from Gecko.

Comment 18

[Wesly Huang (EPM)]

(Thanks Luke!)

Hi Candice:

learned that you are front-end EPM so wondering if you could help here. This is a candidate issue to be tagged for 2.0 and Luke has done some work already but the last piece seems need Gecko expert's involve (however we don't know a proper contact). Looks to me his is notification related that is part offrond-end, so wondering if you could advise a proper person to look into? Thanks.

Comment 19

[Wesly Huang (EPM)]

Valid issue and impact UX, suggest as tag candidate for coming 2.0 Triage.

Comment 20

[Candice Serran (:cserran)]

Triaged with Sysfe, not big enough impact to block release on

Comment 21

[:gerard-majax]

Since it's after reboot, there is no more click handler. So we go through the "notification" system message.

Comment 22

[xiupinglong]

(In reply to Alexandre LISSY :gerard-majax from comment #21)
> Since it's after reboot, there is no more click handler. So we go through
> the "notification" system message.

Yes, I found the "notification" is registered in file findmydevice_launcher.js in system app,
following is the related code:
// ensure resent notifications are handled correctly
window.navigator.mozSetMessageHandler('notification', function(message) {
  if (!message.clicked) {
    return;
  } else {
    if (message.tag &&
      message.tag.startsWith(FMD_ENABLE_FAILURE_NOTIFICATION_TAG)) {
      FMDOpenSettings();
      FMDCloseNotifications();
    }
  }
});

But one app just can register one Message, otherwise it would be covered by another one. So 
suggest dispatch event once Message "notification" is received, and screenshot handle the dispatch event. Do you think so?

Comment 23

[:gerard-majax]

You came to the same conclusion than me :).

Comment 25

[xiupinglong]

Hi all,

Any progress about this issue?

Comment 26

[:gerard-majax]

(In reply to xiupinglong from comment #25)
> Hi all,
> 
> Any progress about this issue?

I should be able to have some time to work on it now.

Comment 27

[:gerard-majax]

Bug 1103560 is starting to look quite good, but I'm not sure we will be able to uplift it this way, at least for 2.0 and 2.1.

Comment 28

[xiupinglong]

Dear Alexandre LISSY,

Thank you for your strong support. I hope we can merge this patch for 2.0.

Comment 30

[:gerard-majax]

So bug 1103560 is fixed now on master, can you try to uplift the patch yourself ?

Comment 31

[xiupinglong]

(In reply to Alexandre LISSY :gerard-majax from comment #30)
> So bug 1103560 is fixed now on master, can you try to uplift the patch
> yourself ?

Dear Alexandre LISSY,
Sorry, the master branch is so different from 2.0, I couldn't uplift it on v2.0 now.

Comment 32

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to xiupinglong from comment #31)
> (In reply to Alexandre LISSY :gerard-majax from comment #30)
> > So bug 1103560 is fixed now on master, can you try to uplift the patch
> > yourself ?
> 
> Dear Alexandre LISSY,
> Sorry, the master branch is so different from 2.0, I couldn't uplift it on
> v2.0 now.

Comment 33

[:gerard-majax]

Ok, I'm going to try at least 2.2 and maybe 2.1 first. Gregor, how should we considering this blocking ?

Comment 34

[Gregor Wagner [:gwagner]]

Kevin, can you help out with 2.1 and 2.0 triage?

Comment 36

[Gregor Wagner [:gwagner]]

(In reply to Gregor Wagner [:gwagner] from comment #34)
> Kevin, can you help out with 2.1 and 2.0 triage?

We need a decision from the devices team here.

Comment 37

[:gerard-majax]

And I'm busy hacking devices and other stuff for now :)

Comment 38

[:gerard-majax]

I really should not keep this assigned to me until I can really have time to work on it.

Comment 39

[Kai-Chih Hu [:khu]]

After triage with the device group, we decided to + this bug with 2.2, and then we will merge the fix to 2.0M and 2.1S. Thank you. 

Gregor, could you find someone to take a look on this bug? 
Thank you.

Comment 40

[Gregor Wagner [:gwagner]]

Can we test on master again?
According to comment 30 it should work on master and the devices team just has to uplift the changes.

Comment 41

[Pi Wei Cheng [:piwei] (inactive)]

There had been 3 bugs mentioned in this bug. To be clear, from testing latest v2.0 I concluded the only issue still happening is the one mentioned in the title - tapping on a screenshot notification doesn't work after reboot if that particular notification had been there prior to rebooting.

On v3.0 master this issue is not present. The screenshot can be accessed without issue either from tapping on notification on lockscreen, or from utility tray after unlocking.

Device: Flame 3.0 Master
BuildID: 20150319010201
Gaia: c39e15f631de80c69467fda0d4ea0bcda9e194ca
Gecko: cf1060d8ce9f
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 39.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:39.0) Gecko/39.0 Firefox/39.0

Comment 42

[Gregor Wagner [:gwagner]]

Fixed in bug 1103560. Still need to uplift and fix on trees mentioned in comment 39

Comment 43

[Lancy(Leave from Mozilla)]

Attachment: Verify1_Flame v2.2&master_Pass.3gp

This issue is verified as pass on latest flame v2.2&master build.
STR:
1.Take a screenshot and reboot device.
2.Tap the notification of the screenshot on lock screen or Notifications menu.

Actual result:
The screenshot can be opened.

See attachment:Verify1_Flame v2.2&master_Pass.3gp.
Reproducing rate:0/10.

Device: Flame 2.2 build (Pass)
Build ID               20150630162500
Gaia Revision          bd386f346eb1591fddbc84bf034b22700e7e2a58
Gaia Date              2015-06-30 15:53:15
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/f16c1125b9d6
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150630.200238
Firmware Date          Tue Jun 30 20:02:49 EDT 2015
Bootloader             L1TC000118D0


Device: Flame master build (Pass)
Build ID               20150630160220
Gaia Revision          5997b406e77ea726fbd9047057a1c3504f6cd6d4
Gaia Date              2015-06-30 01:48:01
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/291614a686f1
Gecko Version          42.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150630.193722
Firmware Date          Tue Jun 30 19:37:34 EDT 2015
Bootloader             L1TC000118D0