Closed Bug 1084247 Opened 5 years ago Closed 5 years ago

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

Categories

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

defect

Tracking

(blocking-b2g:2.2+, tracking-b2g:backlog, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 verified, b2g-master verified)

RESOLVED FIXED
2.2 S5 (6feb)
blocking-b2g 2.2+
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- verified
b2g-master --- verified

People

(Reporter: sync-1, Assigned: gerard-majax)

References

Details

Attachments

(2 files)

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
Attached file log
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.
Flags: needinfo?(wehuang)
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.
Flags: needinfo?(wehuang) → needinfo?(ehung)
Luke, is this the similar issue to bug 1083053?
Flags: needinfo?(ehung) → needinfo?(lchang)
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.
Flags: needinfo?(lchang)
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?
Flags: needinfo?(wehuang)
(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
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.
Flags: needinfo?(lchang)
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.
Flags: needinfo?(wehuang)
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.
Flags: needinfo?(lchang)
(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.
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.
Assignee: nobody → lchang
Status: NEW → ASSIGNED
Summary: [Midori 2.0][System][Notification]Can not view screenshot by click notifications at notification bar → [Midori 2.0][System][Notification] Screenshot notification shouldn't be resent after restarting the device
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.
Flags: needinfo?(longxiuping)
(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!
Flags: needinfo?(longxiuping)
blocking-b2g: --- → 2.0?
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.
Correct the title because I misunderstood the symptom of KO2.
Summary: [Midori 2.0][System][Notification] Screenshot notification shouldn't be resent after restarting the device → [Midori 2.0][System][Notification] After rebooting, the screenshot preview window can't be launched by tapping the resending notifications
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.
Assignee: lchang → nobody
Flags: needinfo?(wehuang)
(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.
Flags: needinfo?(wehuang) → needinfo?(cserran)
Valid issue and impact UX, suggest as tag candidate for coming 2.0 Triage.
Triaged with Sysfe, not big enough impact to block release on
blocking-b2g: 2.0? → backlog
Flags: needinfo?(cserran)
Since it's after reboot, there is no more click handler. So we go through the "notification" system message.
(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?
You came to the same conclusion than me :).
Duplicate of this bug: 1098215
Hi all,

Any progress about this issue?
(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.
Assignee: nobody → lissyx+mozillians
Depends on: 1103560
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.
Flags: needinfo?(longxiuping)
Dear Alexandre LISSY,

Thank you for your strong support. I hope we can merge this patch for 2.0.
Flags: needinfo?(longxiuping)
Duplicate of this bug: 1122282
So bug 1103560 is fixed now on master, can you try to uplift the patch yourself ?
Flags: needinfo?(longxiuping)
(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.
Flags: needinfo?(longxiuping)
(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.
Flags: needinfo?(lissyx+mozillians)
Ok, I'm going to try at least 2.2 and maybe 2.1 first. Gregor, how should we considering this blocking ?
Flags: needinfo?(lissyx+mozillians) → needinfo?(anygregor)
Kevin, can you help out with 2.1 and 2.0 triage?
Flags: needinfo?(anygregor) → needinfo?(khu)
Duplicate of this bug: 1122282
(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.
And I'm busy hacking devices and other stuff for now :)
I really should not keep this assigned to me until I can really have time to work on it.
Assignee: lissyx+mozillians → nobody
blocking-b2g: backlog → ---
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.
blocking-b2g: --- → 2.2+
Flags: needinfo?(khu) → needinfo?(anygregor)
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.
Flags: needinfo?(anygregor)
Keywords: qawanted
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
Fixed in bug 1103560. Still need to uplift and fix on trees mentioned in comment 39
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee: nobody → lissyx+mozillians
Target Milestone: --- → 2.2 S8 (20mar)
Target Milestone: 2.2 S8 (20mar) → 2.2 S5 (6feb)
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
You need to log in before you can comment on or make changes to this bug.