This only happens if a base URL is passed to loadHTMLString. If the same HTML string is saved to a file and loaded with loadURI, it works perfectly, because willAcquireUniversalFileReadSandboxExtension() is called in that case. This problem affects Devhelp the GNOME dev documentation viewer, it has a mode that loads parts of html files, extracted and loaded with loadHTML(). That HTML code contains links relative to the current path, so it passes the html file as base url. The problem is that it also has its own css and javascript in a different directory, see this example: Snippet extracted from file:///usr/share/gtk-doc/html/glib/glib-Hash-Tables.html <html><head><link rel="stylesheet" type="text/css" href="file:///usr/share/devhelp/assistant/assistant.css"/><script src="file:///usr/share/devhelp/assistant/assistant.js"></script></head><body onload="reformatSignature()"><div class="title">Function: <a href="file:///home/cgarcia/gnome/share/gtk-doc/html/glib/glib-Hash-Tables.html#g-str-hash">g_str_hash</a> .... In WebPageProxy::didInitiateLoadForResource() the url resource is checked and checkURLReceivedFromWebProcess() returns false, because it's not in the base url dir, which makes the web process to terminate: "Receive an invalid message from the web process with message ID 230049" This has always worked with WebKit1. Is this new behaviour expected or just a bug?
This is expected behavior. The reason is that showing generated pages that reference browser resources - such as error pages - should not enable access to arbitrary files (if they did, an exploited WebProcess would always be able to break out of its sandbox). Can the documentation viewer just pass "file:///" as base URL?
(In reply to comment #1) > This is expected behavior. The reason is that showing generated pages that reference browser resources - such as error pages - should not enable access to arbitrary files (if they did, an exploited WebProcess would always be able to break out of its sandbox). I see, the problem is that it works in WebKit1, so there are applications using it. > Can the documentation viewer just pass "file:///" as base URL? That would break links using relative paths link this example from the same html code I posted: <a class="link" href="glib-Hash-Tables.html#g-hash-table-new" title="g_hash_table_new ()">
A possible solution for the application might be to save the contents in a temp file and use loadURI() instead of loadHTML(), but I think it would be better if we could use loadHTML(). On the other hand, maybe terminate de web process in that case is a bit drastic, I thought it was a crash the first time it happened.
Getting an unexpected URL from WebProcess means that it has been exploited and now runs malicious code. Immediate termination is the least we can do. Of course this all makes less sense on platforms that don't sandbox WebProcess.
The workaround I've used for devhelp is to use data uris for resources (css and javascript). I'll document in load_html() gtk docs that uris not relative to the base_url will cause the web process to terminate. So, if this is the expected behaviour, feel free to close the bug. Thanks for your help.