[NFC]Can't share screenshot from notification preview page.

VERIFIED FIXED in Firefox OS v2.2

Status

Firefox OS
NFC
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: Verson Xiong (Leave from Mozilla), Assigned: gduan)

Tracking

(Blocks: 1 bug)

unspecified
2.2 S13 (29may)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

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

Details

(Whiteboard: [v2.2-nexus-5-l])

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

3 years ago
Created attachment 8604585 [details]
logcat_1620.txt

[1.Description]:
[Flame v2.2][Nexus5 2.2]If user tries to share an image from notifacation, the image thumbnail at share dialog will change to a thumbnail of the Home. Then if user swipes up, no picture will be sent.
Found time:16:20
See Attachment:logcat_1620.txt & video_1620.mp4

[2.Testing Steps]: 
1.Turn on NFC.
2.Take a screenshot and open it.
3.Close to another NFC device.
4.Check the share window.
5.Swipe up and then check notifacation bar.

[3.Expected Result]: 
4.Share dialog will dispaly the thumbnail of image which you want to send.
5.Picture can be sent successfully.

[4.Actual Result]: 
4.The share dialog will display the thumbnail of home screen.
5.No picture will be sent.

[5.Reproduction build]: 

Device: Flame 2.2 (affected)
Build ID               20150511002500
Gaia Revision          528ef60e7cda09ad43478065f5d33bda398fbeb7
Gaia Date              2015-05-08 23:40:58
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/8d04cc085cf5
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150511.035847
Firmware Date          Mon May 11 03:58:59 EDT 2015
Bootloader             L1TC000118D0

Device: Flame 3.0 (Unaffected)
Build ID               20150511160205
Gaia Revision          6089234ace8b294a8feef064387604bae16254e3
Gaia Date              2015-05-10 13:57:12
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/502e1a5e722f
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150511.193556
Firmware Date          Mon May 11 19:36:04 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus 5 2.2 (affected)
Build ID               20150511002500
Gaia Revision          528ef60e7cda09ad43478065f5d33bda398fbeb7
Gaia Date              2015-05-08 23:40:58
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/8d04cc085cf5
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150511.034716
Firmware Date          Mon May 11 03:47:32 EDT 2015
Bootloader             HHZ12f

Device: Nexus 5 3.0 (Unaffected)
Build ID               20150511160205
Gaia Revision          6089234ace8b294a8feef064387604bae16254e3
Gaia Date              2015-05-10 13:57:12
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/502e1a5e722f
Gecko Version          41.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150511.193757
Firmware Date          Mon May 11 19:38:13 EDT 2015
Bootloader             HHZ12f

[6.Reproduction Frequency]: 
occasionally Recurrence,8/10

[7.TCID]: 
Free Test

[8.Note]:
On 3.0 build, Thumbnail window not change,but user can't swipe up to sent picture,see bug 1162384
(Reporter)

Comment 1

3 years ago
Created attachment 8604586 [details]
video_1620.mp4
(Reporter)

Updated

3 years ago
status-b2g-v2.2: --- → affected
status-b2g-master: --- → unaffected
See Also: → bug 1162384
Blocks: 933640
Is this duplicated to Bug 1162461?
Flags: needinfo?(ashiue)

Comment 3

3 years ago
No, this is not dup of bug 1162462, this test scenario is trying to share screenshot opened from notification. 
v2.1 also has this issue.
blocking-b2g: --- → 2.2?
QA Whiteboard: [COM=NFC]
status-b2g-v2.1: --- → affected
Flags: needinfo?(ashiue)
Summary: [NFC]Can't share image from notification preview page. → [NFC]Can't share screenshot from notification preview page.

Comment 4

