1 issue found across 2 files

Confidence score: 3/5

• There is a concrete regression risk in lib/helpers/fromDataURI.js: RFC 2397 shorthand inputs like data:;charset=UTF-8,... can now match, but produce a Blob with an invalid type because the implicit text/plain default is not normalized.
• Given the medium severity (6/10) and high confidence (8/10), this is likely user-facing for consumers that rely on correct Blob MIME types, so the merge carries some functional risk.
• Pay close attention to lib/helpers/fromDataURI.js - ensure shorthand data URI parsing normalizes omitted media types to RFC defaults before constructing the Blob type.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="lib/helpers/fromDataURI.js">

<violation number="1" location="lib/helpers/fromDataURI.js:36">
P2: Valid RFC 2397 shorthand data URIs (e.g. `data:;charset=UTF-8,...`) are accepted by the new regex but produce an invalid Blob `type` because the omitted `text/plain` default is not normalized.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

Thanks for the patch @abhu85, a couple of things to sort out before this can land.

The regex is looser than the one drafted in #10808:

lib/helpers/fromDataURI.js:7. The form you have, /^([^,]*?)(;base64)?,(.*)$/s, accepts shapes that are not valid mediatypes. data:not-a-mime,hello matches with mime="not-a-mime", and data:;notparam,x gets normalized to mime="text/plain;notparam". The issue lies in the stricter form for a reason:

const DATA_URL_PATTERN = /^([^,;]+\/[^,;]+)?((?:;[^,;=]+=[^,;]+)*)(;base64)?,([\s\S]*)$/;

That requires type/subtype to actually contain a /, requires parameters to be name=value shaped, and keeps ;base64 as its own group. Please switch to that.

The test matrix from #10808 is not fully ported:

tests/unit/fromDataURI.test.js. The issue listed a specific set of cases that should be fixed. Currently missing:

• data:text/plain;charset=US-ASCII,123, the canonical RFC example (charset param with a mediatype, no base64)
• URL encoded body decoding, e.g. data:text/plain,hello%20world resolving to "hello world"
• Blob output preserving the full content type including parameters, e.g. data:text/plain;charset=utf-8;base64,... giving blob.type === "text/plain;charset=utf-8". The existing normalisation test only covers the parameter-only case
• datax:,hi throws Unsupported protocol. The current notadata:uri test exercises a different code path in parseProtocol
• data:hi (no comma) throws Invalid URL

###mall out the Blob.type behaviour shift in the PR body:
For inputs like data:text/plain;charset=utf-8;base64,... the produced Blob.type changes from "text/plain" (the old regex truncated at the ;) to "text/plain;charset=utf-8". This is a fix; the old behaviour was silently dropping the charset, but anyone who asserted on the old truncated value will see a diff. One line in the description is enough, so it ends up in the changelog cleanly at release time.

Two small nits:

• lib/helpers/fromDataURI.js:38. const isBase64 = match[2] ? 'base64' : ''; does not really earn the conversion. The downstream use only needs truthiness. Either drop it or rename to encoding and assign 'base64' or 'utf8' directly so the next ternary collapses.
• lib/helpers/fromDataURI.js:36. The dense one-liner is correct, but a small if/else with a one-line comment pointing at RFC 2397 §3 reads cleaner.

1 issue found across 2 files (changes from recent commits).

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="lib/helpers/fromDataURI.js">

<violation number="1" location="lib/helpers/fromDataURI.js:47">
P2: RFC 2397’s default `text/plain;charset=US-ASCII` is not applied for `data:,`, so Blob metadata stays empty instead of using the RFC default.</violation>
</file>

_{Tip: Review your code locally with the cubic CLI to iterate faster.}