Closed Bug 1163258 Opened 5 years ago Closed 2 years ago

[Add-ons] - Add-ons cannot handle activities

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: pdahiya, Unassigned)

References

Details

(Whiteboard: [spark])

Attachments

(1 file)

Call to activities handled inside customizer add-on fails with error NO_PROVIDER.

Attaching folder has reduced test case having

1) TestAddon folder containing a basic add-on handling activity name 'test'

2) Customizer-activity - folder contains two files a mainfest.webapp that declares an activity name 'customize' and script.js that handles 'customize' activity for customizer add-on. Copy script.js in folder customizer/app/js/services and update mainfest.webapp file to enable customizer-addon to handle 'customize' activity

3) TestApp - folder contains a basic app that has two buttons that launches test activity for TestAddon and customize activity for customizer add-on.

TestApp is able to successfully launch test activity inside a basic Test Add-on where as fails with error NO_PROVIDER for customizer add-on.
Attached file Reduced Test Cases
Hi Justin

Setting NI flag for you first as I am seeing error NO_PROVIDER error for customizer add-on and not for a simple basic add-on. Please feel free to NI Fabrice if it's underlying add-on issue. Thanks!
Flags: needinfo?(jdarcangelo)
Updating this bug title to reflect the latest findings and platform limitations that need addressed.

When an add-on specifies a `"disposition": "inline"` activity in its manifest, it must also specify an `"href": "handler.html"`. Then, when another app calls this activity, the .html file specified by this `href` is launched as an app. It is not possible for an already-injected add-on to answer the call for an incoming activity. Therefore, it is not possible to handle an activity within the context of an app that has the add-on injected.

Because of the way activities are handled, I don't see any possible way of doing this currently. Even if this was functioning and an add-on is injected in 5 different apps at once, how do we determine which of the 5 injected-instances of the add-on should receive the incoming activity request?

Setting NI? for fabrice to get his thoughts on this. I believe we may have a suitable workaround for Customizer V1, but this is definitely something that should be discussed.
Blocks: spark-addons
Component: Gaia::Customizer → General
Flags: needinfo?(jdarcangelo) → needinfo?(fabrice)
Priority: -- → P2
Summary: [Customizer] - Call to Activty handled inside customizer add-on fails with error NO_PROVIDER → [Add-ons] - Add-ons cannot handle activities
Whiteboard: [spark]
(In reply to Justin D'Arcangelo [:justindarc] from comment #3)

> When an add-on specifies a `"disposition": "inline"` activity in its
> manifest, it must also specify an `"href": "handler.html"`. Then, when
> another app calls this activity, the .html file specified by this `href` is
> launched as an app. It is not possible for an already-injected add-on to
> answer the call for an incoming activity. Therefore, it is not possible to
> handle an activity within the context of an app that has the add-on injected.

That's correct.

> Because of the way activities are handled, I don't see any possible way of
> doing this currently. Even if this was functioning and an add-on is injected
> in 5 different apps at once, how do we determine which of the 5
> injected-instances of the add-on should receive the incoming activity
> request?

So, what is the use case here and what do you expect if an add-on is injected in several pages? Note that it could also be injected in web pages that are not even part of an "app".
Flags: needinfo?(fabrice)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.