because I still have to use create… to open the extension gui from the back ground page, I >have to< use an id to communicate with the tab. HOWEVER, when specifying
an id in the manifest, the add-on loader burps with INVALID EXTENSION.
This appears to be hogwash as it loads WITHOUT the id (applications.gecko.id)
in the manifest ( It just has a ‘what we got here is failure to communicate’)
SO, HOW pray tell do I get it to accept a properly formatted UUID as an ID???
Thank you
Could you show us you manifest.json with the ID set?
Martin: Thank you for the response. Here is the manifest.
If applications.gecko.id is removed it loads, otherwise ‘invalid’.
{
“manifest_version”: 2,
“name”: “dflibg/js dfirefly”,
“description”: “dflibg/js lightning bug dataflow developer tools”,
“version”: “0.7.14.51”,
“applications”: {
“gecko”: { “id”: “49fe582f-2b98-407b-881b-f4680af94065” }
},
“page_action”: {
“browser_style”: true,
“default_icon”: { “19”: “flowbug0_19x19b.png”,
“38”: “dflowbugG38.png”,
“48”: “flowbug0_48x48b.png”,
“96”: “flowbug0_96x96b.png”
},
“default_title” : “dflibg/js dfirefly (dataflow sdk)”
},
“background”: {
“scripts”: [“daemon.js”]
},
“content_scripts”: [{
“run_at”: “document_start”,
“matches”: [“http:///” ],
“js”: [“dfcontent.js”]
}] ,
“web_accessible_resources” : [
"/sdkfirefly.html",
"/dflibg/include/",
"/shared/include/",
"/shared/graphlib/",
"/shared/iconlib/",
"/shared/fontlib/",
"/dflibg/sdk/images/"
],
“permissions”: [
“activeTab”, “tabs”,
“http://192.168.2.35/",
"://www.chrysalis-systems.net/*”
]
}
That is not the proper format for a UUID. It needs to be inside { } like it used to with an install.rdf.
Thanks, Martin:
I think I’m about ready to “give up hope all ye who enter” in trying to get this web extension
to work as it does with Chrome 26-5x+. It used to work with FF dev edition 45,46,47.
I don’t know if something in FF48 that was added to remove the necessity for id’s being
assigned had some unforeseen side-effect. I can only imagine.
The general/communication architecture of the extension uses the port interface.
It does not use anything else fancy - the background (persistent daemon) is just
a message forwarder/bridge from the GUI page it starts (on pageAction) to
the embedded content script in the active Tab. It uses the port facility to bridge
these realms [ port=(chrome.runtime.connect({name:})]
Could something have changed in the support for the ports in chrome.runtime??
I can not anymore even open dev tools/inspect on the GUI page that the daemon opens correctly,
a window opens but is blank - and a spinner keeps spinning in the GUI page.
[FF developer edition opens a debugger session with the background page just fine]
As I said, it works all seamlessly in Google Chrome. (and once upon a time in a FFox galaxy far far away )
Oy vey.
Thanks, Chrys
aka ‘confused in jersey’
An update:
One of the communication disconnects/misconnects is occurring because FF regenerates
the ‘hostname’ internal id and it has no relationship to the id known to the manifest.
The embedded library compares window.location.hostname against the extension id
to determine whether it needs to use a cross-extension protocol or exxtension->daemon->tab
protocol… Chrome uses the extension id as its internal id and the hostname. So for
firefox I have to figure out some other way to access the developer-assigned id.
Thanks for the help
An update 2:
chrome.runtime.id did the trick – I remember giving up on finding an api for acquiring the active extension id many moon’s ago when the hyperlink in the google chrome runtime api page for id went to some other place. oh well, thanks for your patience.
Just as a heads up, I’m not sure how stable this is, I think there is work being done to mitigate fingerprinting issues with the current extension URI system while also avoiding leaking information of installed extensions.