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

Status: RESOLVED WONTFIX

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

Description

[Punam Dahiya [:pdahiya]]

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.

Comment 1

[Punam Dahiya [:pdahiya]]

Attachment: Reduced Test Cases

Comment 2

[Punam Dahiya [:pdahiya]]

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!

Comment 3

[Justin D'Arcangelo [:justindarc]]

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.

Comment 4

[[:fabrice] Fabrice Desré]

(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".

Comment 5

[BMO Automation]

Firefox OS is not being worked on