Bug 211671 – Fix base64.any.html test

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Rob Buis]

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

[Rob Buis]

Created attachment 398936 [details]
Patch

[Darin Adler]

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"?

[Rob Buis]

Created attachment 398975 [details]
Patch

[EWS]

Committed r261468: <https://trac.webkit.org/changeset/261468>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 398975 [details].

[Radar WebKit Bug Importer]

<rdar://problem/63078186>

[Rob Buis]

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.

[Rob Buis]

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.