I am working on a Chrome extension that needs to call a native application.
As per Google documentation, we are using the chrome.runtime.connectNative method.
However in our extension, it seems that the chrome.runtime object has no method 'connectNative'. When we display the list of methods of the chrome.runtime object, we get the following list (printed by console.log("" + Object.getOwnPropertyNames(chrome.runtime));
getManifest,getURL,reload,requestUpdateCheck,connect,sendMessage,onConnect,onMessage,id
We are using Chrome 31.0.1650.63 on MacOS X 10.8.5 . We have also tried with Chrome Canary (version 34.0.1767.0 canary), we have the same error, with a slightly different list of methods for chrome.runtime:
getManifest,getURL,setUninstallUrl,reload,requestUpdateCheck,connect,sendMessage,onConnect,onMessage,id
So, in both cases (regular Chrome and Chrome Canary), we don't have the 'connectNative' method.
This does not seem to be a permissions problem, our extension manifest does have "nativeMessaging" in the permissions attribute. When we click on the permissions link in the Chrome extension settings, we can see that the extension can "communicate with cooperating native applications".
(sorry I couldn't post screenshots or the full manifest, StackOverflow won't let me paste things that even remotely look like I'm posting an image since I don't have enough reputation....)
Are we missing something ?
The list of properties of chrome.runtime you are getting indicates that your code is running as a content script. Most chrome.* APIs are not available to content scripts. They can only be used from background or event pages, popups, or other extension views you define. So you can use regular extension messaging from your content script to a background or event page, which in its turn can call your native app.
Related
I am trying to override navigator.useragent with a chrome extension. I see examples where people call the script to run in v2 extensions, but I don't know with CSP if that is possible with v3. I have a v3 extension and want to add this new feature, but I don't know if the content script can redefine it, if I need to inject a script somehow (and get it past CSP), or if there is something else to do.
I would like to append the word "Test" to the user agent retrieved in the app by navigator.useragent and also in the headers that get sent, but I am focused on the first half of the problem first.
I am trying to use chrome.windows.onCreated but I got Uncaught TypeError: Cannot read property 'onCreated' of undefined. I noticed in the samples, all calls to chrome.* API's seem to originate from background scripts? Can I not use them in content scripts?
I want to trigger clicks in my browser. Then get some information (scrape) in popup window. For that I think I will need to know when a window is opened. So I need windows.onCreated? Can I use that in content scripts? Or how will I combine background and content scripts?
From the documentation for Content scripts:
However, content scripts have some limitations. They cannot:
Use chrome.* APIs (except for parts of chrome.extension)
Use variables or functions defined by their extension's pages
Use variables or functions defined by web pages or by other content scripts
These limitations can indirectly be avoided, mainly by sending messages within the extension. The documentation offers several examples which involves message passing. Prior Chrome 20, the message API methods was called onRequest and sendRequest. Since version 20, they're called onMessage and sendMessage.
Here's an answer which mentions the steps how to pass a message from a content script to a popup:
https://stackoverflow.com/a/11617742
"NaCl is currently only turned on by default for applications/extensions from the Chrome Webstore, or unpacked extensions for development purposes." - the Internet
Yet I can't seem to be able to use NaCl from an unpacked extension. (I did not try the Web Store.)
I have a really simple test extension which has the following in its background.js:
function clicked() {
var testNaclElement = document.createElement("embed");
testNaclElement.setAttribute("type","application/x-nacl");
testNaclElement.setAttribute("width",0);
testNaclElement.setAttribute("height",0);
document.body.appendChild(testNaclElement);
alert(testNaclElement.postMessage?true:false);
document.body.removeChild(testNaclElement);
}
chrome.browserAction.onClicked.addListener(updateIcon);
updateIcon();
This extension reports true when the NaCl is enabled in chrome://flags, but when NaCl is disabled in chrome://flags (which is the default) it reports false.
I expected it to report true.
What am I missing?
Update:
It seems that inventing my own detection code not such a good idea after all.
If I create and install an unpacked chrome webapp that points to url X, then NaCl will work on that page, but this detection code will still report false, while the very same code reports true when on a normal webpage with NaCl enabled in chrome://flags.
BUT if create an extension (not a chrome webapp) that uses NaCl in an iFrame which points to url X, then NaCl will not work in it.
BUT if I create a webapp that points to url X and an extension that uses url X in an iFrame, then both will work if installed at the same time.
Update2:
If I actually include the nmf and nexe in the extension, then it works.
Update3:
nexe needn't be included in the extension.
Chrome requires nmf location to belong to extension. Empty nmf attribute doesn't have this property.
a better way to detect if a NaCl module is loaded is to use progress events. see https://developers.google.com/native-client/pepper16/devguide/coding/progress-events for the enumeration of events and an example.
about the url X -- i don't think events propagate pass iframes if the iframe's URL and the container's URL domains differ -- and any enabling of NaCl in the web store or unpacked extensions corresponds to an URL (possibly with a special proto-spec; i don't know the details), so that might explain the various combinations that you're seeing. it probably also depend on how you specified the URL set in the webapp manifest.
the code's testNaclElement lack a src= attribute/value pair. it's been a while since i looked at the NaCl plugin's code, but that might also cause problems.
I come from Chrome extensions, so I'm used to defining when a file should be injected by setting run_at, e.g., to document_start for injection before DOM construction. Is there an equivalent for Firefox addons?
Yes, the equivalent would be the content-document-global-created notification. An extension can add an observer for that notification and then do something with the window - like injecting a content script. See How to override JS function from a firefox extension? for one example of using this notification.
If you use the Add-on SDK it will do this job for you. The page-mod package supports a contentScriptWhen parameter - you can use "start" as its value and the content script will be injected before any page scripts get a chance to run.
I'm wondering, is it even possible to treat the request for the Xul Browser component to open a new window? I tried changing the window.open function, but looks like it's never called.
All links that open in a new window are not opening in my application.
I found this page on the subject, but the provided solution is showing no different behavior.
Any hint on this?
(by the way, I'm developing a stand alone application, not a Firefox's extension)
I'm assuming you are in a XULRunner application, and that you are trying to load a chrome URL from a non-chrome source in a browser (e.g. HTTP or local file). While enabling UniversalXPConnect and UniversalBrowserWrite can be helpful, they are also a security risk (since any arbitrary script on the web could use them), so they tend to be disabled in browsers (for example, running that line in Firebug will give you an exception):
>>> netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect UniversalBrowserWrite");
Error: A script from "http://stackoverflow.com" was denied UniversalXPConnect UniversalBrowserWrite privileges.
How about you try using codebase security principals and see if that makes a difference? (http://www.mozilla.org/projects/security/components/signed-scripts.html#codebase). For me in Firebug it does allow me to get the additional permissions after I OK it with a big, nasty looking dialog), but still doesn't allow me to open a Chrome URL with window.open. The next step is probably to try changing your conf file to use contentaccessible so that the relevant parts of your content are accessible (see https://developer.mozilla.org/en/Chrome_Registration#contentaccessible).
To avoid the nasty message when elevating permissions, you could try setting permissions for the right files automatically as described at http://forums.mozillazine.org/viewtopic.php?f=38&t=1769555.
Also, make sure you check the browser type (https://developer.mozilla.org/en/XUL/Attribute/browser.type). If the browser type is not chrome, then it might be worth trying making it chrome and seeing if that makes a difference.
If any of my assumptions are wrong get back to me and I will try something else.
does normal js not work?
window.open(url,windowname,flags);
There are two ways that I know of.
The first is to set the browser.chromeURL preference to a chrome URL that contains a <browser type="content-primary">. The page that the content window tried to open will load into the given browser.
The second is to set the property window.browserDOMWindow with an object that you define to implement the nsIBrowserDOMWindow interface. This allows you to divert the open call into a tab, if you are using a tabbed interface. Note: the tabbed browsing preferences must be set to allow windows to be diverted into tabs, otherwise XULrunner will fall back on browser.chromeURL.