Description: If there is an application which wants to use WebKitQt to render html code, there is no way to load the html code from memory. Indeed, there is only one way to load html lines, it is the QWebPage::open(QUrl) function which can read only a file. So, it might be interesting to have a function which allow html rendering from a string,and because we are using Qt, from a QString.
Created attachment 14687 [details] a solution to this bug Here is my solution for this bug. I created a function which allow to load html in a Qstring.
IMHO the function should just be called setHtml.
Oh, I forgot: I think the function should take a QByteArray as argument. Unfortunately not every piece of HTML is utf-8 encoded these days.
setHTML might be misleaqding, since the load may still not be completely synchronous (at least if it works like data loads in other browsers). Also, I believe this particular approach to implementing the method is wrong. What I suggest instead is to make the FrameLoader do a data load, as that You also need a way to set the base URL. I suggest looking at the following methods in WebFrame in the Mac/ObjC WebKit API: - (void)loadHTMLString:(NSString *)string baseURL:(NSURL *)URL - (void)loadData:(NSData *)data MIMEType:(NSString *)MIMEType textEncodingName:(NSString *)encodingName baseURL:(NSURL *)URL The former is a convenience for a string but still lets you set a base URL for subresources, the later would be the equivalent of the QByteArray suggestion, it also lets you define the encoding and MIME type. In Qt terms, you could have: void loadHTMLString(const QString& string, const QUrl& baseURL); void loadData(const QByteArray& data, const QString& MIMEType, const QString& textEncodingName, const QUrl& baseURL); You should also look at the Mac implementation of these methods, they ultimately call down to FrameLoader::load(const ResourceRequest&, const SubstituteData&). This isx ultimately the right way to do it, just using begin/write/end can skip many necessary steps. r- to consider my and Simon's comments.
Thank you guys for the advice, but if I want to add this functions in FrameLoader, I can't use QString parameter in loadHTMLString(const QString& string, const QUrl& baseURL) function, because FrameLoader is not a specific class for QT. So, what is the good type to use??? String? Also, in order to create my openString(const QString &htmlString) function, I actualy looked at the loadHTMLString(...) function. I didn't put the URL parameter, but I did the same steps as in this function, I think. So I don't understand, what are the steps I missed.
Also I don't see that the Mac loadHTMLString function call the FrameLoader::load function. So, I don't know how to change my patch with adding the load function tacitly or not.
actually I was looking in the wrong files to look for MAC loadHTMLString function I was looking into a WebFrame.cpp file instead of a WebFrame.mm So now I know exactly where I have to look. :D
Created attachment 14809 [details] new revision of the path I think this patch should be good, I follow all the steps in the MAC function. Nevertheless, there is on thing I didn't use : // hack because Mail checks for this property to detect data / archive loads [NSURLProtocol setProperty:@"" forKey:@"WebDataRequest" inRequest:(NSMutableURLRequest *)request.nsURLRequest()]; I think it's a MAC hack, and think it's not useful, but I'm not sure.
Yeah, that step is mac-specific and should not be needed. I would suggest doing the SubstituteData thing on one line. I think one of the WebKitQt developers should review the API.
(In reply to comment #9) I don't really like a few things about the API: - URL vs Url, MIME vs mime, HTML vs Html naming - we may want to do this from Frame too, so maybe we're in the wrong place. - it seems really special cased. You either have to use utf-8 text/html, or you have to fill in all parameters manually, and there is no default at all for baseUrl.
Comment on attachment 14809 [details] new revision of the path r- based on George's comments above.
setHtml has been added in revision 29123 :)