<html><head></head><body>that's a good idea actually, as last resort emergency measure. it'll be some effort, but should theoretically work.<br>
<br>
it would be important to use it for all untrusted content, including email body.<br><br><div class="gmail_quote">Am 3. Februar 2018 14:26:16 MEZ schrieb Gervase Markham <gerv@mozilla.org>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 03/02/18 13:23, Eyal Rozenberg wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Disagree about the method of achieving speed and stability. For the<br /> Thunderbird dev community to maintain a fork of a rendering engine seems<br /> like over-reaching. <br /></blockquote><br />I'm not sure if this idea has ever been discussed - maybe it has.<br /><br />The difficulty with maintaining an ever-more-distant fork of a rendering<br />engine such as Gecko has always been said to be "security updates". And<br />that is a clear concern.<br /><br />What if... Thunderbird forked Gecko and froze it, running most of the<br />app and the UI on top, and then embedded a second, maintained,<br />embeddable, lightweight rendering engine which dealt with all untrusted<br />content? Such as Servo?<br /><br />Servo is designed to be embeddable ("Servo is a modern, high-performance<br />browser engine designed for both application and embedded use.") It<br />might be that the combined size or memory use of shipping two rendering<br />engines ends up being too much, I don't know. But how much of a<br />rendering engine do you really need for HTML email?<br /><br />Gerv<br /><hr /><br />tb-planning mailing list<br />tb-planning@mozilla.org<br /><a href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my phone. Please excuse the brevity.</body></html>