3 years ago
(In reply to Alison Shiue from comment #3)
> No, this is not dup of bug 1162462, this test scenario is trying to share
                         bug 1162461
> screenshot opened from notification. 
> v2.1 also has this issue.

Comment 5

3 years ago
(In reply to Alison Shiue from comment #3)
> No, this is not dup of bug 1162462, this test scenario is trying to share
                         bug 1162461
> screenshot opened from notification. 
> v2.1 also has this issue.
I'm not able to replicate this on my Flame (done at least 10 tests) with latest build.
Gecko commit 04831570b29d2fd4306445633bb866d389864991
Gaia commit e048df68f6f4853b5826a8816e143d95258149de
(In reply to Krzysztof Mioduszewski[:tauzen] from comment #6)
> I'm not able to replicate this on my Flame (done at least 10 tests) with
> latest build.
> Gecko commit 04831570b29d2fd4306445633bb866d389864991
> Gaia commit e048df68f6f4853b5826a8816e143d95258149de

This Flame 2.2, with 2.2 gaia of course.

Comment 8

3 years ago
I tried with the latest pvt build, and this problem still occur, please refer: http://youtu.be/P4ghij-J-gM

Build ID               20150513002507
Gaia Revision          e048df68f6f4853b5826a8816e143d95258149de
Gaia Date              2015-05-12 19:10:26
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/0e6b4aab2b94
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150513.041549
Firmware Date          Wed May 13 04:15:58 EDT 2015
Bootloader             L1TC100118D0
NI George since he had looked into several issues seem to be like this one.
Flags: needinfo?(gduan)
I saw two errors when screenshot is tilt down, 
W/GeckoConsole( 3663): [JavaScript Error: "TypeError: this.element is null" {file: "app://system.gaiamobile.org/js/app_window.js" line: 1355}]
W/Gallery (13354): [JavaScript Error: "TypeError: activity is null" {file: "app://gallery.gaiamobile.org/js/open.js" line: 229}]

The former one should be not related to this bug since I fix it manually but bug still exist.
I think the latter one cause this issue, because I've commented below line,
https://github.com/mozilla-b2g/gaia/blob/master/apps/gallery/js/open.js#L186
and the problem is fixed .

Hi David, 
I think removing 'activity = null;' in open.js could fix this bug,
do you have any concern ?
Flags: needinfo?(gduan) → needinfo?(dflanagan)
(In reply to George Duan [:gduan] [:喬智] from comment #10)
> I saw two errors when screenshot is tilt down, 
> W/GeckoConsole( 3663): [JavaScript Error: "TypeError: this.element is null"
> {file: "app://system.gaiamobile.org/js/app_window.js" line: 1355}]
> W/Gallery (13354): [JavaScript Error: "TypeError: activity is null" {file:
> "app://gallery.gaiamobile.org/js/open.js" line: 229}]
> 
> The former one should be not related to this bug since I fix it manually but
> bug still exist.
> I think the latter one cause this issue, because I've commented below line,
> https://github.com/mozilla-b2g/gaia/blob/master/apps/gallery/js/open.js#L186
> and the problem is fixed .
> 
> Hi David, 
> I think removing 'activity = null;' in open.js could fix this bug,
> do you have any concern ?

Removing `activity = null` at line 230 will probably not fix the bug, because the line right before that ends the activity and sends the phone back to the app that came before.

The `exitWhenHidden` code that calls done() at line 186 is a fix for bug 1083053, which was a 2.0+ blocker bug. I think that the simplest way to fix that bug would be to backout the patch for 1083053. Maybe the window management code in the system app has changed enough that we can back out the workaround without re-introducing that bug.

If that does not work, though, then fixing this might be harder.  Here are my thoughts:

1) If the peerready event is handled in nfc.js before the visibilitychange event is handled in open.js, then we can set a flag in nfc.js, and then edit open.js to test that flag, so that line 185 becomes somethign like:

   if (document.hidden && !nfcShareInProgress){

2) If we can't fix it that way because the peerready event comes too late, then we should think some more about the proposal in 1090700.  I think that the fundamental issue behind bug 1083053 was that inline activities initiated by the system app don't make much sense.  I don't think we can change the open activity of the gallery app at this point, but we could add a new 'view' activity that had disposition:window and change the system app to use that instead of open. Then we could backout the patch from 1083053 and resolve this bug, too.

That's kind of a big change to uplift to 2.2, so if you can think of something simpler, that would be great.

This seems like an important bug to fix, so let me know if you need help with it.
Flags: needinfo?(dflanagan)
Created attachment 8608460 [details] [review]
[gaia] cctuan:1163957 > mozilla-b2g:master
Created attachment 8608465 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2
Comment on attachment 8608465 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2

Hi David,
could you help to review this patch?
onpeerready is later than the visibilitychange, however, onpeerfound works.
Attachment #8608465 - Flags: review?(dflanagan)
Attachment #8608460 - Attachment is obsolete: true
Comment on attachment 8608465 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2

nfcShareInProgress should be set false in onpeerlost event, however, I found onpeerlost and onpeerready are fired almost at the same time.

remove the review flag til I find correct timing to set nfcShareInProgress to false.
Attachment #8608465 - Flags: review?(dflanagan)
Comment on attachment 8608465 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2

It seems that we cannot NFC.nfcShareInProgress to false when onpeerlost, because you have to return false or evt.preventDefault in onpeerready, so that gecko would think this app will handle nfc related stuff and call onpeerlost when nfc device is lost or unfocused, or it will call onpeerlost right away and won't fix this issue. However, we can't do it in onpeerready callback since system will not receive it to trigger shrinking...

So, I think the best way now is put 'nfcShareInProgress = false' in unshare function...

David, could you review it? Thanks.
Attachment #8608465 - Flags: review?(dflanagan)
(In reply to George Duan [:gduan] [:喬智] from comment #16)
> Comment on attachment 8608465 [details] [review]
> [gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2
> 
> It seems that we cannot NFC.nfcShareInProgress to false when onpeerlost,
typo: onpeerready -> onpeerfound
> because you have to return false or evt.preventDefault in onpeerready, so
> that gecko would think this app will handle nfc related stuff and call
> onpeerlost when nfc device is lost or unfocused, or it will call onpeerlost

typo: onpeerready -> onpeerfound
> right away and won't fix this issue. However, we can't do it in onpeerready
> callback since system will not receive it to trigger shrinking...
> 
> So, I think the best way now is put 'nfcShareInProgress = false' in unshare
> function...
> 
> David, could you review it? Thanks.
blocking-b2g: 2.2? → 2.2+
Looks like you're actively working on this :)
Assignee: nobody → gduan
Comment on attachment 8608465 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2

r- because the gallery open activity does not call NFC.unshare() until it is exiting. So if you clear the flag in unshare, then once you have done an NFC transfer and the flag is set, then the old bug 1083053 will come back because the app will not automatically exit on visibility change.

I did not understand your explanation of why you can't do this in an onpeerlost callback, but if that really doesn't work, then please also add code to clear the flag after calling sendFile(). So the flag gets set when a peer is found, and it remains set until unshare() is called or until the file is transferred.

The state of the flag might not always be correct for the main gallery app where there are multiple photos taht could be shared in a single NFC pairing session, but since we only use it in open.js maybe this is good enough. (especially if you add comments explaining that the flag is not always correct.)

Or here's another idea. I can't find documentation for onpeerfound. Does the event object have a detail property that you can pass to mozNFC.getNFCPeer(). If so, then in onpeerfound you could just set NFC.sessionId = event.detail.

Then, open.js you could determine whether an NFC session is in progress by doing navigator.mozNFC.getNFCPeer(NFC.sessionId).  If it throws an error, then the NFC session is over.  Would that work?
Attachment #8608465 - Flags: review?(dflanagan) → review-
(In reply to David Flanagan [:djf] from comment #19)
> Comment on attachment 8608465 [details] [review]
> [gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2
> 
> r- because the gallery open activity does not call NFC.unshare() until it is
> exiting. So if you clear the flag in unshare, then once you have done an NFC
> transfer and the flag is set, then the old bug 1083053 will come back
> because the app will not automatically exit on visibility change.
Thanks for your suggestion. I forgot this scenario. 
> 
> I did not understand your explanation of why you can't do this in an
> onpeerlost callback, but if that really doesn't work, then please also add
I found that onpeerlost will be fired right after onpeerfound quickly. Yoshi told me that we need to set event.preventDefault or return true in onpeerfound to prevent this case, but if we doing that, system app won't receive this event and won't show shrinkingUI effect anymore. So, we cannot reset nfcShareInProgress in onpeerlost's callback here.
> code to clear the flag after calling sendFile(). So the flag gets set when a
> peer is found, and it remains set until unshare() is called or until the
> file is transferred.
> 
> The state of the flag might not always be correct for the main gallery app
> where there are multiple photos taht could be shared in a single NFC pairing
> session, but since we only use it in open.js maybe this is good enough.
> (especially if you add comments explaining that the flag is not always
> correct.)
Thanks
Please correct me if I misunderstand. Your saying that we should set NFC.nfcShareInProgress = false; after sendFile() and also in unshare, right? But this is probably not good enough to fix bug 1083053, because the flag might be not changed back if user triggers shrinking but hasn't sent the file.
> 
> Or here's another idea. I can't find documentation for onpeerfound. Does the
> event object have a detail property that you can pass to
> mozNFC.getNFCPeer(). If so, then in onpeerfound you could just set
> NFC.sessionId = event.detail.
> 
> Then, open.js you could determine whether an NFC session is in progress by
> doing navigator.mozNFC.getNFCPeer(NFC.sessionId).  If it throws an error,
> then the NFC session is over.  Would that work?
agree, but I couldn't dump any useful msg from onpeerfound.

Hi, Yoshi, 
do you have any suggestion on it? Is there any good timing to reset nfcShareInProgress flag ?
Flags: needinfo?(allstars.chh)
(In reply to David Flanagan [:djf] from comment #19)
> Or here's another idea. I can't find documentation for onpeerfound. Does the
> event object have a detail property that you can pass to
> mozNFC.getNFCPeer(). If so, then in onpeerfound you could just set
> NFC.sessionId = event.detail.
> 
> Then, open.js you could determine whether an NFC session is in progress by
> doing navigator.mozNFC.getNFCPeer(NFC.sessionId).  If it throws an error,
> then the NFC session is over.  Would that work?

Hi David
The NFC APIs (getNFCPeer, event.detail) you mentioned have been removed for v2.2.
The reason is for security concern, for example once you get the sessionId, you can do whatever you want (like sending any data to another NFC device without user perception)

In v2.2 we have added two new callbacks, onpeerfound, and onpeerlost, and in onpeerfound(event), event.peer will be instanceof MozNFCPeer.
And these callbacks will be notified when an NFC device is detected and removed.
These APIs are added per Jonas' request in Bug 963531, and the plan is to let app itself doing the sharing UI without System app.

So if you need onpeerfound, then you have to be on your own to do the Sharing UI.
but if you just want to have a notification that an NFC device is in proximinty, but still let System app doing the sharing UI, Gecko doesnt support this for now, as the plan is to let app to handle the sharing UI by itself.
Flags: needinfo?(allstars.chh)
I tried to move shrinkingUI to gallery/js/nfc.js and have some questions now. when user swipe up the screenshot, ShrinkingUI will dispatch shrinking-sent event to windows, but there's no receiver in gallery app. I think I would also need add an event listener for shrinking-sent and do 
      window.navigator.mozNfc.notifyUserAcceptedP2P(manifestURL);
or probably just add it to shrinkingUI.js itself. However, I guess this method require nfc-manager permission for gallery. I'm wonder if it makes sense, or is there any other suggestion?
Flags: needinfo?(allstars.chh)
(In reply to George Duan [:gduan] [:喬智] from comment #22)
> I tried to move shrinkingUI to gallery/js/nfc.js and have some questions
> now. when user swipe up the screenshot, ShrinkingUI will dispatch
> shrinking-sent event to windows, but there's no receiver in gallery app. I
> think I would also need add an event listener for shrinking-sent and do 
I think so.

>       window.navigator.mozNfc.notifyUserAcceptedP2P(manifestURL);
> or probably just add it to shrinkingUI.js itself. However, I guess this
> method require nfc-manager permission for gallery. I'm wonder if it makes
> sense, or is there any other suggestion?

You shouldn't use this API anymore, since the goal is to removed the complication in System app.
Flags: needinfo?(allstars.chh)
Created attachment 8610343 [details] [review]
[gaia] cctuan:1163957 > mozilla-b2g:master
Comment on attachment 8610343 [details] [review]
[gaia] cctuan:1163957 > mozilla-b2g:master

Hi David,

after discussion with Yoshi, I think the best way to fix here is to bring shrinkingUI liv to gallery's activity window (open.js), like what my patch does.
could I have your advice on it?
Thanks.
Attachment #8610343 - Flags: feedback?(dflanagan)
Comment on attachment 8610343 [details] [review]
[gaia] cctuan:1163957 > mozilla-b2g:master

Do I understand correctly that the idea is that all apps that do NFC sharing will be converted to do it this way eventually? If so, then I suppose it seems reasonable enough to go ahead and do it this way now.

Also, I notice that this patch no longer has any changes to the visiblity change handler. That must mean that when we handle the shrinking ui ourselves then we no longer go to the background, so that visibility change code is no longer triggered.  That seems good.

On the other hand, this fix requires a string change, and I think it is too late for that, so I don't see how we get uplfit approval for this patch.

Also, this patch seems quite big and risky for a last minute 2.2 uplift.

If we have to do it this way, then I guess I'd agree to do it, perhaps just with no text at all so there isn't an l10n issue. But I'm setting feedback- because I'd prefer a simpler fix if we can come up with one for 2.2

Here's another approach you could take. In the visibilitychange handler, you could set a 1000ms timer instead of calling done() right away. If the timer fires, then we call done() and the activity is over. But if the NFC onpeerready handler is called before the timer fires, then we cancel the timer.

If we can fix this bug that way, that seems like the kind of thing that we should do for 2.2.  And then for 3.0 we can actually convert the entire gallery app to do its own shrinking ui.  (I'd file a new bug for that, and maybe request pdahiya's help with it.)
Attachment #8610343 - Flags: feedback?(dflanagan) → feedback-
Attachment #8608465 - Attachment is obsolete: true
Comment on attachment 8610343 [details] [review]
[gaia] cctuan:1163957 > mozilla-b2g:master

In fact, onpeerready is fired after user swipe up the shrinkingUI , so the timer might not work here.

I don't have simpler fix now except my patch .... could you check again?
Attachment #8610343 - Flags: feedback- → review?(dflanagan)
Comment on attachment 8610343 [details] [review]
[gaia] cctuan:1163957 > mozilla-b2g:master

I don't like uplifting patches this complex, but I can't think of any other way to fix it, so r+.

Note that there are a couple of nits on github.

Also, I'd suggest that for the version of this patch that you land on master, you ought to include the required string in the locale file.

But for the version that gets uplifted to 2.2 you should probably not include the string.

Thanks for your work on this, George. What a difficult bug!
Attachment #8610343 - Flags: review?(dflanagan) → review+
Created attachment 8612082 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2
Really appreciated!
The shrinking's locale has been separated to shared folder, and I also create a commit for 2.2 which does not include locale, so it has no string for the tip.

set flag for checkin-needed to master.
Keywords: checkin-needed

Updated

3 years ago
Keywords: checkin-needed
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
land to master manually since tests all pass,
https://github.com/mozilla-b2g/gaia/commit/9ff9e9569846ed1f83cbc0442fe80b62e939570a
Comment on attachment 8612082 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Not a regression or feature.
[User impact] if declined: User cannot share screenshot through NFC as comment 0 describes.
[Testing completed]: Yes, manually test and unit test.
[Risk to taking this patch] (and alternatives if risky): The commit should fix this bug, however, user might not see the 'Share this' string since it's too late for uplifting it to 2.2 branch as comment 26 said.
[String changes made]:
Attachment #8612082 - Flags: approval-gaia-v2.2?

Updated

3 years ago
status-b2g-master: unaffected → fixed
Keywords: verifyme

Comment 34

3 years ago
Comment on attachment 8612082 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2

Norry,
Please verify on master and 2.2 after patch landed.
Thanks
Flags: needinfo?(fan.luo)
Attachment #8612082 - Flags: approval-gaia-v2.2? → approval-gaia-v2.2+

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Comment on attachment 8612082 [details] [review]
[gaia] cctuan:1163957-v22 > mozilla-b2g:v2.2

Gaia Try is showing test failures on this:
ReferenceError: MockShrinkingUI is not defined
Flags: needinfo?(gduan)
This bug has been verified as pass on latest Nightly build of Flame v3.0 and Nexus 5 v3.0 by the STR in Comment 0.

Actual results: Can share the screentshot successfully by NFC after opening the screenshot from Notification bar.
See attachment: verified_v3.0.mp4
Reproduce rate: 0/6


Device: Flame v3.0 build(Pass)
Build ID               20150528160205
Gaia Revision          e7d268074ee3c9eeb191c2205c0e35992fb3915d
Gaia Date              2015-05-28 10:47:28
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/f986e55c4e0b
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150528.192335
Firmware Date          Thu May 28 19:23:44 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus 5 v3.0 build(Pass)
Build ID               20150528002504
Gaia Revision          999bc627063d16c20f703e702f31a5cf0da8b4a6
Gaia Date              2015-05-28 02:16:40
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/351101ec82ba
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150528.040306
Firmware Date          Thu May 28 04:03:25 EDT 2015
Bootloader             HHZ12f

---------------------------------------------
Leaving "verifyme" for v2.2 verification
status-b2g-master: fixed → verified
Flags: needinfo?(fan.luo)
Created attachment 8612686 [details]
verified_v3.0.mp4
QA Whiteboard: [COM=NFC] → [COM=NFC][MGSEI-Triage+]
Update the Nexus 5 v3.0 version in Comment 36:

Build ID               20150528160205
Gaia Revision          e7d268074ee3c9eeb191c2205c0e35992fb3915d
Gaia Date              2015-05-28 10:47:28
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/f986e55c4e0b
Gecko Version          41.0a1
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150528.191717
Firmware Date          Thu May 28 19:17:35 EDT 2015
Bootloader             HHZ12f
Fixed. Thank you to point this out.
Flags: needinfo?(gduan) → needinfo?(ryanvm)
v2.2: https://github.com/mozilla-b2g/gaia/commit/ef9efcc658321f3d7dce27e3e423caf6dcb0f388
status-b2g-v2.2: affected → fixed
Flags: needinfo?(ryanvm)
Target Milestone: --- → 2.2 S13 (29may)
This bug has been verified as pass on latest Nightly build of Flame v2.2 and Nexus 5 v2.2 by the STR in Comment 0.

Actual results: Can share the screentshot successfully by NFC after opening the screenshot from Notification bar.
See above attachment: verified_v3.0.mp4
Reproduce rate: 0/5

Device: Flame v2.2 build(Pass)
Build ID               20150531162502
Gaia Revision          b4582cc394e0919623263997c0cdb0b4751a1403
Gaia Date              2015-05-31 11:06:34
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/78d8b0a4303d
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150531.195816
Firmware Date          Sun May 31 19:58:28 EDT 2015
Bootloader             L1TC000118D0

Device: Nexus 5 v2.2 build(Pass)
Build ID               20150531002502
Gaia Revision          0a46394dbee0ed2eb71a136cee38ddd8549dd597
Gaia Date              2015-05-30 14:50:16
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/ed2f6aeb1d81
Gecko Version          37.0
Device Name            hammerhead
Firmware(Release)      5.1
Firmware(Incremental)  eng.cltbld.20150531.043812
Firmware Date          Sun May 31 04:38:27 EDT 2015
Bootloader             HHZ12f

---------------------------------------------
Leaving "verifyme" for v2.1 uplift & verification
status-b2g-v2.2: fixed → verified
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.