1895687 - LF numeric character reference gets ignored in data:text/plain URL

Status: RESOLVED FIXED

(Core :: Networking, defect, P2)

Description

[Tisza Gergő]

Steps to reproduce:

Create a download link with <a download href="data:text/plain;charset=utf-8,[some text]"> where the text includes newlines encoded as

Test page: https://codepen.io/tisza_gergo/pen/RwmbeRv

Actual results:

The newlines are omitted in the downloaded file.
(Tested in Firefox 125.0.3 on Ubuntu.)

Expected results:

As far as I can see this is a perfectly valid encoding and the newlines should be present in the downloaded file. It does work correctly in Chrome.

Comment 1

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Managed to reproduce on:

• Firefox Nightly 127.0a1;
• Firefox 126.0;

Tested and reproduced on:

• macOS 12;
• Windows 10;
• Ubuntu 22;

Moving the Component to ‘General’. Please change if there’s a better fit, thank you.
Setting as NEW so the developing team can have a look.

Comment 2

[:Gijs (he/him)]

The href property, when inspecting it and using the web development console, says:

$0.href
data:text/plain;charset=utf-8,first%20linesecond%20line

so there is no newline in the DOM. So this breaks well before we get to downloading / file handling. The same difference with Chrome is visible when omitting download="" and just opening the link - Chrome displays a newline and Firefox does not.

Using $0.getAttribute("href") produces the same result in Chrome and Firefox (though it's printed differently in the different consoles 🙃) which does include the newline. So over to URI parsing, which I suspect is doing this.

Comment 3

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

I think we are following the URL standard here. For some reason, Chrome is escaping the \n to %0A character in the string before it reaches the URL parser.

You can check that all browsers Chrome, Firefox and Stafari parse the URL in the same way and correctly strip out \n characters by going to https://jsdom.github.io/whatwg-url/ and pasting data:text/plain;charset=utf-8,first\u{0020}line\u{000A}second\u{0020}line in the Input with escapes: field.

I've also checked with Safari, and they parse the href of the link element the same as Firefox data:text/plain;charset=utf-8,first%20linesecond%20line.

See https://url.spec.whatwg.org/#url-parsing

Remove all ASCII tab or newline from input.
An ASCII tab or newline is U+0009 TAB, U+000A LF, or U+000D CR.

So the difference here is due to Firefox and Safari unescaping the characters before parsing, while Chrome unescapes and percent encodes them.
I haven't checked the HTML spec to see what's actually supposed to happen here.

Thomas, do you think we should just close this, or should we add this exact test case to the WPT suite?

Comment 4

[Thomas Wisniewski [:twisniewski]]

I think we should make sure that a bug is filed with Chromium, and yes: adding a WPT is the way to go, along with adding it to interop2024's URL bucket, so Chromium can be interoperable here.

Comment 5

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

Attachment: Bug 1895687 - Add WPT for 0x0A character embedded in HTML data URL getting stripped r=twisniewski

Comment 6

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

I filed a chrome bug https://issues.chromium.org/issues/344343043

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dd61e4564437
Add WPT for 0x0A character embedded in HTML data URL getting stripped r=twisniewski

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/46591 for changes under testing/web-platform/tests

Comment 9

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/dd61e4564437

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:valentin, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox127 to wontfix.

For more information, please visit BugBot documentation.

Comment 11

[Valentin Gosu [:valentin] {{ PTO 3 July - 3 August }}]

This wasn't actually a bug in Firefox. Marking as not affected.

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot