1823690 - When pasting data:text/html with CRLF codes into the address bar and opening it, the layout is different between Firefox and Chrome.

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[Alice0775 White]

Steps to reproduce:

1. Copy the following strings

data:text/html,<span>bla bla bla
bla bla</span>

2. Paste into address bar and press enter key

Actual results:
Firefox: bla bla blabla bla
Chrome : bla bla bla bla bla

Expected results:
both same

This does not happen if open from html file.

Comment 1

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Drew Willcoxon :adw]

Adding a space between the two lines on paste, as Chrome does, makes sense to me. More info:

• On paste in the address bar, Firefox doesn't add a space between the two lines
• On paste in textboxes in web content, Firefox does add a space (I tested with textboxes on Bugzilla, in case it matters)
• On paste in the omnibox, Chrome adds a space (as Alice mentioned)

Looks like this behavior was regressed or at least modified by bug 1327589, which deliberately replaced \r and \n with an empty string, see this code. I don't remember the context from that bug. Maybe we could have replaced those characters with single spaces instead of an empty string and still have fixed the bug.

Comment 3

[BugBot [:suhaib / :marco]]

:daisuke, since you are the author of the regressor, bug 1327589, could you take a look?

For more information, please visit auto_nag documentation.

Comment 4

[Daisuke Akatsuka (:daisuke)]

Thank you very much for your report!
Yes, I also confirmed the issue.
So, it seems that we need to add special handling for data url at least.

Comment 5

[Daisuke Akatsuka (:daisuke)]

I investigated the behavior of Chrome a bit more.
It seems that if the pasting data has white space at least one, they replace the line break with a white space.
(I could not add a line break in the table in markdown, add <br> instead.)

name	input	result
keywords without white space	123<br>45<br>6	123456
keywords with white space	123<br>45 6	123 45 6
url without white space	http://exam<br>ple.<br>com	http://example.com
url with white space	http://exam<br>ple.co m	http://exam ple.co m
data url without white space	data:text/html,123<br>45<br>6	data:text/html,123456
data url with white space	data:text/html,123<br>45 6	data:text/html,123 45 6

Chrome is consistent in the sense that its behavior changes depending on whether there is whitespace or not. However, is not consistent for the data type.
For ours, I think we’d better take consistency by the data type as we are doing.
For the data url, when the content expresses by base64, remove line break simply. Otherwise, replace line break with white space.

name	input	result	remarks
keywords without white space	123<br>45<br>6	123 45 6	Replace with white space
keywords with white space	123<br>45 6	123 45 6	Replace with white space
url without white space	http://exam<br>ple.<br>com	http://example.com	Remove line breaks
url with white space	http://exam<br>ple.co m	http://example.co m	Remove line breaks
data url without white space	data:text/html,123<br>45<br>6	data:text/html,123 45 6	Replace with white space
data url with white space	data:text/html,123<br>45 6	data:text/html,123 45 6	Replace with white space
base64 data url without white space	data:text/html;base64,123<br>45<br>6	data:text/html;base64,123456	Remove line breaks
base64 data url with white space	data:text/html;base64,123<br>45 6	data:text/html;base64,12345 6	Remove line breaks

I will implement as above, but if you have opinions, please let me know.

Comment 6

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1823690: Change behavior of pasting data url

Comment 7

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1327589

Comment 8

[Drew Willcoxon :adw]

Thanks for doing all that research Daisuke! I started doing some too but then I saw your comment, so I'm glad.

IMO Chrome's approach is good because it's simple and predictable, but Firefox has had more complicated behavior around this for a while, including stripping line breaks from strings that look like URLs, so I guess we should continue to respect that (bug 513648 and bug 1014246 for example).

I'll add more comments in the phabricator.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/23fa52107ed3
Change behavior of pasting data url r=adw

Comment 10

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/23fa52107ed3

Comment 11

[BugBot [:suhaib / :marco]]

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

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

For more information, please visit auto_nag documentation.

Comment 12

[Daisuke Akatsuka (:daisuke)]

Comment on attachment 9327741 [details]
Bug 1823690: Change behavior of pasting data url

Beta/Release Uplift Approval Request

• User impact if declined: When user pastes texts including line breaks on urlbar, an unexpected text might be pasted.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This change only affects the behavior of pasting on urlbar.
• String changes made/needed: None
• Is Android affected?: Unknown

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9327741 [details]
Bug 1823690: Change behavior of pasting data url

Approved for 113.0b5.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/4bf9d3c89ce7

Comment 15

[Giorgia Nichita, Release Desktop QA]

Reproduced this issue on an affected Nightly build from 2023-03-21 on Windows 10, using the STR from comment 0.
Verified as fixed on 114.0a1 (20230419214510) and Firefox 113.0b5 (20230418175842) on Win 10 x64, Ubuntu 20.04 and macOS 10.15.