GNOME Bugzilla – Bug 731532
Use iframes for holding message content in conversation view
Last modified: 2016-12-20 13:43:07 UTC
Currently, we get HTML from emails and stick it into a <div> in the conversation view. This works fine as long as the HTML is well-behaved. But it isn't always, so we get some problems: 1) Styles in the emails can influence the display of UI elements (bug #712904). 2) To work around this, we strip incoming HTML down to the <body> element, if it provides that, to strip out <style> elements in the head. But this causes problems when receiving malformed HTML (bug #713547, bug #730680). 3) Absolutely positioned elements could show up anywhere in the conversation view (a theoretical problem at this point: bug #724270). 4) Setting the document font for the email bodies is a bit harder than it ought to be (see discussion in bug #713746). 5) We have to turn off Javascript, so all DOM manipulation is done in Vala. This will be harder in WebKit2 (bug #728002). It also means, for example, that we can't create new DOMs to play with content before inserting them into the main document; instead we have to stick them into the main document and modify them in place. None of these is a big problem, but I think we could solve all of them by putting the email's contents into an <iframe>. This would keep content from escaping (1,3). We could stick all the content into the iframe, and let WebKit deal with the malformed HTML, since it will be more forgiving than we are (2). The <iframe> won't inherit the UI font from its parent (4). And we can sandbox the iframe, allowing us to run JS in the UI level while prohibiting it in the message contents (5). The problems I see off-hand are: 1) It'll be a bit harder to construct the HTML for a new message, since we'll have to insert the contents into the new frame's document. 2) We'll have to adjust the height of the iframe manually to keep all its contents visible. Unlike a <div>, it won't expand on its own. 3) The quote controls will have to be set inside of the iframes, and will still have to be in Vala, since we can't use JS inside them. If we were starting from scratch, I'd say the benefits easily outweigh the costs. But we aren't, and the larger problems of the single-document method have already been dealt with, so I'm not convinced the slight gain we get is worth the effort of refactoring.
At this moment, none of the above are pressing problems. Although the style/CSS issues are real, in my own experience almost all of them have been taken care of, although I admit some of that code isn't as clean as I would like. The big question is WebKit 2 and if JS would solve problems in the port. I feel like we only know the exposure there once we start going down that path.
I'm not planning to do anything about this soon. But I wanted to have some place where all of these issues were cross-referenced, in case we attack this in the future.
I just learned about the Content-Security-Policy header (http://www.html5rocks.com/en/tutorials/security/content-security-policy/), which allows you to disable inline javascript, among other things. I'm not sure if we'd be able to use it for a document loaded from file://. I haven't seen a WebKitGTK API to use. Some browsers let you set it in a <meta> tag (https://bugzilla.mozilla.org/show_bug.cgi?id=663570), but I don't know if WebKit supports this itself. But it might be another way to allow controlled javascript execution, if we decide we need that.
This has been obsoleted by Bug 765516.