I think your earlier idea of communicating to a server limited to localhost is a better approach.
For starters that is cross-browser compatible, although limited to machines running windows. If that client opened a websocket connection then the external server can “push” things at the browser.
I’d agree, if javascript ctypes was enabled still, it would load a exe/dll instance for each tab which could eat ram quickly, however the Native Messaging appears to have the ability to eat ram by calling multiple instances of the exe/dll, unless a Mutex can restrict the exe/dll to a single instance, that I’ve yet to establish at this stage.
Connectionless messaging
A new instance of the app is created for each message. The app passes two arguments when starting:
So it looks like Connection-based messaging is the most resource efficient, using Background Scripts only.
Background scripts run in the context of a special page called a background page. This gives them a window global, along with all the standard DOM APIs provided by that object.
So I’m guessing here, Nettalk would just need to be set up as a port listener for the UTF-8 JSON data, and then respond accordingly, but it appears that the Firefox extension always need to initiate the port communication first, which would also mean ensuring the exe/dll is loaded.
We are responsible for installing the exe/dll as well and the only way to install a exe/dll within the confines of windows appears to be to write a batch file because python isnt always installed on a windows pc and then use the batch file to install the exe/dll or load it accordingly.
App manifest
In the example above, the native application is a Python script. It can be difficult to get Windows to run Python scripts reliably in this way, so an alternative is to provide a .bat file, and link to that from the application’s manifest:
One other benefit of the batch file, would be testing for later versions and automatically installing them, outside of the firefox extension updates route.
I havent found out if powershell scripts can be used, but powershell can be disabled using group policy or even not installed using methods like the autounattend.xml where as batch files cant be disabled.
Only other thing I need to establish is automatically installing the extension. Kaspersky Anti Virus installs its browser extension automatically when installing their product onto windows, which I like because its so seamless, so just need to track that functionality down and then I think it would be possible to knock something up, once I get my hands on a new Clarion IDE.
Well, yes exactly. That’s what I mean by a server listening on locahost. It has to be running in order to listen. The browser has to initiate the connection because it is the client.
Or just run a regular windows install of your program on the box. Or just copy the EXE and DLL’s onto the box. It all depends on your context here. Not sure how batch files or python come into the mix…
I got the impression there is some security restriction which firefox applies, ie it wont interact wirh a server unless its specified in the manifest.
Until I try I wont know if this is the case or not, but from a practicality POV, installing everything in one go when the extension is installed would be preferred rather than seperate manual installation processes.