Closed Bug 1211709 Opened 4 years ago Closed 4 years ago

Addon script does not get inserted on app startup


(Firefox OS Graveyard :: Runtime, defect)

Gonk (Firefox OS)
Not set



blocking-b2g 2.5+


(Reporter: eeejay, Assigned: fabrice)




(1 file)


1. Load the attached clock addon in WebIDE.
2. Install on device while clock app is running.
3. Enable addon in settings.
4. Observe that in logcat "hello world" is printed - the script runs.
5. Quit the clock app.
6. Launch the clock app again.

Result: The script is not executed on startup.

Expected: The script should execute on startup.
Looks like a regression in the new addon API from bug 1190995.
Flags: needinfo?(fabrice)
Attached file
blocking-b2g: --- → 2.5+
I'll check that later today but I'm really surprised as one of my test addons is the "snappy twitter" which is injected at startup and worked fine.
Everything works for me with the patch from bug 1212089 applied.
Depends on: 1212089
Flags: needinfo?(fabrice)
I still don't see this working. I applied the patch in bug 1212089, no change.
Can you attach a logcat dump?
So I dived into this a bit yesterday. It looks like initialProcessData is empty in the content process. We rely on that to have the list of active addons after the process is started. But what happens is that we prelaunch the content process (dom.ipc.processPrelaunch.enabled) before initialProcessData is populated :P

As the original author of initialProcessData, should it be fixed to work with prelaunched processes? Or should we just never rely on initialProcessData.

I think a natural place for this would be in ContentParent::ForwardKnownInfo() after we transform a preallocation into an app/browser.
Flags: needinfo?(wmccloskey)
I think it does make sense for us to make this work. ContentParent::ForwardKnownInfo() seems like a reasonable place to send the data.
Flags: needinfo?(wmccloskey)
Any chance you can take a look at this Fabrice?
Flags: needinfo?(fabrice)
Yes, I will take a look.
Assignee: nobody → fabrice
Flags: needinfo?(fabrice)
This is actually fixed by the patch in bug 1214133 where we change the way we preload the extension code for perf reasons. One stone, two birds.

Feel free to re-open if you hit that again.
Closed: 4 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1216028
I was testing the sample add-on .
It was working as expected when injected in system app. But when i injected same in SMS app (replaced 'system' with 'sms'). It didn't work as expected.
Flags: needinfo?(fabrice)
(In reply to kumar rishav (:rishav_) from comment #14)
> I was testing the sample add-on .
> It was working as expected when injected in system app. But when i injected
> same in SMS app (replaced 'system' with 'sms'). It didn't work as expected.

Kumar, what was your buildID?
Flags: needinfo?(fabrice) → needinfo?(rishav006)
Version 44.0a1 (2015-10-19)

Built from

Build platform

Flags: needinfo?(rishav006) → needinfo?(fabrice)
Name 	Firefox
Version 	44.0a1
Build ID 	20151019030227
It looks like the CSS file is not getting loaded properly in the SMS app. I see the JS file running fine though. Let's use bug 1216543 to track it. Thanks for the report Kumar!
Flags: needinfo?(fabrice)
QA Whiteboard: [COM=Add-on]
Hi Michael,
But sample add-on (MDN sample add-on) doesn't have any css file. Still it's not working in any app other than system. Can you point out to any working add-on (github link) which is injected in app other than system.

Flags: needinfo?(mhenretty)
The sample add-on does indeed have a css [1]. Here's an add-on that is injected into the twitter app [2].

Flags: needinfo?(mhenretty)
Hi Michael, 
Thanks for the links.

Sorry, but i tried without css files, but still result is same.
Here you can find the sample add-on.

Please help, where i am doing wrong. This addon is not getting injected anywhere other than system.
Flags: needinfo?(mhenretty)
Ah, you know what, I bet you are running into bug 1220700.
Flags: needinfo?(mhenretty)
Yeah, i think, you are right. Some issue with new build of FxOS. 

Will try with old builds.

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