Open Bug 1670520 Opened 4 years ago Updated 10 months ago

Copy/Paste adds extraneous whitespace when copying text inside a dl

Categories

(Core :: DOM: Serializers, defect)

Product:
Core
Component:
DOM: Serializers
Version:
79 Branch
Platform:
Desktop
All
Type:
defect

Tracking

()

Project Flags:
Webcompat Priority P3
Tracking Flags:
Tracking Status
firefox81 --- affected
firefox82 --- affected
firefox83 --- affected

People

(Reporter: karlcow, Unassigned)

References

(
URL
)

Details

Steps to reproduce

  1. Copy and Paste this URL in your browser
data:text/html,<!doctype html><title>copy/paste</title><dl><dd>foo</dd></dl>
  1. Enter
  2. Select the foo text by double or triple click
  3. Paste into a text document

Expected:
Have just the string foo

Actual:
We get foo (aka four whitespace + foo)

This seems remotely familiar to Bug 211233
Maybe there is already an existing bug for this.

If I select the three letters by dragging on double-clicking on Linux (GDK in Wayland mode), copy, and paste, I get just the three letters. If I select by ctrl-a, I get the four spaces, too.

This seems expected.

I can repro on Mac with triple-click but not double-click. This suggests that this is an intentional difference between what double and triple-clicking means.

Masayuki, can you confirm the intent?

I believe this one is WFM.

Severity: -- → S4
Flags: needinfo?(masayuki)

It's intentionally done:
https://searchfox.org/mozilla-central/rev/25d5a4443a7e13cfa58eff38f1faa5e69f0b170f/dom/base/nsPlainTextSerializer.cpp#780,782

And it's implemented at creating the first version of nsPlainTextSerializer.
https://searchfox.org/mozilla-central/rev/4ddd46c0602c3809f5afc156c6160501181a8fa4/content/base/src/nsPlainTextSerializer.cpp#594-595

Chrome does not indent <dd> even when there is <dt> in the <dl> element. I'm not sure whether which behavior is better for majority. Mirko, do you have some ideas?

Flags: needinfo?(masayuki) → needinfo?(mbrodesser)

Well, if the selection range is in <dd> element (i.e., when selecting only in the text node with double click), the indent shouldn't be set. But when triple click, the <dd> element is selected (i.e., when the range is {<dl> - 0, <dl> - 1}), I feel that indenting the text seems reasonable. On the other hand, if only one <dd> element is selected, no indent might be more reasonable since indent of <dd> must be required only when there is a line which is not indented.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #4)

Well, if the selection range is in <dd> element (i.e., when selecting only in the text node with double click), the indent shouldn't be set.

Agree.

But when triple click, the <dd> element is selected (i.e., when the range is {<dl> - 0, <dl> - 1}), I feel that indenting the text seems reasonable. On the other hand, if only one <dd> element is selected, no indent might be more reasonable since indent of <dd> must be required only when there is a line which is not indented.

I agree with "no indent might be more reasonable since indent of <dd> must be required only when there is a line which is not indented.".
Note that when triple-clicking it seems only possible to select exactly one <dd>.

Flags: needinfo?(mbrodesser)
See Also: → 211233
Webcompat Priority: P3 → ?
Webcompat Priority: ? → P3

Related question on Stackoverflow: https://stackoverflow.com/questions/66447991/when-copying-text-from-dd-styled-to-select-all-text-in-firefox-leading-whites

This is an odd behavior, especially when the detail list is used to show some code stuff that user may want to copy with a triple-click.

Indenting is ok but adding space when copying the indented text is not obvious.

Is there any plan to fix this?

You need to log in before you can comment on or make changes to this bug.