WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
225226
Blob contentType with charset renders html as plain text
https://bugs.webkit.org/show_bug.cgi?id=225226
Summary
Blob contentType with charset renders html as plain text
Stefan Pasel
Reported
2021-04-30 01:25:45 PDT
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.
Attachments
Patch
(7.31 KB, patch)
2021-05-04 14:34 PDT
,
Chris Dumez
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2021-05-04 10:51:41 PDT
> 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?
Chris Dumez
Comment 2
2021-05-04 10:58:57 PDT
This is still broken on trunk. Not sure when it regressed but it was already broken on
r266000
.
Stefan Pasel
Comment 3
2021-05-04 11:14:56 PDT
(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.
Chris Dumez
Comment 4
2021-05-04 12:27:43 PDT
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.
Chris Dumez
Comment 5
2021-05-04 12:29:45 PDT
(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.
Chris Dumez
Comment 6
2021-05-04 12:42:42 PDT
m_blobData->contentType() in NetworkDataTaskBlob::dispatchDidReceiveResponse() is "text/html; charset=utf-8", which looks good. Things must be going wrong later on.
Chris Dumez
Comment 7
2021-05-04 12:58:51 PDT
(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
Chris Dumez
Comment 8
2021-05-04 13:36:25 PDT
Interesting finding, if I use 'text/html' as blob content type instead of 'text/html; charset=UTF-8' then it works as expected.
Chris Dumez
Comment 9
2021-05-04 13:54:15 PDT
(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?
Chris Dumez
Comment 10
2021-05-04 13:59:33 PDT
(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.
Chris Dumez
Comment 11
2021-05-04 14:08:18 PDT
I have a fix, working on a test.
Chris Dumez
Comment 12
2021-05-04 14:34:22 PDT
Created
attachment 427701
[details]
Patch
Chris Dumez
Comment 13
2021-05-04 14:35:19 PDT
(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.
EWS
Comment 14
2021-05-04 15:37:16 PDT
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]
.
Radar WebKit Bug Importer
Comment 15
2021-05-04 15:38:17 PDT
<
rdar://problem/77529459
>
Stefan Pasel
Comment 16
2021-05-04 23:28:48 PDT
> > 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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug