Bug 46091 – Add WebKit2 API to load a string as plain text

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Sam Weinig]

Add WebKit2 API to load a string as plain text

[Sam Weinig]

Created attachment 68083 [details]
Patch

[Adam Roben (:aroben)]

Comment on attachment 68083 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=68083&action=review

> WebKit2/WebProcess/WebPage/WebPage.cpp:257
> +void WebPage::commonLoadData(PassRefPtr<SharedBuffer> sharedBuffer, const String& MIMEType, const String& encodingName, const KURL& baseURL, const KURL& failingURL)
> +{
> +    ResourceRequest request(baseURL);
> +    SubstituteData substituteData(sharedBuffer, MIMEType, encodingName, failingURL);
> +    m_mainFrame->coreFrame()->loader()->load(request, substituteData, false);
> +}

I don't think there's any need for "common" in this function name.

> WebKit2/WebProcess/WebPage/WebPage.cpp:270
>  void WebPage::loadHTMLString(const String& htmlString, const String& baseURLString)
>  {
>      RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(reinterpret_cast<const char*>(htmlString.characters()), htmlString.length() * sizeof(UChar));
> -    String MIMEType("text/html");
> -    String encodingName("utf-16");
>      KURL baseURL = baseURLString.isEmpty() ? blankURL() : KURL(KURL(), baseURLString);
> -    KURL failingURL;
> -
> -    ResourceRequest request(baseURL);
> -    SubstituteData substituteData(sharedBuffer.release(), MIMEType, encodingName, failingURL);
> +    commonLoadData(sharedBuffer, "text/html", "utf-16", baseURL, KURL());
> +}
>  
> -    m_mainFrame->coreFrame()->loader()->load(request, substituteData, false);
> +void WebPage::loadPlainTextString(const String& string)
> +{
> +    RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(reinterpret_cast<const char*>(string.characters()), string.length() * sizeof(UChar));
> +    commonLoadData(sharedBuffer, "text/plain", "utf-16", blankURL(), KURL());
>  }

Neither of these functions seems prepared to handle sharedBuffer outliving the string it's constructed from. Is that a problem?

[Sam Weinig]

(In reply to comment #2)
> (From update of attachment 68083 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=68083&action=review
> 
> > WebKit2/WebProcess/WebPage/WebPage.cpp:257
> > +void WebPage::commonLoadData(PassRefPtr<SharedBuffer> sharedBuffer, const String& MIMEType, const String& encodingName, const KURL& baseURL, const KURL& failingURL)
> > +{
> > +    ResourceRequest request(baseURL);
> > +    SubstituteData substituteData(sharedBuffer, MIMEType, encodingName, failingURL);
> > +    m_mainFrame->coreFrame()->loader()->load(request, substituteData, false);
> > +}
> 
> I don't think there's any need for "common" in this function name.

Changed to loadData.

> 
> > WebKit2/WebProcess/WebPage/WebPage.cpp:270
> >  void WebPage::loadHTMLString(const String& htmlString, const String& baseURLString)
> >  {
> >      RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(reinterpret_cast<const char*>(htmlString.characters()), htmlString.length() * sizeof(UChar));
> > -    String MIMEType("text/html");
> > -    String encodingName("utf-16");
> >      KURL baseURL = baseURLString.isEmpty() ? blankURL() : KURL(KURL(), baseURLString);
> > -    KURL failingURL;
> > -
> > -    ResourceRequest request(baseURL);
> > -    SubstituteData substituteData(sharedBuffer.release(), MIMEType, encodingName, failingURL);
> > +    commonLoadData(sharedBuffer, "text/html", "utf-16", baseURL, KURL());
> > +}
> >  
> > -    m_mainFrame->coreFrame()->loader()->load(request, substituteData, false);
> > +void WebPage::loadPlainTextString(const String& string)
> > +{
> > +    RefPtr<SharedBuffer> sharedBuffer = SharedBuffer::create(reinterpret_cast<const char*>(string.characters()), string.length() * sizeof(UChar));
> > +    commonLoadData(sharedBuffer, "text/plain", "utf-16", blankURL(), KURL());
> >  }
> 
> Neither of these functions seems prepared to handle sharedBuffer outliving the string it's constructed from. Is that a problem?

No, it is not a problem. SharedBuffer will copy the string. We should consider adding a way for the sharedBuffer to adopt an existing buffer (such as one released from a string) though,

[Sam Weinig]

Landed in r67849.