[Webkit-unassigned] [Bug 137756] WKWebView: JavaScript fails to load, apparently due to decoding error

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=137756

--- Comment #12 from Alexey Proskuryakov <ap at webkit.org> ---
> Specifying the subresource encoding is a fine workaround when the developer has control over the web server. But in our case we want to use `loadHTMLString` to load a dynamic `index.html` page and then have subresources accessed as file:// URLs.

It sounds like there is a bigger problem if this is what you are doing - subresources won't load at all. You said that you observed the problem on a device, which is very surprising - sandboxing should have prevented loading any local files.

> So in this case we have no control over the headers.

A charset can also be specified in other ways:
- at the start of any text subresource, you can have a UTF-8 BOM (EF BB BF), which will make the resource interpreted as UTF-8;
- at the start of a CSS subresource, you can have a @charset rule;
- XSL stylesheets can have the charset declared in a regular XML way (<?xml version="1.0" encoding="UTF-8" ?>);
- in HTML that loads subresources, you can have charset attributes (<script src="myscript.js" charset="UTF-8">).

> Is this something that could be exposed in the WK framework?

UIWebView has always had a -loadData method, and it does seem like WKWebView needs one, too.

-(void)loadData:(id)data MIMEType:(id)type textEncodingName:(id)name baseURL:(id)url;

> In light of this I would like to ask for the "INVALID" resolution to be reconsidered.

In any case, please let's not reopen this bug. It has gone a long way since the original decoding mystery, and exactly because of this, it will be very difficult for others to read.

My suggestion would be to file a bug with Apple via http://bugreport.apple.com, asking for an equivalent of UIWebView's -loadData.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141020/f08aa84b/attachment-0002.html>