Closed Bug 785391 Opened 8 years ago Closed 8 years ago

Activities 'data' content cannot be accessed

Categories

(Firefox OS Graveyard :: General, defect, major)

All
Gonk (Firefox OS)
defect
Not set
major

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
blocking-basecamp +

People

(Reporter: gerard-majax, Assigned: fabrice)

Details

Attachments

(1 file, 1 obsolete file)

With current gecko, (head at fcb2af3ad2e7d9af40e54b3cc5a2e40241e59c09), it's impossible to access the 'data' field in an activity. This happens at least with Gallery 'share-filenames' activity: "Share Receiver" application cannot access any of the fields that are in the 'data' member of the activity.

The following shows that we can access to source.name and source.data but not its content.

E/GeckoConsole( 3273): Content JS LOG at app://image-uploader.gaiamobile.org/js/image-uploader.js:10 in anonymous: request source: [xpconnect wrapped nsIDOMMozActivityOptions]
E/GeckoConsole( 3273): Content JS LOG at app://image-uploader.gaiamobile.org/js/image-uploader.js:11 in anonymous: request name: share-filenames
E/GeckoConsole( 3273): Content JS LOG at app://image-uploader.gaiamobile.org/js/image-uploader.js:12 in anonymous: request data: [object Object]
E/GeckoConsole( 3273): Content JS LOG at app://image-uploader.gaiamobile.org/js/image-uploader.js:13 in anonymous: request type: 
E/GeckoConsole( 3273): Content JS LOG at app://image-uploader.gaiamobile.org/js/image-uploader.js:14 in anonymous: request filenames:
Summary: Activitis data cannot be accessed → Activities 'data' content cannot be accessed
This is clearly a regression.
blocking-basecamp: --- → ?
Hardware: ARM → All
Assignee: nobody → fabrice
git bisect gives:
257c5f02cb67aa4b1497f99c03cdfa8fcd4c5e85 is the first bad commit
commit 257c5f02cb67aa4b1497f99c03cdfa8fcd4c5e85
Author: Fabrice Desré <fabrice@mozilla.com>
Date:   Thu Aug 23 11:56:36 2012 -0700

    Bug 784678 - Error when calling postCancel and postSuccess in an activity : followup [r=mrbkap]

:040000 040000 42a0f7e37594e39887e6778b31dfe13ccd6d2259 e8619da4faf5cbb20e85a608c59b7d11b555fa73 M	dom
Open gallery, tap "share", select "share receiver".
blocking-basecamp: ? → +
Attached patch Fixing. (obsolete) — Splinter Review
Thanks to fabrice, this patch fixes the issue.
Attached patch patchSplinter Review
Alexandre patch was not complete. We also need to wrap what we send to the onsuccess() handler of the DOM request. Hence a couple of idl changes to send the window used to wrap around.
Attachment #655134 - Attachment is obsolete: true
Attachment #655213 - Flags: review?(anygregor)
Attachment #655213 - Flags: review?(21)
Attachment #655213 - Flags: review?(anygregor) → review+
Attachment #655213 - Flags: review?(21)
Thanks, it fixes my issue, but if I try to reproduce bug 784768, then the contact app never shows:
- Open SMS app
- New SMS
- Click on Contacts icon

Contacts should be opened, while it does not.
(In reply to Alexandre LISSY from comment #7)
> Thanks, it fixes my issue, but if I try to reproduce bug 784768, then the
> contact app never shows:
> - Open SMS app
> - New SMS
> - Click on Contacts icon
> 
> Contacts should be opened, while it does not.

It is, but since the contacts "pick" activity lacks a returnValue: true in the manifest we fire onsuccess(null) and the sms app gets confused. (see https://mxr.mozilla.org/mozilla-central/source/dom/activities/src/ActivitiesService.jsm#233)
https://hg.mozilla.org/mozilla-central/rev/005c47c479fa
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
QA Contact: jsmith
Whiteboard: [qa+]
Keywords: verifyme
Whiteboard: [qa+]
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.