[NFC] Unable to share image when ever opened image from notification

RESOLVED INVALID

Status

defect
RESOLVED INVALID
4 years ago
4 years ago

People

(Reporter: ashiue, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

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

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Posted file nfc.log
Build ID               20150506162500
Gaia Revision          c6a6996841860ab335bf46b273477dc4bef19c95
Gaia Date              2015-05-06 17:01:57
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c7fafa53b4e7
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150506.195956
Firmware Date          Wed May  6 20:00:07 EDT 2015
Bootloader             L1TC100118D0

STR:
1. Run gallery in the background
2. Receive an image, and open it from notification
3. Exit image preview
4. Run gallery in the foreground, and select an image
5. Tap device with others, swipe shrinking UI to share the selected image

Expected result:
Share image successfully

Actual result:
Unable to share image until relaunch gallery app, please refer: https://youtu.be/w-d3mrwM9xg
(Reporter)

Updated

4 years ago
blocking-b2g: --- → 2.2?
QA Whiteboard: [COM=NFC]
note: this is NOT a dup to bug 1162384, and not a regression.
See Also: → 1162384
Flags: needinfo?(dflanagan)
The symptom shown in the video, where swiping to share the image fails is outside of the control of gaia, so I suspect there is a gecko issue here. But we can investigate it on the gaia side to see if we can figure out more.

Does this really only reproduce for the image that was just transferred? Or after using NFC to transfer from A to B is it impossible to transfer any image from B to A?

If the former, then I wonder if changing the filename of the blob would have any effect. If the latter then maybe there is some kind of failure in the code that receives the original image to send a success signal to acknowledge that the transfer was complete?

This is just pure speculation, of course.  

It would also be interesting to try the same STR using a song instead of a photo.

Punam: I'm taking this one to investigate, but if you have thoughts about this, or learn anything from investigating 1162384, please add your comments here.
Assignee: nobody → dflanagan
Flags: needinfo?(dflanagan) → needinfo?(pdahiya)
Hi David

I have noticed the bluetooth disabled in logs, not sure if its related but something that could be a reason

I/GKI_LINUX( 9436): GKI_destroy_task: GKI_shutdown(): task [BTIF] terminated
I/GeckoConsole(  207): Content JS LOG: [NfcHandoverManager]: bluetooth-disabled 
I/GeckoConsole(  207):     at _logVisibly (app://system.gaiamobile.org/gaia_build_defer_index.js:1692:0)

I am looking into Bug 1162384 and will update if I find anything related. Thanks
Flags: needinfo?(pdahiya)
I've been able to reproduce this.  I'm not sure it happens every time for me, though. I transfered a photo from nexus 5 to flame and then was able to transfer it from the flame back to the nexus 5. But when I tried to transfer from the nexus 5 to the flame a second time, I saw that the video shows.

My logcat includes this message repeated many (50?) times in a row:

I/Gecko   ( 1519): this._window or this.__DOM_IMPL__ is a dead wrapper.

That message also appears in the logcat attached to this bug.
1519 is the gallery process, but the string _window does not appear anywhere in the gallery source code so that message isn't coming from Gaia.

I also see this message in my logcat (but not in the attached logcat):

E/GeckoConsole(  206): [JavaScript Error: "TypeError: this._showScreenshotOverlay(...) is undefined" {file: "app://system.gaiamobile.org/gaia_build_defer_index.js" line: 2459}]

There is lots of diagnostic NFC information in the logcat, but since I know nothing about the NFC implementation it does not make any sense to me.

This is looking like a gecko issue or a system app issue. I'm going to unassign myself.

Wesley: can you find someone who knows more about NFC to investigate this, please?
Assignee: dflanagan → nobody
Flags: needinfo?(whuang)
calling out to Yoshi.
Flags: needinfo?(allstars.chh)
For notification the original bug is Bug 1033964 and it's belonged to System app.
From the log I didn't see any error on NFC side.
Flags: needinfo?(allstars.chh)
triage: this should block, as it breaks basic function and no easy workaround for users.
blocking-b2g: 2.2? → 2.2+
Flags: needinfo?(whuang) → needinfo?(alive)
I do think this is not a gaia issue as David had already addressed.

If you see the window is shrink-ed and you could swipe it - that's it, nothing happened after that is controlled by gaia. I don't know why this is kicked back?

What does 'any error on NFC side' mean? Does system app not call the sendNFC API correctly? Does bluetooth fail to transfer the file?
Flags: needinfo?(alive)
From Bug 1033964 it makes the notification window to be NFC shared.
However it seems it's changed now so the window object is no longer valid, (Cu.isDeadWrapper returns true) so djf saw the log "this._window or this.__DOM_IMPL__ is a dead wrapper."

So base on Bug 1033964 I said this should be related to System app,
but feel free to correct me :).

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #8)
> What does 'any error on NFC side' mean?
From previous djf's comment he said that he saw a lot of NFC log, (which is from NCI library)
and from the Video provided by Alison the ShrinkUI keeps popping out even when user swipes it,
this could be possibly caused by NFC connection is broken (connected -> disconnected -> connected -> disconnected,... back and forth), but from the log I didn't observe this, so I mean no error from the NFC hardware side.
Could you help to verify if this is a gaia bug? Thanks.
Flags: needinfo?(gduan)
This is a bit more complicated, and I think it's related to activity handling on Gecko side (so not exactly NFC). In short the problem here is that when the preview image is displayed, gallery activity code (open.js) is registering onpeerready handler to be able to share the image. This invokes MozNFCImpl constructor and invalidates this._window and __DOM_IMPL__ in the original gallery app. So the log line pointed out by David in comment 4:
> I/Gecko   ( 1519): this._window or this.__DOM_IMPL__ is a dead wrapper.
is actually coming from MozNFCImpl.handlePeerFound, and shows that onpeerready handler of gallery app is not invoked and sharing is not possible.  

I don't know why this._window and __DOM_IMPL__ are invalidated in the original gallery app. The only workaround which works for me is to remove the onpeerready registration from open.js, this of course blocks the sharing in image preview/gallery activity. Yoshi, what do you think about this?
Flags: needinfo?(gduan) → needinfo?(allstars.chh)
So this is the scenario with full logging. The important parts are below:
1. Opening the gallery app, viewing one image details, going back to gallery overview:
>05-13 13:05:40.840 I/Gecko   ( 6894): -*- Nfc DOM: In MozNFCImpl Constructor
>05-13 13:05:40.840 I/Gecko   ( 6894): -*- Nfc DOM: MozNFCImpl init called
>05-13 13:05:40.860 I/Gecko   ( 5815): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:RegisterPeerReadyTarget","sync":false,"json":{"appId":1018},"data":{"appId":1018},"objects":{}}
>05-13 13:05:43.090 I/Gecko   ( 5815): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:UnregisterPeerReadyTarget","sync":false,"json":{"appId":1018},"data":{"appId":1018},"objects":{}}
Please notice here that appId for the gallery app is 1018

2. Opening and closing the image from the notification:
>05-13 13:06:07.800 I/Gecko   ( 6894): -*- Nfc DOM: In MozNFCImpl Constructor
>05-13 13:06:07.800 I/Gecko   ( 6894): -*- Nfc DOM: MozNFCImpl init called
>05-13 13:06:07.830 I/Gecko   ( 5815): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:RegisterPeerReadyTarget","sync":false,"json":{"appId":1018},"data":{"appId":1018},"objects":{}}
>05-13 13:06:10.330 I/Gecko   ( 5815): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:UnregisterPeerReadyTarget","sync":false,"json":{"appId":1018},"data":{"appId":1018},"objects":{}}
Please notice that we have the same appId here.

3. Once again we open the image detail in the gallery app and try to share it:
>05-13 13:06:13.380 I/Gecko   ( 5815): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:RegisterPeerReadyTarget","sync":false,"json":{"appId":1018},"data":{"appId":1018},"objects":{}}
>05-13 13:06:20.500 I/Gecko   ( 5815): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:CheckP2PRegistration","sync":false,"json":{"appId":1018,"requestId":"aWR7OGY2MTIzYmQtOTk1Ny00ZGQ1LTllZTQtZmJhM2UyYzEwNjhmfQ=="},"data":{"appId":1018,"requestId":"aWR7OGY2MTIzYmQtOTk1Ny00ZGQ1LTllZTQtZmJhM2UyYzEwNjhmfQ=="},"objects":{}}
>05-13 13:06:22.740 I/Gecko   ( 5815): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:NotifyUserAcceptedP2P","sync":false,"json":{"appId":1018},"data":{"appId":1018},"objects":{}}
>05-13 13:06:22.750 I/Gecko   ( 6894): this._window or this.__DOM_IMPL__ is a dead wrapper.
>05-13 13:06:22.790 I/Gecko   ( 5815): -*- Nfc: Received message from content process: {"target":{},"name":"NFC:CallDefaultFoundHandler","sync":false,"json":{"sessionToken":"{8ac67884-207e-494c-b3ca-fead9e57c0d3}","isP2P":true,"records":null},"data":{"sessionToken":"{8ac67884-207e-494c-b3ca-fead9e57c0d3}","isP2P":true,"records":null},"objects":{}}

So the first step from STR is incomplete. We need to actually see the details of at least one image and go back to gallery view, so MozNFCImpl constructor can be invoked. If we just start the gallery app and leave it on the first screen the problem won't occur.

On the other hand, if we check the image details and put the gallery app into background, we will get a different bug - we won't get Shrinking UI in step 5 of STR. This is because the activity and gallery app share the same appId, exiting the activity will remove PeerReady registration for gallery app in the parent process. I'm not sure if we should file this as a separate bug. Removing sharing from gallery activity will of course solve this problem also.
Bug 1162384
Flags: needinfo?(allstars.chh)
One information, 
Alison has applied the patch in bug 1162384. But the problem doesn't resolve by the patch.

Ni George and see his opinions here.
Flags: needinfo?(gduan)
Thanks for your investigating.
> So the first step from STR is incomplete. We need to actually see the
> details of at least one image and go back to gallery view, so MozNFCImpl
> constructor can be invoked. If we just start the gallery app and leave it on
> the first screen the problem won't occur.
> 

 As Krzysztof said, this bug is only reproducible if we have seen the details of one image. Without this step, this bug is not reproducible. 
and I also tried to dump msg on https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/nfc_manager.js#L333 when bug happened, the manifestURL is correct (app://gallery.gaiamobile.org/manifest.webapp).

I think it's probably more related to gecko ...
Flags: needinfo?(gduan)
Let's INVALID it and create bug 1165841 because the STR is incomplete here.
Refer to:
https://bugzilla.mozilla.org/show_bug.cgi?id=1165841#c0
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
(Reporter)

Comment 17

4 years ago
(In reply to Krzysztof Mioduszewski[:tauzen] from comment #12)
> On the other hand, if we check the image details and put the gallery app
> into background, we will get a different bug - we won't get Shrinking UI in
> step 5 of STR. This is because the activity and gallery app share the same
> appId, exiting the activity will remove PeerReady registration for gallery
> app in the parent process. 

Create bug 1168716 to track this issue.
You need to log in before you can comment on or make changes to this bug.