I have recently developed a google chrome extension that uses an NPAPI plugin made using the FireBreath framework. I just now found out that google will shortly discontinue these types of plugins and eventually ban all existing extensions that use them. So, I would like to eventually move to the NaCl / PPAPI architecture, but I am not sure if this architecture can even support what I am currently doing in the NPAPI plugin.
In my current NPAPI plugin I am supporting OSX and Windows. On the OSX version, the plugin executes the system() function which executes a small 1 line applescript. It looks like this:
osascript -e 'tell app ...
On the windows version, it executes functions in a COM library. Both versions end up doing the same exact thing. Another option I have is executing a python script, if I were to go this route, I would most likely want to embed python in the native component.
Is any of this possible anymore with NaCl / PPAPI?
The ability to run arbitrary system() function or execute arbitrary functions from a COM library is #1 reason for NPAPI deprecation. Ditto for execution of a python script (you can execute python script in NaCl, of course - but it'll not be able to call system() function or a COM library either).
It's not news: as was noted in the Chrome Comic book on the day of Chromium release NPAPI plugins are unrestricted and that it's a big problem: http://www.google.com/googlebooks/chrome/small_30.html
It was obvious even back then that this situation can only be tolerated for so long. Plugins were tolerated for five years because some important things were unimplemenatble without them but now it's time to kill plugins and make sure nothing in browser can access OS directly.
If you want to implement some functionality which can not be implemented in browser currently because there are no appropriate API the right way is to ask about it on chromium-dev and add this API to Chromium (and perhaps other browsers, too). For example access to COM ports (not libraries) was added recently (see http://developer.chrome.com/apps/app_hardware.html).
Since you are already using an extension, you may want to look at Native Messaging as a replacement for your use of NPAPI.
If you don't need an interaction between browser and the application, you can use external protocol support. You need to register protocol in the registry on Windows. I don't know how external protocols work on OSX. When user clicks external protocol link, Chrome shows a dialog which allows user to launch the application.
Related
This question is pretty short and self explanatory. I'm wondering how I can run my Chrome extension in NW.js.
I know you can run an app in NW.js and I think you can run extensions as well?
I can't find much on the topic. Back in 2013 the way to do it seemed to be:
nw [path to manifest.json] --load-extension
Any ideas are appreciated!
Yes you can.
First off, download the extension you want. For this example I'll be using this debugging tool, which adds an additional tab in the dev tools window.
Inside your NW.js package.json file, ensure you have an entry called chromium-args.
Ensure its value contains --enable-extensions --load-extension=relative_path_to_extension_manifest.
My package.json looks like this:
After restarting the application, the extension shows up as expected:
Something I'll add is that the full Chrome API might not be available to you. I couldn't find info about what NW.js supports, but Electron definitely does not support the entire API, so this might have similar restrictions.
I also noticed you mention in the comments that you need to assign a hotkey of sorts. I'd need to know what you were trying to do, but essentially you have the option of either using a browser mechanism such as addEventListener('keydown', myHandler) or using the NW.js API depending on your exact needs.
I am creating a custom protocol handler for Google Chrome on Linux. My link looks like this:
Trigger my app with param
I have noticed that if 'myprotocol:' is not registered (my app not installed), Google Chrome on Linux displays "External Protocol Request" dialog and tries to use xdg-open:
While on other OS, such as Windows 10 and OS X El Capitan nothing is displayed if protocol is not registered.
I have also verified that Firefox works consistently for unknown protocols on Windows, OS X and Linux - nothing is displayed.
Chrome behavior on Linux is quite confusing for users.
Any idea why Chrome on Linux (I was testing on Ubuntu 14.04) acts differently from any other OS and web browsers?
The issue is really that if Chrome lacks a local protocol handler then it wants to use the handler configured in the user's environment. No two OSes provide exactly the same API to launch a default handler. Figuring out what this program would be before actually launching it is not even a clear API on Windows or Linux.
Both the "Mac" and Windows implementations end up knowing which external application is ultimately responsible for the protocol and therefore are able to suppress unhandled calls without issuing a call warning. But the windows implementation is actually a kludge that relies on observations of the windows registry on existing versions on windows. This type of API violation is more dangerous on Linux where many flavors have very different forks of the related settings tools.
It is actually considered a bug that Windows and OsX don't issue an alternate warning that they've called nothing, so you may want to comment here if you think that is the right behavior.
Here is my observation of how the 3 systems work based on the current source:
Linux
In Linux, when you register protocol handlers with the (window) system, you do something like:
xdg-settings set default-url-scheme-handler myprotocol evolution.desktop
Now, the application evolution is responsible for your protocol and anything can call:
xdg-open myprotocol:...
To now open evolution on these links. The other OSes have similar mechanisms, but may not have an external program as the call stub.
This is nice and abstract and knowing/saying the external app you are calling is xdg-open prevents much complication in the linux implementation. But it is not exactly the information the user probably wants. Getting that information would require using xdg-settings instead and risks being incorrect if there is or ever will be a way to conditionally override the default handler in some flavors of this system.
Windows
In the Windows handler, apparently you can just go snooping around in the registry and then make an educated guess as to what calling the api is going to actually do. Technically, chrome has to do this since the way it opens external programs is through a system API, so there is not an external stub like xdg-open to refer to in the warning.
Mac
In the "mac" handler, there is a proper API to ask about the app your specific URL will launch, so chrome does, then if the application name the empty string it can completely drop the call before generating the warning.
There is an API in windows called URLDownloadToCacheFile that downloads data to the Internet cache and returns the file name of the cache location for retrieving the bits.
Is there any API (C/C++) in linux that downloads a file from internet?
There are some libraries (eg. curl, ...) that useful for downloading but I want a simpler API that does not deponds on any other libraries except browser.
Note that I want a C/C++ API, not a command line tool.
Thanks
A browser is an external application. On a typical Linux system, there's nothing which has the status comparable to that of IE on Windows. You can use Firefox as your browser; you can also completely uninstall Firefox and use only Chrome; you can even use w3m exclusively and no single GUI-based browser.
You seem to be somewhat confused about the differences between Windows and other operating systems.
There's no monolithic "browser" or "Internet cache" built into linux. In Windows you're simply using a function from a library they provide, but it's integrated into the OS (along with Internet Explorer).
There's really no parallel in linux. The OS is not tightly coupled with applications running on it. Using cURL, etc is how you approach what you're trying to do.
Like the other answers noted, there is no such thing as a built-in HTTP API on Linux systems, and you should be quick to accept that you need a HTTP library to do the task. But fear not, linking to libraries and deploying programs linked to libraries is much easier and less error-prone than under windows systems, so library dependencies are not that much of an issue.
libcurl is a well-established solution for HTTP and HTTPS.
After a lot of searching I have yet to find a way to sign a BlackBerry application on a Linux distribution with no GUI.
As of right now I'm getting the error "Unable to request signatures until this application has completed the initial key generation.". The problem is I'm not able to register the CSI files it seems via CLI. Has anyone accomplished this without setting up X11?
Yes, its definitely possible to do this on a headless Linux box. Heck, I do it on a headless Solaris/UltraSPARC server :-)
For actually running the tool, I like http://bb-ant-tools.sf.net/ . If you are using an older version of the signature tool, you may need to make some modifications as described on http://slashdev.ca/ .
While the tool is fully controllable from command-line parameters, it does unfortunately still require access to a running X server to function. The workaround for this is to install "Xvfb" (a fake X server for purposes like this), launch it in the background on your system, then set the DISPLAY variable so the signature tool will use it for its non-interactive GUI.
Blackberry sigtool may not be supported in Linux and it may be only partially working. BB dev tools are still Windows-centric.
I've used Python webbrowser module and I would love something equivalent in Erlang. What I am trying to do is open a browser window/tab from Erlang.
I can't find anything in the official Erlang documentation. Is there such a thing?
I assume you mean the Python webbrowser module, not webserver. The code for this module is instructive; it looks for various browsers and picks the best option. It interacts with the browser by running a shell command. Firefox supports a -remote command line argument to control an existing Firefox process. (IE seems to be handled simply by passing the url to the iexplore.exe)
The module also detects if it's running on Windows and tries to find out the Windows default browser and use that. Likewise, on Mac OS X, it uses the open command, which will use the default browser.
You should be able to implement this with open_port/2.