Last week I took the plunge and tried to get HTML mail working.
As an early internet adaptor and ex Pine user, I still have mixed feelings about HTML mail, but it’s just so much eaiser to read, esp. with newsletters, that I cannot deny its usefulness.
Coming back to local mail with Haiku - getting more everyday capable every day… - I missed the nice renderin in GMail, so I set out to find a lightweight, easy to port HTML rendering library without dragging in webkit or other high profile browser engines.
I quickly found out there was an older and incomplete libhtml port by @adamfowleruk so I forked it and made it consume my latest port of liblitehtml 0.9.
I cleaned up the CMake config and made it behave properly under Haiku, added native support for libnet2 and using the new but still private BNetwork API.
It looks already quite nice, consuming local and remote images, loading style sheets and all.
However, coming to the point, I get this strange heap memory corruption with remote requests, when the local (!) BHttpRequest object is destroyed at the end of the scope:
This seems to be a race condition but I’m using the synchronous API so the method shouldn’t exit before the object is destroyed…
Yesterday I had this working with all web sites I tested, but today after changing some logic it always crashes on external sites (only then the HttpRequest is used, obviously).
Any idea what I’m doing wrong here?
You can find the code in question here:
Nice job! There’s another use case for litehtml: a native alternative to Zeal.
Having control over a native app could open to many interesting scenarios.
Thanks, well first I have to make it work reliably without crashing, so I’d really appreciate some help here…
Then I’d make it into a proper recipe for Haiku Ports and submit the library there.
I’m willing to work on the necessary changes to integrate this into the Mail app in a secure way, I’ve already an implementation in mind.
Lately I need to at least support opening links. The needed foundation is already provided by liblitehtml but it needs to be implemented on the frontend, deriving the relevant link from the mouse click position.
Text selection inside a contiguous block would also be quite easy to add it seems.
My original plan was to use netsurf librarier for this, it seems you already have quite a chunk done with this other library, one thing to keep in mind is also that there will be a native webkit2 based api for these use cases aswell.
got it working quite well now, Haiku website renders, kind of;-)
(it’s really intended for local use only, anyway, so I’ll work on resolving links and then try integrating with the Mail app).
The issue was caused by using fresh HttpSession objects on the heap for every remote call, which was an oversight and is now remedied by using a field. Crashes gone.
Nice work! if you cannot resolve links or intergration with the mail app, you could try surf. It does build and works nicely. I was never was able to get dmenu working on it.
thanks, I’m almost there.
Links are supported out of the box, I just had to add some integration code from BView::Mouse...() methods to call liblitehtml’s hook functions that in turn call the Haiku container when links are clicked or mouse hover events should be handled.
There’s some work left to do, it’s not quite working yet, but I can already see links change color when clicked.
I also added cursor support, so you will see the Haiku standard link hand when over a link.
The aim is really to build a lightweight, reusable HTML rendering component. I certainly don’t want to draw in more heavy weight browser dependencies like webkit or netsurf, this would just add unnecessary complexity and safety concerns (no Javascript in components!).
This should probably be included without the capabiltiy to connect to the network at all. Remote images can be a problem, but the mail app should do the downloading if anything (if it is explicitly asked to do so)
Exactly. I’ll include a flag to control if the HTML component is allowed to access remote content.
From the mail app side, I would suggest having a query to decide if it would access remote content, based on the sender and looking up local contacts (i.e. people).
We could for example allow this only for messages from contacts in certain groups etc.
Like the mail queries for drafts, new mail etc. this would be user configurable in a natural and consistent way.
I’m willing to implement the necessary changes for Mail in an official way (Trac issue, PR).
Maybe some day I’ll even get a mention in the activity report:=)
Well, we don’t have any PRs, but other than that this is good news ; )
Yes, per-contact would be nice. I could understand users wanting to allow this for certain “newsfeed” like emails (say marketing emails from online shops) but not want every other mail allow them to track via images…
I’ll submit one really soon now, just fighting with MouseDown() not being called in the html view although it’s properly overridden and has focus
So links don’t work yet and for some reason CPU load gets really high, something’s fishy.
For the mail app, that’s exactly the plan.
So you can add individual contacts or say “all close friends / family / …”.
The Query can be simply adjusted and search all indexed attributes including META:group, so it’s quite simple and powerful, a natural combination in Haiku
I’ve contributed to litehtml before… more specifically laying the ground work for the CSS gradient support that it now has.
Just note that the reason I can’t use it in MY email client is that it has zero support for selections. And I mean not even a hint of it. So the user can’t select something to copy.
Currently I use my own HTML renderer that is… well “ok”… but has more than enough issues. It would be so nice to delegate responsibility for parsing and rendering HTML to something like litehtml. However my own control has fairly decent selection support so it stays I guess. I also have a completely different rich text control that allows the user to author HTML. It has it’s own set of different issues, like no table support.
That’s awsome, didn’t know that!
Do you know why it doesn’t work for the Haiku website?
Also, I spotted some inline data: <svg content that is currently not handled, don’t even know if it’s legal… Update: it’s a normal data url, forgot about those. I’ve implemented detection so it doesn’t confuse the parsing but need to think about how and when to handle those.
I am aware of missing selection functionality, but once MouseDown works, this would be quite straightforward to add at least for contiguous text.
It’s definitely a todo for later but right now I don’t reem it really that important for a first version of HTML mail rendering though, as long as links work…
I really just want to be able to read HTML mail, I think HTML authoring would be overkill for a simple mail reader like the default Mail app.
Would be interested to check out your rich text control though, is it available somewhere?
I usually don’t reply to newsletters and for personal email, I never use HTML.
Just makes sense for marketing mail and newsletters to me. That should work for over 90% of use cases.
Almost all “business” emails I get are html, and i reply to those regularily (i.e to follow up on something). I don’t think just rendering them solves 90% of cases. Those cases are already solved as you can already tell it to open the html attachment in webpositive. : )
- I missed the nice renderin in GMail, so I set out to find a lightweight, easy to port HTML rendering library without dragging in webkit or other high profile browser engines.
