Running Safari on iOS 14.5 (iPhone, iPad) will render HTML content as plaintext when the Blob.type is 'text/html; charset=UTF-8'. Reproduktion Example: https://jsfiddle.net/9h71Lqb0/ The following code will not work in iOS 14.5 anymore: var html = `<h1>This is Blob Content</h1>`; var blob = new Blob([html], {type: 'text/html; charset=UTF-8'}); var iframe = document.querySelector("iframe"); iframe.src = URL.createObjectURL(blob); The following code is working as expected and showcases the behaviour in earlier versions: var html = `<h1>This is Blob Content</h1>`; var blob = new Blob([html], {type: 'text/html'}); var iframe = document.querySelector("iframe"); iframe.src = URL.createObjectURL(blob); There might be some connection/relation to https://bugs.webkit.org/show_bug.cgi?id=225057 which has been submitted earlier this week.
> The following code will not work in iOS 14.5 anymore: Could you please confirm if this worked before iOS 14.5? Which is the latest version known to work?
This is still broken on trunk. Not sure when it regressed but it was already broken on r266000.
(In reply to Alexey Proskuryakov from comment #1) > Could you please confirm if this worked before iOS 14.5? Which is the latest > version known to work? Here is what i know for sure: We have an app which is primarily using WKWebView (ReactNativeJS App). This app stopped working with the update on 28th of april and we started investigating a possible cause. We then discovered that the same problem also appeared in Safari on iOS and we have also gotten reports from customers using the website with the latest updates of Safari on MacOS. We have a phone in QA with iOS 14.4 which was reported to NOT have the bug in WKWebView but in Safari already. My means of testing older Safari / iOS versions is limited - but i hope this information helps in tracking down the cause.
I went as far back as r263000 and it was already failing. Earlier builds do not run on my machine. The demo does work on Chrome and it does seem like something we should fix, no matter if this is a recent regression or not.
(In reply to Stefan Pasel from comment #3) > (In reply to Alexey Proskuryakov from comment #1) > > Could you please confirm if this worked before iOS 14.5? Which is the latest > > version known to work? > > > Here is what i know for sure: > > We have an app which is primarily using WKWebView (ReactNativeJS App). This > app stopped working with the update on 28th of april and we started > investigating a possible cause. > > We then discovered that the same problem also appeared in Safari on iOS and > we have also gotten reports from customers using the website with the latest > updates of Safari on MacOS. > > We have a phone in QA with iOS 14.4 which was reported to NOT have the bug > in WKWebView but in Safari already. Interesting. So this may be a recent regression in WKWebView but a pre-existing bug in Safari.
m_blobData->contentType() in NetworkDataTaskBlob::dispatchDidReceiveResponse() is "text/html; charset=utf-8", which looks good. Things must be going wrong later on.
(In reply to Chris Dumez from comment #6) > m_blobData->contentType() in > NetworkDataTaskBlob::dispatchDidReceiveResponse() is "text/html; > charset=utf-8", which looks good. Things must be going wrong later on. Even in DocumentLoader::responseReceived() the MIME type is still correct: DocumentLoader::responseReceived() URL: blob:https://fiddle.jshell.net/bfee7052-96f8-4df0-b134-30adf078bf3d, mime type: text/html; charset=utf-8
Interesting finding, if I use 'text/html' as blob content type instead of 'text/html; charset=UTF-8' then it works as expected.
(In reply to Chris Dumez from comment #8) > Interesting finding, if I use 'text/html' as blob content type instead of > 'text/html; charset=UTF-8' then it works as expected. Question for Youenn & Alex, isn't this a surprising result? Content-Type header: text/html; charset=utf-8, ResourceResponse::mimeType(): text/html; charset=utf-8 I would have expected ResourceResponse::mimeType() to have returned "text/html", without the charset. I think we rely on CFNetwork to retrieve the response's MIME type so I am wondering is this could be due a CFNetwork change?
(In reply to Chris Dumez from comment #9) > (In reply to Chris Dumez from comment #8) > > Interesting finding, if I use 'text/html' as blob content type instead of > > 'text/html; charset=UTF-8' then it works as expected. > > Question for Youenn & Alex, isn't this a surprising result? > Content-Type header: text/html; charset=utf-8, ResourceResponse::mimeType(): > text/html; charset=utf-8 > > I would have expected ResourceResponse::mimeType() to have returned > "text/html", without the charset. I think we rely on CFNetwork to retrieve > the response's MIME type so I am wondering is this could be due a CFNetwork > change? Oh, I suspect this line is wrong in NetworkDataTaskBlob::dispatchDidReceiveResponse(): ResourceResponse response(m_firstRequest.url(), errorCode != Error::NoError ? "text/plain" : m_blobData->contentType(), errorCode != Error::NoError ? 0 : m_totalRemainingSize, String()); It is passing m_blobData->contentType() as a MIME type to the ResourceResponse constructor.
I have a fix, working on a test.
Created attachment 427701 [details] Patch
(In reply to Stefan Pasel from comment #3) > (In reply to Alexey Proskuryakov from comment #1) > > Could you please confirm if this worked before iOS 14.5? Which is the latest > > version known to work? > > > Here is what i know for sure: > > We have an app which is primarily using WKWebView (ReactNativeJS App). This > app stopped working with the update on 28th of april and we started > investigating a possible cause. > > We then discovered that the same problem also appeared in Safari on iOS and > we have also gotten reports from customers using the website with the latest > updates of Safari on MacOS. > > We have a phone in QA with iOS 14.4 which was reported to NOT have the bug > in WKWebView but in Safari already. > > My means of testing older Safari / iOS versions is limited - but i hope this > information helps in tracking down the cause. Note that while this is a WebKit bug. This does not appear to be a recent regression on our side. This code has been wrong for years.
Committed r276986 (237312@main): <https://commits.webkit.org/237312@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 427701 [details].
<rdar://problem/77529459>
> > Note that while this is a WebKit bug. This does not appear to be a recent > regression on our side. This code has been wrong for years. First of all: Thanks for fixing the root problem. I'm really puzzled why this emerged just recently.