FireBreath 2.0 plans

1,341 views
Skip to first unread message

Richard Bateman

unread,
Jan 19, 2015, 3:12:37 PM1/19/15
to FireBreath Dev Group
Hello,

Many of you have wondered about the future of the project, as well as what we're all going to do once Chrome is released.  The good news is:

We have a plan!

The upshot of this, though, is that it won't solve all of the problems and it's going to require some help from the community.

Let me be clear on this: I can't do this adequately alone.
See the end of the email for what help I need.

For complete details (if you might use it at all, I really recommend reading everything) see below.  Here is the TL;DR version:

TL;DR:
----------
FireBreath 2.0 will support current protocols as well as Native Messaging, but hypothetically could support any of the following:
* NPAPI
* ActiveX
* Native Messaging (using FireWyrm)
* NaCL/pNaCL (if we can make it build, and will use FireWyrm)
* Web Sockets (using FireWyrm)
* HTTP Ajax PULL (using FireWyrm)
* Telnet (using FireWyrm)
* IP over Avian Carrier (https://tools.ietf.org/html/rfc2549) (using FireWyrm)

Major changes will include:
------------------------------------

* Everything will be asynchronous!
* Calling a function on the plugin will return a Promise
* Getting a property from the plugin will return a Promise
* Calling into the DOM from the plugin will also be asynchronous
  - Most likely we'll use C++11 lambdas, std::promise/std::future, etc
* Drawing models will need to be developed, but will essentially be browser-based
  - WebGL, Canvas, possibly NaCL/pNaCL and/or emscripten, etc
  - Drawing models will also be asynchronous
* FireWyrmJS will provide a simple abstraction for using a FireWyrm plugin from Javascript
* FireWyrmJS will require that a WyrmHole (transport mechanism) be provided
  - The most common WyrmHoles we anticipate seeing would be ones for Native Messaging and js-ctypes
  - Many of these may require a browser Extension; we could probably create a FireBreath extension which would be usable by all

Possible improvements:
--------------------------------

* Better cmake support (run cmake on your project, not on FireBreath)
* Use FireBreath as a static library (I have a plan that might work, but I'm not promising)

The basic plan:
---------------------

FireBreath 2.0 will attempt to address several long-standing complaints about the framework as well as adding a whole new type of plugin support.  With the collaboration of some coworkers and other members of the community I've started development of the FireWyrm protocol.  This name was carefully chosen using the same naming methodology as FireBreath itself, which is top secret.  The point, though, is that the FireWyrm interface will allow a whole new type of plugin transports.

Fully developing FireWyrm will involve a fair bit of complexity, but at its core it will actually be a distinct thing from FireBreath -- it could be used in other projects, if someone wanted to.  In essence, FireWyrm is/will be an advanced mechanism for performing RPC calls over an essentially text-based asynchronous transport protocol using JSON.

What does this mean?

You have three pieces to this system:

1. FireWyrm client (FireWyrmJS will be our initial javascript implementation)
2. FireWyrm provider (FireBreath's third plugin type, a sibling to ActiveX and NPAPI)
3. A tranport mechanism for communicating between them, known as a WyrmHole

FireWyrmJS will connect over a WyrmHole to the FireBreath plugin (through the provider) and will get information about the root JSAPI object; it will then construct a javascript object wrapper that will create a payload, send it over the WyrmHole, and return a Promise.  (If you aren't familiar with the Promise pattern, I suggest you read up on it a bit).

What this means is that any transport mechanism that you can find that will connect the two points of code can be used to connect to this plugin.  On the C++ side a new set of FireWyrm provider entrypoints will be created which should make it relatively easy to create the c++ side of the WyrmHole.  The initial implementation of a WyrmHole will use Native Client in order to instantiate the plugin.  We'll essentially create a thin executable which will load your FireBreath 2.0 plugin using the FireWyrm entrypoints and will communicate with the browser, allowing you to use your same plugin.

Limitations:
---------------

I'm sure any of you that is actually thinking about what I'm proposing has already noticed that there are some deviations and challenges with this idea.  I'm not sure I've identified them all, but here are the things I can think of off-hand that will change or need to be addressed:

* Initially, there will be no drawing model.
  - I expect this to change soon, but the initial drawing model will just be a pixel buffer which can be sent across the WyrmHole, likely base64-encoded
  - Eventually I expect that we will develop other drawing methods, such as:
    * WebGL proxied through the WyrmHole
    * Canvas proxied through the WyrmHole
    * Some other RPC-driven mechanism (perhaps we can find an existing one) compiled with emscripten and proxied through the WyrmHole
    * Some other HTML-based abstraction (controlled through the WyrmHole)

* All operations will be Asynchronous
  - We will be relying heavily on the Promise pattern, both in C++ and JavaScript
  - We will be requiring at least C++0x and possibly C++11 (std::promise/std::future, lambdas, etc) in order to make this hurt less
  - This will apply to NPAPI and ActiveX as well! This will be a relatively HUGE change
  - All property get calls will return a Promise
  - *All* method calls will return a Promise, though ones that return void it will only tell you it completed
  - We will attempt to find a way to allow calls to be batched in such a way that a series of operations can be sent at the same time and the code will continue when it's complete

* We will require C++0x at least, possibly C++11
  - I want to use lambdas, possibly std::promise and std::future, and others




What I need help with

If you want to see this happen, I need some help.  First, I need someone who knows the new C++11 features well to help me think through how we can simplify things using them -- I have never used them before.  Second, I need help thinking through all the various challenges this will entail.  Third, I need people around to bounce ideas off of as I work through things.

If I develop this in isolation, it will be crap.  FireBreath is what it is because I've drawn on a lot of people who have helped me figure out the best way to do things -- I need that again, but those people have moved on.

The main place this discussion will take place is in the #firebreath room on irc.freenode.net.  I am always signed in and check in when I can, which is less often than it once was.  However, searchable logs are available on http://logs.firebreath.org

If I can find people who understand what is going on well enough I'd love help with the code as well.  No huge time commitment is required, but I do need help.



I look forward to all of your responses.

Richard a.k.a. taxilian
FireBreath founder

Billy Simon

unread,
Jan 20, 2015, 11:06:24 AM1/20/15
to firebre...@googlegroups.com
Hello Richard,

My C++ is very basic but maybe I can help with the ideas part.  I have a little experience with Chrome Native Messaging now that I finished reimplementing my digital signature plugin using that technology.

Thanks for the great effort. 

Richard Bateman

unread,
Jan 20, 2015, 12:13:54 PM1/20/15
to FireBreath Dev Group

Billy,

Thanks for responding.  I can use all the help I can get.  I'll generally be in the #firebreath room during the day... ping me sometime and you can help me think through use cases.

Who knows, maybe others will join us as well...

Richard

--

---
You received this message because you are subscribed to the Google Groups "firebreath-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebreath-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Uuno Turhapuro

unread,
May 12, 2015, 3:09:23 AM5/12/15
to firebre...@googlegroups.com
How would you handle Microsoft's new default browser in Windows 10, Microsoft Edge, since it does not support ActiveX, NPAPI or Native Messaging?

Alexandre GOUAILLARD

unread,
May 12, 2015, 5:40:05 AM5/12/15
to firebre...@googlegroups.com
it will support activex

On Tue, May 12, 2015 at 3:09 AM, Uuno Turhapuro <re6d...@gmail.com> wrote:
How would you handle Microsoft's new default browser in Windows 10, Microsoft Edge, since it does not support ActiveX, NPAPI or Native Messaging?

--

---
You received this message because you are subscribed to the Google Groups "firebreath-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebreath-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
CTO - Temasys Communications, S'pore / Mountain View
President - CoSMo Software, Cambridge, MA
------------------------------------------------------------------------------------

Langdon

unread,
May 12, 2015, 8:54:20 AM5/12/15
to firebre...@googlegroups.com
Alexandre, I think you're mistaken, ActiveX will not be supported in Microsoft Edge.

Dr Alex Gouaillard

unread,
May 12, 2015, 11:25:40 AM5/12/15
to firebre...@googlegroups.com
Shijun sun, program manager at MS in charge of IE, W3C and IETF standard committee member in the webrtc working group with me, confirmed a few weeks back that edge would support plugins even though it will be done through a specific mechanism. 

They want to restrict the plugin usage by default but need to provide a solution for enterprises to keep using the products (including Microsoft own products) that depends on plugins through IT policies and rules. There will be two ways to start edge from the system.

Happy to introduce anyone to MS representative if needed. Better to wait until release date to start asking practical questions.

Sent from my iPhone

John Dexter

unread,
May 12, 2015, 11:34:39 AM5/12/15
to firebre...@googlegroups.com
Very interesting. I thought's MS' support for enterprise plugin requirements was "use IE instead of Edge" since W10 will ship with both. But if they provide secret support in Edge/Spartan, that'd be nice.

Alexandre GOUAILLARD

unread,
May 12, 2015, 11:57:14 AM5/12/15
to firebre...@googlegroups.com
Here are my exact notes from the discussion:
""
Spartan will be uniquely based on the new (H) engine, while a separate app that will be equivalent to IE 11 (with support to plugin) will also be available, mainly for enterprise customers. Spartan will be the default, and it will not be possible to make the IE one default, forcing average user out of IE.
""

Langdon

unread,
May 12, 2015, 4:53:49 PM5/12/15
to firebre...@googlegroups.com
So from your notes, Microsoft Edge will not support ActiveX.  This is the same information that is being reported on sites for the past few days.


I think what you're saying is that IE11 will still run on Windows 10 for a some time to ease transition.

Alexandre GOUAILLARD

unread,
May 12, 2015, 5:22:19 PM5/12/15
to firebre...@googlegroups.com
no, there will be two "modes", one only accessible through IT policies and other enterprise tools, which will supports plugin. It will be equivalent to IE11 in terms of feature, but no use the same engine (trident).

Uuno Turhapuro

unread,
May 13, 2015, 2:05:29 AM5/13/15
to firebre...@googlegroups.com
The new Edge browser will also support browser extensions, although not available at launch. These extensions have been said to be similar to ones currently used by Chrome. This is pure speculation but there just might be some mechanism in the Edge's extensions that would allow talking native appllications similiar to Chrome's Native Messaging.

Fabrizio Ammollo

unread,
May 26, 2015, 11:30:34 AM5/26/15
to firebre...@googlegroups.com
Hello,

I'm very interested about the the new implementation, because soon Google Chrome will drop NPAPI support and it seems to me that the new FB 2.0 would be an excellent way to avoid rewriting from scratch a plugin.

I tried compiling the "refactor" branch on Visual Studio 2013 Express but I have a couple of problems trying to compile both examples (EchoTestPlugin and FBTestPlugin):
- boost is not correctly included in the generated Visual Studio solution (with FB 1.7 there are subprojects for the used boost libraries that require a compilation)
- atlbase.h is not found by a particular file (I successfully compiled FB 1.7 using the Windows DDK, I suspect this is another CMake project issue)

I would like to know if I am doing something wrong, if I should not yet try to compile this code since it's in active development, or if this could just be an environment issue caused by the Express edition.

Thank you in advance and Best regards,
Fabrizio

Richard Bateman

unread,
May 27, 2015, 10:00:11 AM5/27/15
to FireBreath Dev Group

There seem to be some issues with building on the community edition; I welcome anyone who wants to fix them to do so.  I have gotten very little help from the community thus far and frankly am a bit burned out from doing it all myself.

In short, it works fine on Visual Studio Professional and I'm not fixing the other, though I would love it if someone else did =]

Richard

Beck Yang

unread,
Jun 3, 2015, 6:36:52 AM6/3/15
to firebre...@googlegroups.com
I can compile EchoTestPlugin successful.
  • firebreath branch "refactor"
  • firebreath-boost branch "1.57.0"
  • VS 2013 express edition installed on Win7 SP1
  • ATL header/lib files are copy from Windows DDK (VS 2013 express does not include them...)
There is a link error in FireWyrmNativeMessageHost project.
I do some research and fix it by modifying "src/NativeMessageHost/CMakeLists.txt"
Here is the patch code:
*** before
--- after
***************
*** 29,34 ****
--- 29,35 ----
  include_directories(
      ${CMAKE_CURRENT_SOURCE_DIR}
      ${FB_CONFIG_DIR}
+     ${ATL_INCLUDE_DIRS}
      ${Boost_INCLUDE_DIRS}
      ${FBLIB_INCLUDE_DIRS}
      ${FireWyrm_SOURCE_DIR}
***************
*** 89,94 ****
--- 90,100 ----
      OUTPUT_NAME ${FBSTRING_HostFileName}
      FOLDER "FireWyrmHosts"
      )
+
+ if (WIN32 AND ATL_LIBRARY)
+     set_property(TARGET ${PROJECT_NAME} APPEND_STRING PROPERTY
+     LINK_FLAGS "/LIBPATH:\"${ATL_LIBRARY_DIR}\"" )
+ endif ()
 
  if (FIREBREATH)
      link_boost_library(${PROJECT_NAME} filesystem)

==== patch end ====
It should work on non-Windows platform or other environments.

BTW, this version cannot be compiled using VS 2010 express. The variant.cpp of "ScriptingCore" has lots of compile error.
Look like the C++11 support of VS 2010 is not enough.


Fabrizio Ammollo

unread,
Jun 3, 2015, 11:05:28 AM6/3/15
to firebre...@googlegroups.com
Hello Richard,

thank you for your answer.

I finished installing Visual Studio Professional today, and right after that, I saw Beck Yang's answer (thank you Beck!) :-), anyway, I compiled FBTestPlugin without any problems, but I now have problems understanding exactly all the configuration steps required to use the Chrome Native Messaging functionality, and how to test it.

Following Google's directions at https://developer.chrome.com/extensions/nativeMessaging, I registered the generated NativeMessagingHost exe into the Windows registry and I then installed the generated Chrome Extension found into the build\NativeMessageExtension using the "Load unpackaged extension..." function, and Google Chrome shows the extension as a separate task, which I think is correct.

What is less clear to me is what to do about the generated dll.

Opening the test.html page provided along the FBTestPlugin then shows problems with the plugin. From what I understand from that page (my knowledge of Javascript and HTML is not so great) its purpose is to load the plugins, but it seems to me that this way it loads them as NPAPI plugins, not using the extension mechanism which is supposed to bypass the problems caused by NPAPI being phased out. This theory seems validated to me by the fact that if I "register" the dll under MozillaPlugins, then Chome shows it as a NPAPI plugin (warning about it) and then the test page correctly loads. If I disable the plugin, the page then does not load correctly.

I think that what the user of FireWyrm based plugins is supposed to do is to leave the plugin disabled (from the code of NativeMessageHost I see that it looks for the DLLs under MozillaPlugins, specifically those with the special key FireWyrm = true) so that Chrome does not attempt to use it as a NPAPI plugin and must then use the JS functions exposed by the extension to use the plugin. It seems to me that a minimal sample page of how to do this is missing, without that I can only guess what should be done. Can you suggest me something about it?

Best regards,
Fabrizio

Richard Bateman

unread,
Jun 4, 2015, 2:02:34 PM6/4/15
to FireBreath Dev Group

I will not have time this week to respond to this properly; if you look at the irc logs (logs.firebreath.org) you might be able to find the info you want; it's there but may be hard to track down.  the registry stuff is all done by the _devinstall project, though.  There are a lot of annoying subtleties with the native messaging stuff that we don't have good solutions to yet, and the test pages don't yet work.

Richard

Fabrizio Ammollo

unread,
Jun 5, 2015, 12:27:17 PM6/5/15
to firebre...@googlegroups.com
Hello Richard,

thank you for pointing me to the sources of information about the development, I'll check them out.

Today I have temporarily switched my focus to porting a plugin we use (it is based upon BlabblePhone) to FB 2.0 and it now correctly compiles and links, but I have a problem upon executing it as a NPAPI plugin: it seems that the onload function specified within the web page that loads the plugin is not executed.

I tested this with FBTestPlugin and the behavior is the same; it seems that this code into PluginCore::setParams:

            if (key.substr(0, 2) == "on") {
                FB::JSObjectPtr tmp;
                auto dfd = m_host->getDOMWindow()->getProperty<FB::JSObjectPtr>(value);
                auto selfPtr(shared_from_this());

                dfd.done([=](FB::JSObjectPtr tmp) -> void {
                    m_params[key] = tmp;
                });

                FBLOG_TRACE("PluginCore", "Found <param> event handler: " << key);

                m_params[key] = tmp;

always sets tmp to an object with both _Ptr and _Rep members set to NULL.

I have almost no experience with the C++ standard library about these topics so I don't really know what to check. The code into FB 1.7 is not reusable because classes are now different and a plain assignment cannot be made.

Do you have already experienced, or do you have knowledge, of this problem?

Best regards,
Fabrizio

Richard Bateman

unread,
Jun 5, 2015, 3:38:22 PM6/5/15
to FireBreath Dev Group

You need to realize that this is an asynchronous call now; it has to call back into the page.  Therefore the "done" handler won't immediately resolve.  tmp in the outside scope is therefore never actually used, only the tmp in the done closure. I haven't actually tested the onLoad callback, so there may be a bit more work required to have that functional.

Richard

Fabrizio Ammollo

unread,
Jun 8, 2015, 12:04:11 PM6/8/15
to firebre...@googlegroups.com
Hello Richard,

I managed to make the onLoad callback work, although certainly not in a "clean" way, because of my unsufficient knowledge of the code, by calling setReady after invocation of the "done" lamba function related to the "onload" event.
I didn't know how to invoke setReady on the NpapiPlugin object, so, to make things a little "safer", I added a m_isReady member to the PluginCore class in order to execute it only once.

This way onLoad is correctly executed all the times it is supposed to run; I have some doubts regarding the complete initialization of parameters if there are many and not all of them are processed within the delay set for invoking onLoad (I think 250ms).

Anyway, I have discovered instead an issue that seems to be specific to Internet Explorer: upon onLoad, not all registered properties are available, "valid" in particular, because we test it and we found it undefined, which for us is a blocking error.
I am trying to debug it but I am finding more difficulties than with Chrome of Firefox: sometimes breakpoints cannot be enabled and there are C++ exceptions and I don't have an idea of what could cause them and how to track them; these are some (sorry for the Italian, the IDE is in Italian):

Eccezione first-chance in 0x7754C42D in iexplore.exe: Eccezione Microsoft C++: Js::JavascriptExceptionObject nella posizione di memoria 0x040896AC
Eccezione first-chance in 0x7754C42D in iexplore.exe: Eccezione Microsoft C++: FB::bad_variant_cast nella posizione di memoria 0x040832E4
Eccezione first-chance in 0x7754C42D in iexplore.exe: Eccezione Microsoft C++: std::runtime_error nella posizione di memoria 0x0D35BF5C.
Eccezione first-chance in 0x7754C42D in iexplore.exe: Eccezione Microsoft C++: [rethrow] nella posizione di memoria 0x00000000.

Best regards,
Fabrizio

Richard Bateman

unread,
Jun 8, 2015, 3:07:33 PM6/8/15
to FireBreath Dev Group

FB 2.0 isn't working completely on IE yet; there are certainly a lot of things broken.  It needs to be updated but I haven't had time to nor does it look promising in the next few weeks :-/

If you push your fix up to a fork on github I'd be happy to look at it and give you some pointers or feedback on how to do it more cleanly.

Richard

Fabrizio Ammollo

unread,
Jun 9, 2015, 10:18:44 AM6/9/15
to firebre...@googlegroups.com
Hello Richard,

today I have switched back the focus to Chrome. :-)

Thanks to a colleague of mine who know Javascript much better than me, we managed to build a web page using the extension and loading the plugin.
I am not entirely sure we completely did "the right thing" but, above all, I don't know how to go on after that, because I have no idea how to "interact" with the plugin (getting/setting properties, invoking methods).
Looking at the extension's code, the FireWyrmJS function seems to be central to the communication, but I have no idea of how to use it from the page (I have the idea that it should not directly called).

This is the code we wrote so far:

        var WyrmHoleObj = null;

        function pageLoaded() {
            CreateWyrmHole();
            window.addEventListener('message', function (e) {
                console.log("event listener: " + JSON.stringify(e));

                // {"data":{"plugin":"Rei...@PluginSIP.com","status":"success","source":"host","port":"FireWyrmPort1","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}}
                if ((e.data.plugin == "Rei...@PluginSIP.com") && (e.data.status == "success")) {
                    console.log("PluginSIP successfully loaded");
                    // What to do now ???
                }
            });
        }

        function CreateWyrmHoleCallBack(data) {
            if (! (typeof data === "undefined") ) {
                console.log("Received " + JSON.stringify(data));
                WyrmHoleObj = data.wyrmhole;
                WyrmHoleObj.create(data.extId, "application/x-pluginSIP");
            }
        }

        function CreateWyrmHole() {
            var req = {"request": "create", "firebreath": "Reitek S.p.A." , "callback": "CreateWyrmHoleCallBack"};

            window.postMessage(req, "*");
        }

        jQuery(document).ready(pageLoaded);



Best regards,
Fabrizio

Fabrizio Ammollo

unread,
Jun 12, 2015, 12:22:53 PM6/12/15
to firebre...@googlegroups.com
I made more experiments, this time using this code (I found it on pastebin and I adapted it):

            window.postMessage({firebreath: 'Reitek S.p.A.', callback: 'onMyPluginLoaded'}, "*");
            window.onMyPluginLoaded = function(firebreath) {
                firebreath.wyrmhole.create().then(function(transport) {
                                    return transport.loadPlugin('application/x-pluginSIP');
                            }).then(function(transport) {
                                    var wyrm = new FireWyrmJS(transport);
                                    return wyrm.create('application/x-pluginSIP');
                            }).then(function(plugin) {
                            }

and it now executes more than before, but it seems that there is a problem during communication between the extension and the native messaging host.

I have added a log file to the native messaging host in order to see what is received from the extension and what it sent to it, and this is what happens:

12/06/2015 - 18:17:29.291 Starting FireWyrm native message host
12/06/2015 - 18:17:29.293 Starting read loop
12/06/2015 - 18:17:29.293 Starting main message loop
12/06/2015 - 18:17:29.294 read len: 94
12/06/2015 - 18:17:29.294 read data: {"cmd":"create","mimetype":"application/x-pluginSIP","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}
12/06/2015 - 18:17:29.305 writing length: 52
12/06/2015 - 18:17:29.305 writing data: {"plugin":"Rei...@PluginSIP.com","status":"success"}
12/06/2015 - 18:17:29.343 read len: 139
12/06/2015 - 18:17:29.343 read data: {"cmdId":1,"type":"cmd","c":1,"n":1,"colonyId":0,"msg":"[\"New\",\"application/x-pluginSIP\",{}]","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}
12/06/2015 - 18:17:29.344 writing length: 82
12/06/2015 - 18:17:29.344 writing data: {"c":1,"cmdId":1,"colonyId":0,"msg":"[\"New\",\"browser\",{}]","n":1,"type":"cmd"}
12/06/2015 - 18:17:29.351 read len: 115
12/06/2015 - 18:17:29.352 read data: {"cmdId":1,"type":"resp","c":1,"n":1,"colonyId":0,"msg":"[\"success\",1]","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}
12/06/2015 - 18:17:29.494 writing length: 74
12/06/2015 - 18:17:29.495 writing data: {"c":1,"cmdId":1,"colonyId":0,"msg":"[\"success\",1]","n":1,"type":"resp"}
12/06/2015 - 18:17:29.495 writing length: 72
12/06/2015 - 18:17:29.495 read len: 115
12/06/2015 - 18:17:29.498 writing data: {"c":1,"cmdId":2,"colonyId":0,"msg":"[\"Enum\",1,0]","n":1,"type":"cmd"}
12/06/2015 - 18:17:29.499 read data: r c a l r p c : [ d h c p c s v c 6 , S e c u r i t y = I m p e r s o n a t i o n   D y n a m i c   F a l s e ]   ]
12/06/2015 - 18:17:29.499 Exit signaled

Notice the log line before the last one: it seems to me that the contents is "garbage" (spaces are actually NULs), memory taken from a memory location within the Chrome process that contains the extension.
I don't know what may be causing it, I can't set a breakpoint within the code injected (it shows each time as something like VMxxx).

chrome_debug.log shows this:

[159084:11104:0612/181729:ERROR:native_message_process_host.cc(291)] Native Messaging host tried sending a message that is 825899057 bytes long.

Is there any way to debug what is happening? May it be a Chrome bug (I am using the last stable version, not the development versions).

Best regards,
Fabrizio


Ilgiorno martedì 9 giugno 2015 16:18:44 UTC+2, Fabrizio Ammollo ha scritto:
Hello Richard,

today I have switched back the focus to Chrome. :-)

Thanks to a colleague of mine who know Javascript much better than me, we managed to build a web page using the extension and loading the plugin.
I am not entirely sure we completely did "the right thing" but, above all, I don't know how to go on after that, because I have no idea how to "interact" with the plugin (getting/setting properties, invoking methods).
Looking at the extension's code, the FireWyrmJS function seems to be central to the communication, but I have no idea of how to use it from the page (I have the idea that it should not directly called).

This is the code we wrote so far:

        var WyrmHoleObj = null;

        function pageLoaded() {
            CreateWyrmHole();
            window.addEventListener('message', function (e) {
                console.log("event listener: " + JSON.stringify(e));

                // {"data":{"plugin":"Reitek@PluginSIP.com","status":"success","source":"host","port":"FireWyrmPort1","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}}

Fabrizio Ammollo

unread,
Jun 16, 2015, 12:04:20 PM6/16/15
to firebre...@googlegroups.com
Hi there,

I have found out what was causing the error reported by Chrome: pjsip was sending some messages to stdout upon initialization. I "suppressed" them and now I am able to query the properties (such as valid) and invoke methods of the plugin.

One thing I have noticed is that, once every two page loads, the response to this request sent from the page to the host:

{"data":{"cmdId":2,"type":"cmd","c":1,"n":1,"colonyId":0,"msg":"[\"Enum\",1,0]","source":"page","port":"FireWyrmPort1","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}}

contains an "error" entry instead of the expected contents.

Expected contents:

{"data":{"c":1,"cmdId":2,"colonyId":0,"msg":"[\"success\",[\"createAccount\",\"getAttribute\",\"getAudioDevices\",\"getCurrentAudioDevice\",\"getLogAD\",\"getLogDimension\",\"getLogNumber\",\"getSignalLevel\",\"getVolume\",\"log\",\"logSender\",\"playWav\",\"setAttribute\",\"setAudioDevice\",\"setCodecPriority\",\"setLogDimension\",\"setLogNumber\",\"setVolume\",\"stopWav\",\"tlsEnabled\",\"toString\",\"valid\",\"value\",\"version\",\"writeLogAD\"]]","n":1,"type":"resp","source":"host","port":"FireWyrmPort1","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}}

Error contents:

{"data":{"c":1,"cmdId":2,"colonyId":0,"msg":"[\"success\",[\"error\",\"getAttribute\",\"setAttribute\",\"toString\",\"valid\",\"value\"]]","n":1,"type":"resp","source":"host","port":"FireWyrmPort1","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}}

It seems that the enumeration of the custom-registered JSAPI properties/methods failed. At first I thought this could be caused by a timing issue, but since there is an alternation, I think something else is happenimg. I'll try to debug it later.

Best regards,
Fabrizio


Il giorno venerdì 12 giugno 2015 18:22:53 UTC+2, Fabrizio Ammollo ha scritto:
I made more experiments, this time using this code (I found it on pastebin and I adapted it):

            window.postMessage({firebreath: 'Reitek S.p.A.', callback: 'onMyPluginLoaded'}, "*");
            window.onMyPluginLoaded = function(firebreath) {
                firebreath.wyrmhole.create().then(function(transport) {
                                    return transport.loadPlugin('application/x-pluginSIP');
                            }).then(function(transport) {
                                    var wyrm = new FireWyrmJS(transport);
                                    return wyrm.create('application/x-pluginSIP');
                            }).then(function(plugin) {
                            }

and it now executes more than before, but it seems that there is a problem during communication between the extension and the native messaging host.

I have added a log file to the native messaging host in order to see what is received from the extension and what it sent to it, and this is what happens:

12/06/2015 - 18:17:29.291 Starting FireWyrm native message host
12/06/2015 - 18:17:29.293 Starting read loop
12/06/2015 - 18:17:29.293 Starting main message loop
12/06/2015 - 18:17:29.294 read len: 94
12/06/2015 - 18:17:29.294 read data: {"cmd":"create","mimetype":"application/x-pluginSIP","ext":"bgpbojpjbgfpflclfjadeihjpjifclkm"}
12/06/2015 - 18:17:29.305 writing length: 52
12/06/2015 - 18:17:29.305 writing data: {"plugin":"Reitek@PluginSIP.com","status":"success"}

Fabrizio Ammollo

unread,
Jun 26, 2015, 6:08:01 AM6/26/15
to firebre...@googlegroups.com
Hello Richard,

since I am not yet able to master github, and the changes I made to make the NPAPI onload event work are very limited, I'll put them in this message in unified diff format. I added in almost all places the remark // REITEK for us in order to easily find them.


--- src/NpapiCore/NpapiPlugin.cpp    Tue Jun 23 17:11:44 2015
+++ src/NpapiCore/NpapiPlugin.cpp    Mon Jun 08 12:53:27 2015
@@ -83,7 +83,9 @@
         }
     }
     pluginMain->setParams(paramList);
-    setReady();
+
+    // REITEK: This cannot work anymore since setParams works asynchronously
+    //setReady();
 }
 
 NPError NpapiPlugin::SetWindow(NPWindow* window)
--- src/PluginCore/PluginCore.cpp    Tue Jun 23 17:11:44 2015
+++ src/PluginCore/PluginCore.cpp    Mon Jun 08 12:57:55 2015
@@ -44,7 +44,8 @@
      Regular Class Stuff
 \***************************/
 
-PluginCore::PluginCore() : m_paramsSet(false), m_Window(NULL),
+// REITEK: Initialise m_isReady
+PluginCore::PluginCore() : m_paramsSet(false), m_isReady(false), m_Window(NULL),
     m_windowLessParam(boost::indeterminate), m_scriptingOnly(false)
 {
     FB::Log::initLogging();
@@ -79,6 +80,10 @@

 
                 dfd.done([=](FB::JSObjectPtr tmp) -> void {
                     m_params[key] = tmp;
+
+                    // REITEK: Call onload here !!!
+                    if (key == "onload")
+                        setReady();

                 });
 
                 FBLOG_TRACE("PluginCore", "Found <param> event handler: " << key);
@@ -114,6 +119,10 @@
 // to indicate that we're done.
 bool PluginCore::setReady()
 {
+    // REITEK: Check m_isReady and set it at the end
+    if (m_isReady)
+        return false;
+
     bool rval = false;
     FBLOG_TRACE("PluginCore", "Plugin Ready");
     try {
@@ -130,7 +139,10 @@
         // Usually this would be if it isn't a JSObjectPtr or the object can't be called
     }
     onPluginReady();
-    return rval;
+
+    m_isReady = true;
+
+    return rval;
 }
 
 bool PluginCore::isWindowless()
--- src/PluginCore/PluginCore.h    Tue Jun 23 17:11:44 2015
+++ src/PluginCore/PluginCore.h    Mon Jun 08 12:54:56 2015
@@ -355,7 +355,9 @@
         bool m_paramsSet;              
         /// Stores the list of params provided by the browser to setParams(); deprecated, use
         /// getParam insead
-        FB::VariantMap m_params;       
+        FB::VariantMap m_params;
+        // REITEK: Put this here in order to safely call setReady upon asynchronous call of lamba function within the setParams method
+        bool m_isReady;
     private:
         /// Don't use directly; use GetWindow()
         PluginWindow *m_Window;        


Best regards,
Fabrizio

Fabrizio Ammollo

unread,
Jun 29, 2015, 12:15:28 PM6/29/15
to firebre...@googlegroups.com
Hello,

I tried again using IE after the changes pushed by user wojwal and described as "Implementing missing Promise changes for ActiveX core" and this time what happens is a crash of Internet Explorer.

The debugger shows that the crash happens in file JSAPI_IDispathEx.h into method JSAPI_IDispatchEx<T,IDISP,piid>::InvokeEx

when entering into this if condition:

            if (wFlags & DISPATCH_METHOD && (api->HasMethod(wsName) || !id) ) {

and then calling

setPromise(api->Invoke(wsName, params), pvarRes);

The problem is that pvalRes is NULL and so the crash happens when this code is executed:

::VariantInit(result);

I don't know anything about the IE (ActiveX) programming model, I noticed that, when into the topmost method (apart from the topmost ones that is in "system binaries"), "this" pointer shows that m_readyState is READYSTATE_LOADING.
Does it mean that the crash was caused by trying to execute a Javascript method before full loading of the page?
I also noticed that (it seems to me) Javascript must now be accessed as in Chrome, using promises, not in the old way which is still supported using NPAPI. Am I correct?
 
Best regards,
Fabrizio

Richard Bateman

unread,
Jun 30, 2015, 7:23:52 PM6/30/15
to FireBreath Dev Group

Hey Fabrizio; 

I’m sorry I’ve been so unresponsive — I’ve been crazy busy.

This does sound like a lifecycle issue with something trying to be accessed before the page is loaded; it may take some doing to find a good solution for this.

As you have surmised, the intent of FireBreath 2.0 is to make everything consistent, so regardless of which browser you use everything is accessed (after the plugin is loaded) in the same way. Since we can’t make everything synchronous we make everything async and use promises.

Richard

Fabrizio Ammollo

unread,
Jul 11, 2015, 5:31:08 AM7/11/15
to firebre...@googlegroups.com
Hello Richard,

I imagined you were very busy while you were absent from both the group and the IRC channel.
FB2 on Chrome in our experience so far seems quite stable, on Firefox it seems there is only an issue with plugin destruction because hitting F5 it crashes, on IE instead there are the problems I told you last time.
Since your objective is to make the usage across different browsers consistent, I imagine in the not too distant future there will be changes to the NPAPI part in order to use promises there too, right?

Best regards
Fabrizio

Richard Bateman

unread,
Jul 11, 2015, 10:39:30 AM7/11/15
to FireBreath Dev Group

You're correct, I've been rather insanely busy lately as well as a bit burned out after months of constant work on FB2 =] It really needs someone to jump in and help document things.

FB2 NPAPI and ActiveX both already use Promises; as to the crash, is there any way you could provide me with a sample project to reproduce it easily? I've been having trouble finding motivation to get in there, but if you'll give me something that will get me right into the problem I'll try to help fix it.

Richard

Charles Burfoot

unread,
Sep 7, 2015, 7:31:37 PM9/7/15
to firebreath-dev
You indicated you wanted some help. We chatted on Friday. I have been reading through, building, learning promise and trying to find EchoTestPlugin.
I've gotten refactor from Git but I don't find EchoTestPlugin to build and document. 

Richard Bateman

unread,
Sep 8, 2015, 12:19:42 AM9/8/15
to FireBreath Dev Group

EchoTestPlugin is found under the examples/ directory


you'd build it on windows with:

prep2013.cmd examples\EchoTestPlugin et_build
cmake --build et_build

There are some problems with the project that will need to be tracked down.  I've been on vacation today, but should be online tomorrow.

Richard

On Sep 7, 2015, at 5:27 PM, Charles Burfoot <ch...@burfoots.com> wrote:

You indicated you wanted some help. We chatted on Friday. I have been reading through, building, learning promise and trying to find EchoTestPlugin.
I've gotten refactor from Git but I don't find EchoTestPlugin to build and document. 

Charles Burfoot

unread,
Sep 8, 2015, 11:05:41 PM9/8/15
to firebreath-dev
K! That builds. Running the project - Chrome - no workie - no debug break. IE kinda working - no debug break. FireFox - best working example it seems - no debug break.
Don't see any usage of WyrmHole. Is the async mechanism preventing the debug break?

I can't document much yet....

Adrian C

unread,
Sep 10, 2015, 3:09:15 AM9/10/15
to firebreath-dev
Hi Charles,

I'm also trying to jump in to help document. In another post here I made some comments about a few changes in the project to build the WiX installer with WiX 3.9. But after building the EchoTestPlugin I can't test it in any browser, seems to me that the generated test html page does not yet incorporate the promises and other changed. How did you make it work in Firefox? Maybe would you have the page you are using to test so we can progress this together?

-Adrian

Richard Bateman

unread,
Sep 10, 2015, 11:10:22 AM9/10/15
to FireBreath Dev Group

That is correct; the updates to support native messaging and promises have not yet been made to the test pages.

More information can be found in past messages, like this one: https://groups.google.com/forum/#!topic/firebreath-dev/FSeWz9yqW7k

Richard

Charles Burfoot

unread,
Sep 10, 2015, 8:10:02 PM9/10/15
to firebreath-dev
Cool indeed. After building don't forget to call regsvr32 npEchoTestPlugin.dll. then under the gen folder use the FBcontrol.html page with different browsers

Charles Burfoot

unread,
Sep 10, 2015, 8:12:20 PM9/10/15
to firebreath-dev
Will try that over the next couple of days! Thanks

Charles Burfoot

unread,
Sep 10, 2015, 11:57:02 PM9/10/15
to firebreath-dev
Base on the post I modified the FBControl.htm to have the following onload() {
        var callbackFn;
        function load()
        {
            callbackFn = "_fwcb_" + Math.floor(Math.random() * 100000000);
            /*
            alert("Load");
            addEvent(plugin(), 'test', function(){
                alert("Received a test event from the plugin.")
            });
            */
        window[callbackFn] = function(inp) {
            helper = inp.wyrmhole;
            setHelper(helper);
        };
        window.postMessage({firebreath: 'CompanyName', callback: callbackFn}, "*");
        }
       
       I commented out the HTML for the <object />
       I don't see any errors but no breakpoint fires from the callback either. I don't see a class or member to receive the 'data' and call the callback from ??
      The docs on window.postmessage() suggest we need and addeventlistener() but to ??
      I'm running on a leap of faith, but I seem to be landing with concrete shoes.

 
Reply all
Reply to author
Forward
0 new messages