Rendering HTML with wxWebConnect

[jonmmorgan]

As far as I can tell there isn't any easy way to render raw HTML with wxWebConnect (while being very easy to open a URI). If I've missed something, feel free to comment.

I can think of a few workarounds, such as:
* Write to a file and load that file with a file:/// URI.
* Use a data URI.
* Create and execute a Javascript script that sets the document body's innerHTML?

All of these feel like workarounds, and are probably slower and/or less reliable than a "real" solution.

I propose to implement nsIProtocolHandler like support <https://developer-stage.mozilla.org/en/nsIProtocolHandler> using nsIProtocolHandler to do it properly. Does this seem reasonable?

[Ben]

Hi there,

Wow, cool idea with the nsIProtocolHandler. We of course toyed with the idea of writing out a temporary file, but there was no way to reliably do it and manage the lifetime of the temporary file (which could contain sensitive information), so we just decided to punt and forward this functionality to the user of the library.

We had do this ourselves. We ended up storing all of our content in a .jar file and using ns's special jar urls to view the data.

I'd be curious if you'd like a shot implementing this.

Best,
Ben

[jonmmorgan]

I knew about nsIProtocolHandler because I've used it in a XULRunner application before. I'll have a look at adding support for it, and post back here if I get somewhere.

[jonmmorgan]

I have (hopefully) written most of the forwarding code for nsIProtocolHandler. However, I can't actually test it because it won't work without registering protocols properly, which requires a unique GUID and contract ID for each protocol. This last makes it a little inconvenient to make it work. I can see at least several ways forward:
1. Require every wxProtocolHandler to have a GUID and to know its GUID and pass it in when registering the protocol handler.
2. Make up a GUID when registering a new protocol handler. Would need to link to some UUID type library.
3. Have a static list of GUIDs, give them out as you register a new protocol handler.
4. Just register one protocol, webconnect, and allow apps to use the host to differentiate themselves (e.g. if I register protocol "app", then I have to use the URI webconnect://app/<my custom path>, and <my custom path> would be passed to the protocol handler when the content for a URL is being got).

Thoughts?

Of these, I don't like (1) because it is unnecessarily leaking Mozilla concepts into the wx API (and I'm working with wxPython and don't want to have to wrap the C++ GUID array structures for XPCOM if I don't have to). It does do the correct Mozilla thing, though. I don't like (4) because it is also probably unnecessarily leaking implementation details, and it means that every URL you build has to be of form webconnect://app/. That leaves (2) and (3). Of these, (2) is probably the most correct approach. There is a UUID generator, nsIUUIDGenerator, so I will try using that.

Of course, after this is implemented you could add a special protocol handler for webconnect, of the form webconnect://<unique browser id>/content, then maintain a map between browser IDs and their contents to implement a SetPageSource() type method which sets the content in this map, then opens the WebConnect content URL. I'd probably prefer to implement my own protocol handler if I could make URLs that made sense.

I'll keep on looking into this.

[Ben]

Very cool stuff.

First, I'd like to say, add this problem to the long list of headaches I've encountered since starting this library a few years back. It seems to never end. I'm glad we have some help this time around.

Optimally, we 'd be able to use some kind of UUID generator, but I even think your #3 proposal is easily workable (having a static list of GUIDs).

Best,
Ben

[jerry_mouse]

Ooh, It's quite simple to load raw HTML string using the data URI workaround.
I currently use this code to load HTML string into wxWebControl and it works properly.

But It's great if we have a protocol handler so we can load data from anywhere (e.g. from a database or zip file) seamlessly.

Code: Select all

bool wxWebControl::OpenHTML( const wxString& strBaseURI, const wxString& strHTML )
{
   nsresult rv;
   m_content_loaded = false;

   ns_smartptr<nsIStringInputStream> inputStream(nsCreateInstance("@mozilla.org/io/string-input-stream;1"));
   if (!inputStream.p)
      return false;
   // convert our string to stream
   std::string strutf8data = strHTML.ToUTF8();
   inputStream->SetData( strutf8data.c_str(), strutf8data.length() );
   // get document shell
   ns_smartptr<nsIDocShell> docShell(nsRequestInterface(m_ptrs->m_web_browser));
   if (!docShell.p)
      return false;
   ns_smartptr<nsIURI> uri;
   if (!strBaseURI.IsEmpty())
      uri = nsNewURI(strBaseURI);
   // finally, load the stream we made!
   rv = docShell->LoadStream( inputStream, uri.p, nsDependentCString("text/html"), nsDependentCString("UTF-8"), NULL);

   if (NS_FAILED(rv))
      return false;
   return true;
}


