I would very much like to have the ability to build an SDK add-on which allowed wildcards (even if you only implemented the wildcard "*") for privileged cross-domain content script content). While you would no doubt not want this on AMO, since you already support this with a whitelist, I would expect it could be implemented with a minimum of effort, yet expose a great deal of functionality. You could easily check on AMO to disallow this particular configuration, but please throw a bone to those of us who have wanted for years to have a way to make our own browser interface/prototype whose code was itself executed from a website (i.e., a browser in a browser).
I see there is bug 786681 about similar feature. NB: retriage if I'm wrong.
Component: Untriaged → General
Product: Firefox → Add-on SDK
(In reply to Loic from comment #1) > I see there is bug 786681 about similar feature. > > NB: retriage if I'm wrong. I too am curios if this wildcard functionality would be possible. I'm working on a plugin which communicates with devices on the local network (set up through configuration of a separate internal application that postMessage's its configuration to the plugin) - so like 192.168.0.127:123456. However, given that these are configurable, I can't ahead of time provide the exact entries in the permissions:cross-domain-content entry. From all I've read in bug 786681, the wildcard functionality isn't implemented. Please advise if I'm just overlooking something. Thanks! :)
I want to echo @email@example.com and @Brett Zamir, this is hugely important. We are also building a solution to talk to local LAN devices, where a fixed whitelist will not work. We already have it working in Chrome, as Chrome does not have this restriction. They allow cross-domain requests. I understand the security implications, but this is a showstopper for us being able to deploy as a plugin in FireFox. Seems like it would be a fairly simple fix, as Brett Zamir indicated, and would allow the plugin author to define who they want the code to make requests to. Please consider this -- I'd be happy to take a stab at it and submit a PR if someone could point me where the code in question is that manages this.
We're not implementing any new features in the SDK. The future of add-on development is in WebExtensions (https://developer.mozilla.org/en-US/Add-ons/WebExtensions), so I suggest you focus your efforts there and let us know what you need to migrate to it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
Jorge, I can appreciate that, and I would love to. Unfortunately your Web Extensions implementation is not finished, and thus I cannot use it. I already have built a solution that is Web Extension compliant and works in Chrome, but we want to support FF as well. I can't, it seems because you guys don't support cross domain calls and your web extension implementation is incomplete. In this case...for this bug, it really seems like it could be fixed fairly easily with a simple regex test. Would be great to support the community in the interim while we wait for web extensions to get finished.
Is there a bug open in WebExtensions for that?
Andy, I didn't add a bug in WebEx -- more specifically, I am waiting for WebEx to finish implementing a few APIs, the most critical one being: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessageExternal We are rolling out a payment terminal solution for point of sale. The code that talks to the payment terminal runs in a Chrome extension, and uses the runtime.messaging. We need to support Firefox too, and it is awesome that the Chrome stuff has converged into a standard, but we can't use WebEx until it's ready in FF. Didn't think it made sense to add a bug for a "to be implemented" API, but it does beg the question if you're also going to support wildcards for runtime.messaging or not? Chrome does, and it is a necessity for us, b/c the terminals we talk to are on local LAN and there's no way we can whitelist them all. So, we instead went down the path of trying to implement in the SDK instead, and almost got it working, but then got hit with this, b/c we cannot make cross-domain requests with a wildcard. So we are stuck for both paths with FireFox. I'd love nothing more than to re-use the code we've already written and exchange s/chrome.runtime/browser.runtime/ but we can't until it is ready. If there's any other way past these issues that you can see, I would love to hear it.
onMessageExternal is bug 1253643. If there is stuff you want in WebExtensions, we encourage people to file bugs otherwise it won't get implemented (but I will note filing a bug is no guarantee it will). If it's a simple fix, perhaps it would make sense to send in a patch for the SDK?
And that bug points to bug 1258360, which looks like it has some patches in progress, so that's good news.
Yep, saw that. There is support for browser.runtime.sendMessage https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/sendMessage but we need the other half to be able to receive it and we'd be golden. If there were a development branch we could use, I'd even try that...
Guys, based on my experiences, I *strongly* suggest not getting your hopes up with WebExtensions and needlessly stringing yourselves along. I suggest this both because the browsers have been very skittish about adding anything inherently dangerous to their browser APIs (except Geolocation) and even our previous champion of power users and power-developer freedom, Mozilla, has made no extra efforts to accommodate us in the add-on world while they try to solve the admittedly important problem of simplifying their own add-on review processes by avoiding risky APIs and minimizing the risks to users encountering third-party add-ons. If you want to see some past evidence of this lack of accommodation, see https://bugzilla.mozilla.org/show_bug.cgi?id=546848 and https://bugzilla.mozilla.org/show_bug.cgi?id=823811 . I'm not saying this to complain here (though I definitely could), but rather to save you from wasted efforts (unless there has been a change of heart I don't know about). Perhaps you might find nw.js to be a more promising avenue for your efforts: http://nwjs.io/ and https://github.com/nwjs/nw.js/wiki/Mini-browser-in-iframe Good luck!
You need to log in before you can comment on or make changes to this bug.