Fix base64.any.html test by extending DataURLDecoder with a forgiving-base64 decode mode [1], as used by the Fetch data: URL processor algorithm [2]. [1] https://infra.spec.whatwg.org/#forgiving-base64-decode [2] https://fetch.spec.whatwg.org/#data-url-processor
Created attachment 398936 [details] Patch
Comment on attachment 398936 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398936&action=review > Source/WebCore/loader/ResourceLoader.cpp:278 > + auto mode = DataURLDecoder::Mode::Default; > + if (m_request.requester() == ResourceRequest::Requester::Fetch) > + mode = DataURLDecoder::Mode::ForgivingBase64; In this context, the name ForgivingBase64 isn’t great. The reason is that this is actually *stricter* than the default. Maybe the other mode needs a name other than "Default"?
Created attachment 398975 [details] Patch
Committed r261468: <https://trac.webkit.org/changeset/261468> All reviewed patches have been landed. Closing bug and clearing flags on attachment 398975 [details].
<rdar://problem/63078186>
Comment on attachment 398936 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398936&action=review >> Source/WebCore/loader/ResourceLoader.cpp:278 >> + mode = DataURLDecoder::Mode::ForgivingBase64; > > In this context, the name ForgivingBase64 isn’t great. The reason is that this is actually *stricter* than the default. Maybe the other mode needs a name other than "Default"? I went with Legacy before landing this.
Antti, can you remember what specification the DataURLDecoder was following before Fetch was a thing? Was it HTMLx? I am wondering if we can just always use the new Fetch/forgiving-base64-decode now. It does not break the tests but I have no idea whether websites rely on the legacy behavior.