[jonmmorgan]

The code you give looks good (much better than having a special internal webconnect protocol). I've worked with XULRunner a bit before, but I've never used it with C++, and am obviously nowhere near navigating the maze of interfaces available.

I'll continue with the protocol handler because I also have a feeling it will be useful for loading additional content in Javascript with HTTP requests or similar as I go (you could of course generate a bunch of HTML, then execute some Javascript to put it in a parent element and add that parent element to the document body, but I'm not sure that I like that solution, and protocol handlers decouple things nicely).

[jonmmorgan]

I have added support for the protocol handler which works fairly well with the basic testing I've given it. I attach the relevant files to this post. It's possible that I will change the implementation a bit, but the interface is probably relatively stable (though now it exposes just about all of the methods on nsIProtocolHandler, and I'm not sure they all need to be exposed - particularly ones like managing ports, having a default port, and so on).

The two sample protocol handlers I have used for basic testing are:

Code: Select all

wxString TestProtocolHandler::GetContent(const wxString &url)   {
   return wxT("The URL that was passed was: ") + url;
}

wxString TestProtocolHandler::GetContentType(const wxString &url)   {
   return wxT("text/plain");
}


wxString TestHTMLProtocolHandler::GetContent(const wxString &url)   {
   return wxT("<html><head><title>Test title</title></head><body><p>The URL that was passed was: <b>") + url + wxT("</b>.</p></body></html>");
}

// Add to OnInit after initialising the engine:
      RegisterProtocol(wxT("test"), new TestProtocolHandler());
      RegisterProtocol(wxT("testhtml"), new TestHTMLProtocolHandler());


I've been trying to get it working with Python, but it keeps on crashing (and it seems to be a problem with SWIG rather than with wxWebConnect or the protocol handler).

The interfaces I added to nsall.idl were nsIInputStreamChannel, nsIMutable, nsIStandardURL, nsIProtocolHandler, nsIInputStream and nsIUUIDGenerator (see attached files).

This works with XULRunner 1.9.1 and 1.9.2, but does not work with the XULRunner 1.8.1.3 which comes with the default distribution. I do not have a full copy of XULRunner 1.8.1 (particularly the IDL files), and am not sure whether you can get one, so I am working with newer IDL files, and it is possible that one of the interfaces I was using is different (I think it was crashing when calling nsIStandardURL::Init). I will post more about version compatibility in another post.

[jonmmorgan]

Just for interest, the code posted by jerry_mouse does not work with XULRunner 1.9.2, as that way of getting the doc shell is apparently no longer supported. It probably works for 1.9.1 and down, but I haven't bothered testing it.

[jonmmorgan]

Hope I didn't sound too harsh in the previous post. It wasn't my intention.

I have another implementation which uses the frozen API nsIWebBrowserStream (though I don't know which release of XULRunner it was introduced in - it works fine with XR 1.9.2). You will note that I've added the contentType as a third parameter (defaulting to text/html), since I think it makes sense and I definitely want to be able to use plain text as well as HTML. As with the protocol handler, it's probably not yet guaranteed to work properly with Unicode - I haven't tried to set the content type for the web control to UTF-8.

Code: Select all

    // In the class declaration:
    bool SetContent(const wxString& strBaseURI, const wxString& strContent, const wxString& strContentType = wxT("text/html"));


bool wxWebControl::SetContent(const wxString& strBaseURI, const wxString& strContent, const wxString& strContentType)
{
    nsresult rv;
    m_content_loaded = false;

    ns_smartptr<nsIURI> uri;
    if (!strBaseURI.IsEmpty())
        uri = nsNewURI(strBaseURI);

    nsCString nsContentType;
    wx2ns(strContentType, nsContentType);

    std::string strutf8data = strContent.ToUTF8();

    ns_smartptr<nsIWebBrowserStream> browserStream(m_ptrs->m_web_browser);
    if (!browserStream.p)   {
        return false;
    }

    browserStream->OpenStream(uri, nsContentType);
    browserStream->AppendToStream((const PRUint8*)strutf8data.c_str(), strutf8data.length());
    browserStream->CloseStream();

    return true;
}


[jerry_mouse]

Hi John,
Thanks for the protocol handlers code.

The code that I've posted to load HTML DOES work well with XR 1.9.2, and we are using it in our project (http://www.atomisystems.com/activepresenter) to render and edit html in the balloons.
However, your code looks like a neater way.
Just one notice: You convert the input HTML string to UTF-8 but don't specify that elsewhere to let XR to know about that so I assume it might not work correctly with international languages.
This is just my guest cause I didn't tested yet.

[jonmmorgan]

I'm sorry if I misrepresented the situation with your solution. It would certainly surprise me if Mozilla did break that method of getting the doc shell. However, here is what I have done:
1. Checked the version of XULRunner. xulrunner.exe reports XULRunner 1.9.2.
2. Checked the version of nsIDocShell in nsall.idl was right. It came from the XULRunner 1.9.2 SDK. The UUID is 8ADFB831-1053-4A19-884D-BCDAD7277B4B. The UUID in nsall.h is the same.
3. In the debugger, I can verify that the place where it fails is the cast to nsIDocShell.

I have also had clear reports from another program I am involved with (using Gtk-mozembed) that a certain method just stopped working when it was run with XULRunner 1.9.2. That method also had a cast of web browser to nsIDocShell, so I assumed it was the same cause, and that it was no longer possible to cast to nsIDocShell in that way. I'm intrigued that you have it working. Any guesses as to what I might be doing wrong?

My solution does not specify the charsets, and I haven't found a way to specify the charsets. As you say, that will probably be a problem. After a little searching the web, it seems you might be able to give it content type "text/html;charset=utf-8". The protocol handler is equally probably not ready for Unicode (I should use the UTF-8 encoding method with std::string that you used...). I do need to support international characters, so I will probably fix these things when I actually get a chance to use them in my program.

[jerry_mouse]

I can verify that the place where it fails is the cast to nsIDocShell.

That is in fact a QI, not a cast.
I doubt that there might be something wrong elsewhere with the IDL files.
From Moz documentation:

2.14 Interface: nsIWebBrowser
Properties for the client to register listeners and to obtain the nsIDocShell of the root object.

So that is the standard way to obtain the root nsIDocShell.

Regarding the utf-8, if you always have control on the input data (e.g. you can convert it before feeding to XR) then it should be safe to always use utf-8 as default, as it supports all international languages as far as I know.
This is the simplest way to handle internationalization. We use this in our application that has support for English, Spanish, Japanese, Vietnamese and so far so good.

About your protocol handler:
At line 196 (protocolhandler.cpp)

Code: Select all

// XXX: Memory leak?
    wxString *contractID = new wxString(wxT(NS_NETWORK_PROTOCOL_CONTRACTID_PREFIX) + scheme);
    wxString *className = new wxString(wxT("WebConnect Protocol - ") + scheme);

I don't know why you need to use wxString pointer (wxString *)?
The nsIComponentRegistrar::RegisterFactory method requires const char* for both class name and contract id so you can create the string on the stack and pass the returned value of ToAscii() to it.

Code: Select all

wxString contractID = wxString(wxT(NS_NETWORK_PROTOCOL_CONTRACTID_PREFIX) + scheme);
    wxString className = wxString(wxT("WebConnect Protocol - ") + scheme);
.....
    res = comp_reg->RegisterFactory(*protocol_cid,
                                    className.ToAscii(),
                                    contractID.ToAscii(),
                                    protocol_handler_factory);



Regards,

[MrD]

Where is the type nsIWebBrowserStream coming from?

I tried this on the standard wxWebConnect source but that type didn't exist, so I downloaded the code you provided in an earlier post but that type doesn't exist in there either. I assume it is a type exported from the XulRunner XPCOM, however it doesn't seem to exist in nsall.h.

[jonmmorgan]

nsIWebBrowserStream does indeed come from XULRunner - I pinched its IDL definition from the XULRunner SDK and then added it to nsall.idl and regenerated nsall.h. However, if you want a copy of the source code with that change applied (and also others that vary from more to less dubious) try https://github.com/jonmmorgan/wxwebconnect/. You could at least get the nsall.idl and nsall.h from there.

[MrD]

I've finally gotten around to testing this out now, however I've noticed that while setting HTML from memory works fine, it doesn't then seem to load in any external CSS files referenced by that HTML. Is this a known issue? (I would assume I would also have to set the CSS into the browser stream for it to work?)

[jonmmorgan]

It does indeed seem to ignore the CSS link. In my testing it does the same if I encode the string with the equivalent "data:" URI. However, I think it is that way for security: it is doing some kind of origin checking and disallowing access to the CSS file in consequence. If I use "http://www.kirix.com/fileadmin/css/content.css" as the CSS HREF (for example), it works. Here are the results of my testing (in Python syntax, as I'm working with Python):

Test files:

test1.css

Code: Select all

h1 {
   color: green;
}


test1.html

Code: Select all

<html><head><link rel="stylesheet" href="file://d:/devel/webconnect_testapp/test1.css" type="text/css"></link></head><body><h1>Test</h1></body></html>


When I run:

Code: Select all

obj.OpenURI('file://d:/devel/webconnect_testapp/test1.html')


the heading is green.

When I run:

Code: Select all

obj.SetContent('http://www.test.com', '<html><head><link rel="stylesheet" href="file://d:/devel/webconnect_testapp/test1.css" type="text/css"></link></head><body><h1>Test</h1></body></html>')


the heading is black.

When I run:

Code: Select all

obj.SetContent('file://www.test.com', '<html><head><link rel="stylesheet" href="file://d:/devel/webconnect_testapp/test1.css" type="text/css"></link></head><body><h1>Test</h1></body></html>')


the heading is green again (the CSS is being applied).

The only important difference between these two is that one is trying to load CSS from the same protocol (file:) and works. The other is trying to load from a different protocol (http:) and is blocked by security.

[MrD]

Thanks.

Setting the base_uri to "file://" when setting the page has fixed the CSS loading issue (since the CSS is also loaded using file://)

[evendine]

Hi,

I added the OpenHTML function listed above to webcontrol.cpp / .h and am getting nsIDocShell related errors due to it being undeclared. I can't find the needed header file in my standard v1.1 wxWebConnect source code package. I googled it and understand that nsIDocShell.h can be generated from nsIDocShell.idl, but I am unsure which version I should be using. Any advice appreciated!

[jonmmorgan]

What is necessary is to:
1. Add the nsIDocShell interface into the nsall.idl file (and possibly interfaces that it depends on - can't remember).
2. Recompile nsall.h with "xpidl -m header nsall.idl" (using the 1.8.x version of xpidl).
3. Add the method mentioned here.

The changes I made to incorporate this change can be found at https://github.com/jonmmorgan/wxwebconn ... 95fa00d055.

However, it is worth noting that I could not make this method work with XR 1.9.2, and fell back to using the nsIWebBrowser method I have detailed. Ultimately I ended up using a custom protocol handler, also described here.

[evendine]

I followed the custom protocol handler approach with some success - now have a browser displaying the test html above from memory with css applied :0)

Any thoughts on 'inlining' the css file reference? Tried embedding the css file content in place of its href, but no go.

I'm looking into a 'webserver-less' arrangement feeding data from a db locally. Is it right to assume the custom protocol hander can handle anything supported by XULRunner with the appropriate mime types set via strContentType?

PS: @Jon: It seems the problem you describe here http://stackoverflow.com/questions/4347000/linux-dynamic-link-error-with-wxwebconnect may relate to missing wxLib refs. Although webconnect will compile and produce the lib using your supplied project file, when you try to reference functions within the webconnect.lib through testapp, (in VS/C++) you get function implementation missing type link errors.

Checking the backward refs, it seems webconnect needs the following wxLibs:
wxbase<v>.lib, wxmsw<v>_core.lib, wxmsw<v>_aui.lib, wxmsw<v>_xrc.lib, wxmsw<v>_adv.lib, wxmsw<v>_html.lib, wxbase<v>_xml.lib, wxexpat<v>.lib

[jonmmorgan]

By "inlining the CSS file contents" do you mean wrapping it in a <style> tag?
e.g.

Code: Select all

<html>
<head>
<style>
// Insert CSS here.
</style>
</head>
</html>


If so, that should work. If not, how are you doing it?

I think the protocol handler can handle any content type. I use it for HTML and CSS at the moment, and it seems to work fine.

As for the error described on StackOverflow, I fixed it after a few days. I think from memory the problem was something like I was taking too many shortcuts, which resulted in building in one location, and then installing from a different location, which meant that the old version with the error kept on being installed no matter how I reconfigured it. Reconfiguring that fixed the problem. Thanks for the thought, anyway!

[evendine]

That solved the css problem - thanks Jon :0)

I'm currently trying to use the custom protocol handler to display a flash file which is in a string in memory (rather than in a file, or on the web).

I can display a web based test flash file whose URL is embedded in a piece of html without problems, but am not quite sure about the correct approach to doing this for a string in memory. Passing SetContent(URI, Content, ContentType) the flash file contents and setting ContentType to "application/x-shockwave-flash" produces a blank browser form. Not sure how to configure the URI in such circumstances (have tried 'data://' and 'file://' formats with a dummy URL).

Any advice much appreciated! :0)

[jonmmorgan]

I don't really know. I suppose that you have access to a Flash plugin from the fact that it works if it is linking to a file.

It might be worth trying to embed the Flash player as an object in an HTML document rather than showing the Flash content directly (assuming that is not what you are already doing). I don't know whether that would have any more success.

Another possibility would be to just write the Flash content out to a file and then display that. That feels horrible, though.

[evendine]

Wrapping file-loads with html <object> tags does provide an interim solution, but (of course) needs an external file to work. My application has a (localhost) database of mixed type media files (swf, pdf, jpg, etc) stored as binaries and I need to avoid exposing the content files directly to users. The intention is to use the browser as a multimedia display console.

What I'd imagined was that the file contents could be passed to SetContent along the lines of:

Code: Select all

m_browser->SetContent("file:", TheFileContent, "application/x-shockwave-flash");

(setting the mime-type according to the original file type for each page change)

Reading back through the thread, I think it's right to say you've implemented handlers for "text/plain" and "text/html", which both seem to work in the way suggested above. Is a custom handler for each mime-type needed, which uses the passed in content string, rather than doing the file load in the handler?

So for say "image/jpeg", the content string would simply be the contents of the .jpg file (rather than a file path) and the handler would implement the default processing for "image/jpeg"...

[jonmmorgan]

When I used SetContent(), I found that it worked best when using a completely different protocol handler (e.g. the one that I used was test:, which I had just created to be a dummy protocol handler). I think that was because sometimes (not always) I found that Firefox would "steal" references to protocol handlers it was using (i.e. it would try to load http://www.test5.com/test itself). I didn't try SetContent with anything other than HTML content type, I don't think. Also, it might work better if it has a valid URL (e.g. file:///myrandomfile.jpg). I don't know. Now, instead of using SetContent(), we just have a global dictionary mapping content to a unique counter URL, then make the protocol handler look up the content in the dictionary and return it from GetContent(). (watch out for thread safety if you try this - we use the Python bindings, and so the GIL saves us from having to worry about this).

Using a custom protocol handler should hopefully work, just by overriding the GetContentType() method on the protocol handler as well as the GetContent(), but I haven't tried it with Flash. As for using multiple content types from the same protocol handler, we use CSS and HTML from the same protocol handler and it works fine (though equally you could have different protocol handlers for different content types if you wanted to - depending on how you structure your database it might make things easier).