Hello all,
Kirix is pleased to announce the availability of wxWebConnect 1.2 -- a new version of the popular library for wxWidgets that enables developers to quickly integrate advanced web browser capabilities.
It wraps up functionality exposed by the Mozilla Foundation's Gecko engine (XULRunner) into a set of user-friendly classes to: embed browser controls, search web content, print web pages, interact with the DOM, implement custom content handling for different MIME types, issue POST calls using the current browser state, etc. Notably, with this library you can also embed all of your favorite Firefox browser plug-ins into your application.
New features in this version include:
* support for newer versions of xulrunner (9.0.1)
* more DOM interfaces
* better support for bad certificates
* many bug and crash fixes
* now hosted on Github
With other libraries in the past, embedding a web browser control has proven a daunting task, often involving compiling seemingly countless sub-dependencies. We've gone out of our way to make sure that getting a browser control up and running in your application is as easy as possible.
The source code is hosted on Github at https://github.com/kirixresearch/wxwebconnect
More information can be found at the wxWebConnect project page (http://www.kirix.com/labs/wxwebconnect.html). A short demo video and some screenshots can be found here (http://www.kirix.com/labs/wxwebconnect/screenshots.html)
We've released the full source code under the wxWindows license, so please go ahead and use this library in your own applications freely.
Comments and criticisms are welcome.
All the best,
Benjamin I. Williams
Kirix Corporation (http://www.kirix.com)
Ben Williams
Kirix Support Team
Kirix Support Forums
wxWebConnect 1.2 Released
15 posts
• Page 1 of 1
wxWebConnect 1.2 Released
Ben Williams
Kirix Support Team
Kirix Support Team
-
Ben - Kirix Support Team
- Posts: 525
- Joined: Mon Dec 19, 2005 6:29 am
Re: wxWebConnect 1.2 Released
I've finally got around to starting looking at moving my changes over to this version. So far I've noticed at least the key up and down issue I mentioned with XULRunner 2 in viewtopic.php?f=25&t=921.
Running my tool to check interfaces with the wrong GUID came up with the following interfaces.
Some of them may be to do with my version or with bad merging of my version, but they seem to affect at least executing Javascript on the web control and my code to use a custom protocol handler:
When changing them over I discovered that the interface of nsIAppShell has completely changed, so for now I have had to just comment out the section of the code that used that. No idea if that has any negative effect.
There were also a few interfaces that seemed no longer to exist in XULRunner 9:
Don't know if they ran anything important in the wxWebConnect setup.
I will try to get it to a state where it is working and the code is able to be shared, but thought those findings were a good start.
Running my tool to check interfaces with the wrong GUID came up with the following interfaces.
Some of them may be to do with my version or with bad merging of my version, but they seem to affect at least executing Javascript on the web control and my code to use a custom protocol handler:
- nsITransfer
- nsIComponentManager
- nsIScriptSecurityManager
- nsICacheService
- nsIAppShell
- nsISHistory
- nsIPrincipal
- nsIURI
When changing them over I discovered that the interface of nsIAppShell has completely changed, so for now I have had to just comment out the section of the code that used that. No idea if that has any negative effect.
There were also a few interfaces that seemed no longer to exist in XULRunner 9:
- nsIDOM3Document
- nsIBadCertListener
- nsIDOM3Node
Don't know if they ran anything important in the wxWebConnect setup.
I will try to get it to a state where it is working and the code is able to be shared, but thought those findings were a good start.
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
Wow, thanks for the useful information, Jon. Coincidentally we're about to do a big upgrade to the latest XULRunner, just to be up-to-date. I'll also review all of the interfaces you mentioned and see if we can't get Javascript execution working properly.
I'll be merging my work into this tree here: https://github.com/kirixresearch/wxwebconnect and will let you know as soon as I've done that. I've added you as a collaborator to that tree.
All the best,
Ben
I'll be merging my work into this tree here: https://github.com/kirixresearch/wxwebconnect and will let you know as soon as I've done that. I've added you as a collaborator to that tree.
All the best,
Ben
Ben Williams
Kirix Support Team
Kirix Support Team
-
Ben - Kirix Support Team
- Posts: 525
- Joined: Mon Dec 19, 2005 6:29 am
Re: wxWebConnect 1.2 Released
Thanks for the feedback, Ben.
The script I referred to that checks for GUID differences can be found at https://github.com/jonmmorgan/wxwebconn ... erences.py. It was just quickly hacked together when I was working on XR 2.0 years ago, but still seems useful. Written in Python, my favourite scripting language. [note that it only checks IDL files like nsall.idl - it won't tell you to update nsIScriptContext and the other ones in webconnect.cpp].
I'm actually baffled by the Javascript errors. I have gone and changed nsIScriptContext and similar files, and it is now executing scripts fine but returning random strings instead of the result of the function. As far as I can tell from my logs of the XR 2 changes, I've made exactly equivalent changes for XR 9, but it doesn't seem to have fixed the problem. I'll keep going and see if I get anywhere, but yes, an update to latest XR would be good to see.
The script I referred to that checks for GUID differences can be found at https://github.com/jonmmorgan/wxwebconn ... erences.py. It was just quickly hacked together when I was working on XR 2.0 years ago, but still seems useful. Written in Python, my favourite scripting language. [note that it only checks IDL files like nsall.idl - it won't tell you to update nsIScriptContext and the other ones in webconnect.cpp].
I'm actually baffled by the Javascript errors. I have gone and changed nsIScriptContext and similar files, and it is now executing scripts fine but returning random strings instead of the result of the function. As far as I can tell from my logs of the XR 2 changes, I've made exactly equivalent changes for XR 9, but it doesn't seem to have fixed the problem. I'll keep going and see if I get anywhere, but yes, an update to latest XR would be good to see.
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
I have managed to make my version all work (well, as well as XR2, anyway). The build issues I was having were down to still using some of the XR 1.9.2 headers. I've pushed the changes to a separate branch on my repository at https://github.com/jonmmorgan/wxwebconn ... ulrunner9/. We should look at merging at least some of the changes into your main repository later.
You may be particularly interested in https://github.com/jonmmorgan/wxwebconn ... 046e5f4b30, which aims to bring all the interfaces I mentioned up to XR 9 level.
I have removed nsIAppShell since it was only used in detecting whether XR was 1.8 or not. Do you still use XR 1.8?
It looks like nsIDOM3Document might be able to be just replaced with nsIDOMDocument. No guarantees, though. It's only used once - is that code important?
As far as the up and down keys go, they still don't work. It might be the way I use the control, but it seems that it isn't grabbing focus, and so up and down are actually jumping to the next/previous control in the wxWidgets tab order. I won't be able to move to a new version until I figure that out. Do you see any behaviour like that?
You may be particularly interested in https://github.com/jonmmorgan/wxwebconn ... 046e5f4b30, which aims to bring all the interfaces I mentioned up to XR 9 level.
I have removed nsIAppShell since it was only used in detecting whether XR was 1.8 or not. Do you still use XR 1.8?
It looks like nsIDOM3Document might be able to be just replaced with nsIDOMDocument. No guarantees, though. It's only used once - is that code important?
As far as the up and down keys go, they still don't work. It might be the way I use the control, but it seems that it isn't grabbing focus, and so up and down are actually jumping to the next/previous control in the wxWidgets tab order. I won't be able to move to a new version until I figure that out. Do you see any behaviour like that?
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
Hi Jon,
Thanks for all your efforts. I really appreciate it.
We have been on 9.0.1 and have been for a while. I'm quite interested and need to get this project up to XR 25 compatibility, so after you complete any merges you need/want, I'd get started on that work.
Yeah, we can totally axe any XR 1.8 compatibility as that was a temporary measure. We haven't used 1.8 in a long time.
So, the next step is to merge your work into our tree. Is this something you have time to do? After that job is done, I'll get cracking on XR 25 compatibility. As with most XR version upgrades, this will almost certainly preclude any compatibility with XR 9. Is that ok with you?
Ben
Thanks for all your efforts. I really appreciate it.
We have been on 9.0.1 and have been for a while. I'm quite interested and need to get this project up to XR 25 compatibility, so after you complete any merges you need/want, I'd get started on that work.
Yeah, we can totally axe any XR 1.8 compatibility as that was a temporary measure. We haven't used 1.8 in a long time.
So, the next step is to merge your work into our tree. Is this something you have time to do? After that job is done, I'll get cracking on XR 25 compatibility. As with most XR version upgrades, this will almost certainly preclude any compatibility with XR 9. Is that ok with you?
Ben
Ben Williams
Kirix Support Team
Kirix Support Team
-
Ben - Kirix Support Team
- Posts: 525
- Joined: Mon Dec 19, 2005 6:29 am
Re: wxWebConnect 1.2 Released
Hi Ben,
Thanks for that. I held off responding hoping to merge my changes, but haven't actually had time to. Hopefully I will get to it in the next week.
As far as XR 9 compatibility goes, I'm certainly not tied to it. It was just the latest target available to aim for.
When working on XR 2 I tried to have a system of conditional compilation in place, but it might be more trouble than it is worth given that you would still need to rebuild it for whichever version you wanted anyway.
Jon
Thanks for that. I held off responding hoping to merge my changes, but haven't actually had time to. Hopefully I will get to it in the next week.
As far as XR 9 compatibility goes, I'm certainly not tied to it. It was just the latest target available to aim for.
When working on XR 2 I tried to have a system of conditional compilation in place, but it might be more trouble than it is worth given that you would still need to rebuild it for whichever version you wanted anyway.
Jon
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
I've pushed most of my changes into the Kirix branch. That included updating the interfaces to XULRunner 9, removing the interfaces I mentioned above that no longer exist, and adding a number of methods to the webcontrol API.
The one change that I haven't pushed in was the change to support executing a Javascript script and returning the result as a string. The change can be viewed at https://github.com/jonmmorgan/wxwebconn ... 06c762c837.
To do that, I made it rely on including jsapi.h from the XULRunner SDK at build time (there are no additional dependencies at runtime). I'm not sure whether that's a dependency you want in the code, though I found that the definition of jsval was too complex to trace through the many different headers and that just including the headers directly worked fine. What do you think?
Next I want to look at why up and down arrows don't work for me in the web control (and haven't since XR2). It looks like the web control isn't properly getting focus, and so arrows and tabs both cycle to the next/previous control in the wxWidgets tab order.
The one change that I haven't pushed in was the change to support executing a Javascript script and returning the result as a string. The change can be viewed at https://github.com/jonmmorgan/wxwebconn ... 06c762c837.
To do that, I made it rely on including jsapi.h from the XULRunner SDK at build time (there are no additional dependencies at runtime). I'm not sure whether that's a dependency you want in the code, though I found that the definition of jsval was too complex to trace through the many different headers and that just including the headers directly worked fine. What do you think?
Next I want to look at why up and down arrows don't work for me in the web control (and haven't since XR2). It looks like the web control isn't properly getting focus, and so arrows and tabs both cycle to the next/previous control in the wxWidgets tab order.
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
Perfect. Thanks for the code updates! The next step for me is to sync our internal scc tree with the github tree and then chip away at XR 25 compatibility.
I'm pretty sure we don't want to add a dependency to the sdk's jsapi.h file, or any other XULRunner SDK code. I realize the manual labor involved in doing it the way we've done up until now, but it makes it a lot easier for others using the library just do download, compile and go.
I'm wondering if there's some way we can just declare the functions we need, but I haven't yet reviewed what exactly is necessary, so I may be speaking out of turn.
In any case, huge thanks.
Ben
I'm pretty sure we don't want to add a dependency to the sdk's jsapi.h file, or any other XULRunner SDK code. I realize the manual labor involved in doing it the way we've done up until now, but it makes it a lot easier for others using the library just do download, compile and go.
I'm wondering if there's some way we can just declare the functions we need, but I haven't yet reviewed what exactly is necessary, so I may be speaking out of turn.
In any case, huge thanks.
Ben
Ben Williams
Kirix Support Team
Kirix Support Team
-
Ben - Kirix Support Team
- Posts: 525
- Joined: Mon Dec 19, 2005 6:29 am
Re: wxWebConnect 1.2 Released
Hi Ben,
I understand the concern about build-time dependencies, and I don't really like them either.
I removed other build-time dependencies. The only reason I left that one in was because the header depended on way too many other headers and had too many conditionals and I just couldn't understand what was the real structure. I'm sure it could be done, but I wasn't feeling like going to the effort when I had a working system.
Because it's a struct and is being passed by value, not by reference, it really has to be the right length otherwise segfaults happen (that was one of the things that held me up moving to XR 9 - accidentally including the wrong headers). Since to us it's just an opaque data structure, I did wonder about just putting in a dummy struct something like:
However, I suspected that even if that managed to work it could have more issues being cross-platform. I think you have used dummies like that for some of the Mozilla data structures?
I understand the concern about build-time dependencies, and I don't really like them either.
I removed other build-time dependencies. The only reason I left that one in was because the header depended on way too many other headers and had too many conditionals and I just couldn't understand what was the real structure. I'm sure it could be done, but I wasn't feeling like going to the effort when I had a working system.
Because it's a struct and is being passed by value, not by reference, it really has to be the right length otherwise segfaults happen (that was one of the things that held me up moving to XR 9 - accidentally including the wrong headers). Since to us it's just an opaque data structure, I did wonder about just putting in a dummy struct something like:
- Code: Select all
typedef struct _jsval {
char dummy[28]; // For 28, substitute the actual sizeof(jsval) for the platform and XULRunner version you are interested in.
}jsval;
However, I suspected that even if that managed to work it could have more issues being cross-platform. I think you have used dummies like that for some of the Mozilla data structures?
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
That solution is very agreeable to me, though I'd agree, the target size would have to be exactly the same to avoid stack corruption if it's passed by value. We'd have to check this on all target platforms.
The alternative is looking at the jsval structure and choosing dummy fields that have equal sizes. Pointers would be easily replaced by void*, etc. I'm saying this without having looked at the structure, so I may be talking out of place. The real challenge here would be embedded structures, if there are any. If jsval is just a list of pointers and integers and other simple types, I don't see why we couldn't come up with an equivalent structure with placeholder members.
The alternative is looking at the jsval structure and choosing dummy fields that have equal sizes. Pointers would be easily replaced by void*, etc. I'm saying this without having looked at the structure, so I may be talking out of place. The real challenge here would be embedded structures, if there are any. If jsval is just a list of pointers and integers and other simple types, I don't see why we couldn't come up with an equivalent structure with placeholder members.
Ben Williams
Kirix Support Team
Kirix Support Team
-
Ben - Kirix Support Team
- Posts: 525
- Joined: Mon Dec 19, 2005 6:29 am
Re: wxWebConnect 1.2 Released
Looks like there's a nice comment to the effect that jsval should always be 64-bit. So for the moment I'm trying:
We'll see how that goes.
I've started looking at XULRunner 25. I think I've updated all the interfaces, but it's in a bit of a mess because they've nicely gone adding namespaces and managing the lifespan of all the Javascript variables, so you get nice interfaces like:
Note that the handle is passed by value, and the CompileOptions have to be constructed locally and then passed by reference. I think both of these definitions would need to be copied from the Mozilla source, and who knows what else would have to come with it? I haven't even got the code to compile yet.
I'm actually wondering whether I can get away with using:
I could load it from the JS DLL in the same way as I load the string manipulation functions.
Anyway, more when I have more to hand.
- Code: Select all
typedef unsigned long long jsval;
We'll see how that goes.
I've started looking at XULRunner 25. I think I've updated all the interfaces, but it's in a bit of a mess because they've nicely gone adding namespaces and managing the lifespan of all the Javascript variables, so you get nice interfaces like:
- Code: Select all
virtual nsresult EvaluateString(const nsAString& aScript,
JS::Handle<JSObject*> aScopeObject,
JS::CompileOptions& aOptions,
bool aCoerceToString,
jsval* aRetValue) = 0;
Note that the handle is passed by value, and the CompileOptions have to be constructed locally and then passed by reference. I think both of these definitions would need to be copied from the Mozilla source, and who knows what else would have to come with it? I haven't even got the code to compile yet.
I'm actually wondering whether I can get away with using:
- Code: Select all
extern JS_PUBLIC_API(JSBool)
JS_EvaluateScript(JSContext *cx, JSObject *obj,
const char *bytes, unsigned length,
const char *filename, unsigned lineno,
jsval *rval);
I could load it from the JS DLL in the same way as I load the string manipulation functions.
Anyway, more when I have more to hand.
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
I tried the new jsval typedef with XULRunner 9 and it seemed to work. So I've pushed the script execution changes into the Kirix repository.
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
Just a status update: Turns out XULRunner 25 has changed a lot. Right now, I've got something that compiles and seems to do the right thing, except for the minor fact that it crashes the first time you click on the web control after loading a URL (loading the URL only worked because I disabled a lot of the standard adding of event listeners).
Some things that have needed changing (and maybe haven't been changed very well by me):
1. The JS API relies much more on namespaces and even on safe C++ pointers than it used to. Not entirely comfortable duplicating these (and, in fact, at this stage I haven't).
2. The DOM API has changed to distinguish between elements and attributes. This breaks a lot of wx DOM code. I have put in some workarounds.
3. The mozjs DLL is now compiled with C++ linkage (and name mangling) rather than being a C API. This kills the idea of easily loading the functions needed from mozjs.dll and just working directly with them as I do now.
4. nsILocalFile has been deprecated. Most of the things we do with nsILocalFile now expect and return an nsIFile instance instead.
There were probably other things I glossed over. At the moment I'm looking at starting with an earlier version of XULRunner with fewer problems and working up.
Some things that have needed changing (and maybe haven't been changed very well by me):
1. The JS API relies much more on namespaces and even on safe C++ pointers than it used to. Not entirely comfortable duplicating these (and, in fact, at this stage I haven't).
2. The DOM API has changed to distinguish between elements and attributes. This breaks a lot of wx DOM code. I have put in some workarounds.
3. The mozjs DLL is now compiled with C++ linkage (and name mangling) rather than being a C API. This kills the idea of easily loading the functions needed from mozjs.dll and just working directly with them as I do now.
4. nsILocalFile has been deprecated. Most of the things we do with nsILocalFile now expect and return an nsIFile instance instead.
There were probably other things I glossed over. At the moment I'm looking at starting with an earlier version of XULRunner with fewer problems and working up.
- jonmmorgan
- Registered User
- Posts: 94
- Joined: Fri May 14, 2010 9:48 am
Re: wxWebConnect 1.2 Released
Great! Scaling back the version jump sounds like a prudent approach. I expect more breaking changes because of their intention to go multi-process.
Ben Williams
Kirix Support Team
Kirix Support Team
-
Ben - Kirix Support Team
- Posts: 525
- Joined: Mon Dec 19, 2005 6:29 am
15 posts
· Page 1 of 1
Return to wxWebConnect Questions, Thoughts & Feedback