1291467 - (contenteditable-plaintext-only) Implement contenteditable="plaintext-only"

Status: RESOLVED FIXED

(Core :: DOM: Editor, enhancement, P3)

Description

[Monica]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

Chrome, Safari and (recently) Edge now all support `<div contenteditable="plaintext-only">`, to remove formatting from the div contents

Sample JSBin: http://jsbin.com/kaladi/edit?html,output


Actual results:

Cannot paste content at all in a `<div contenteditable="plaintext-only">`


Expected results:

It should behave like a normal `<div contenteditable>`, but formatting should always be removed.

Comment 1

[Ojan Vafai]

Masayuki-san or Aryeh, who are the right people at Mozilla to CC here?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, the behavior of <div contenteditable="plaintext-only"> is really different between Edge vs. Chrome.

Looks like that Chrome uses |white-space: pre-wrap;| and inserts "\n" at pressing Enter key. So, this is similar to <textarea> handling in Gecko.

On the other hand, Edge uses |white-space: normal;| (but it's odd, two or more whitespaces are not collapsed!) and inserts <br> at pressing Enter key. This looks like "limited" HTML editor.

I'm not sure what the standardized spec of this feature...

Ojan, do you have draft of this feature?

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oops, and I forgot to reply to your question.

Temporarily, I'm an unofficial module owner of editor. But nobody including me are not working on editor aggressively.

Comment 4

[Monica]

As a user (and I don't know if this is a view that matters), entering "<br>"s instead of "\n"s is preferable because you can get easy single-line inputs by hiding the <br>: http://jsbin.com/sukelu/edit?html,output

Although that demo looks like it works fine in Safari, but on Chrome, the single-line trick only works for the contenteditables that don't have plaintext-only. I will file a separate Chromium bug for that.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

We need to wait the decision of W3C which line breaker is "correct" behavior because it's really important difference in Gecko's implementation. If it's different from first implementation, we need to reimplement it again with other feature.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Here is a test case what .innerHTML returns.
https://jsfiddle.net/d_toybox/5pwo4sbr/2/

Comment 7

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

We should probably take this in theory, but I don't know if anyone actually wants to do it.  If anyone does it, they should follow the WebKit/Chrome behavior, since that's the original behavior, and ideally write a spec that reverse-engineers that behavior.  It could probably be put in the HTML spec if it needs a home.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, now ContentEditable spec said "The state "plaintext-only" is deprecated and its usage is discouraged".
https://w3c.github.io/editing/contentEditable.html#meaning-of-states

Comment 9

[張俊芝(ZHANG Junzhi)]

I didn't find anything that says plaintext-only for contenteditable is discouraged.

I only saw use of "true" is discouraged.

Comment 10

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Comment 11

[Kagami Rosylight [:saschanaz] (they/them)]

Note that plaintext-only is removed from the spec:

• https://github.com/w3c/contentEditable/commit/ae454fc84c784cd507a1e2f9a226d01f7ac519d4
• https://github.com/w3c/editing/issues/162#issuecomment-616210379

Comment 12

[張俊芝(ZHANG Junzhi)]

(In reply to Kagami :saschanaz from comment #11)

Note that plaintext-only is removed from the spec:

• https://github.com/w3c/contentEditable/commit/ae454fc84c784cd507a1e2f9a226d01f7ac519d4
• https://github.com/w3c/editing/issues/162#issuecomment-616210379

Does it mean this bug can be closed with WONTFIX?
Since beforeinput is standardised, the same effect of plaintext-only can be achieved via beforeinput.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to 張俊芝(ZHANG Junzhi) from comment #12)

Does it mean this bug can be closed with WONTFIX?

Depends on existing web apps. If web apps won't stop using the non-standardized API, we would need to implement it for Firefox users.
(The main issue of plaintext-only is, there are no agreement of what can be called as "plaintext" from point of innerHTML view.)

Since beforeinput is standardised, the same effect of plaintext-only can be achieved via beforeinput.

Well, sorry for the delay to implement beforeinput. I'm still struggling with setting proper target ranges at deletion. You can test our beforeinput event behavior on your own apps with setting dom.input_events.beforeinput.enabled to true in about:config.

Comment 14

[Howard Edwards [:howard-e]]

The following spec PRs specify the contenteditable="plaintext-only" which is supported in WebKit and Chromium:

• https://github.com/whatwg/html/pull/8275
• https://github.com/w3c/editing/pull/407

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Howard Edwards [:howard-e] from comment #14)

The following spec PRs specify the contenteditable="plaintext-only" which is supported in WebKit and Chromium:

• https://github.com/whatwg/html/pull/8275
• https://github.com/w3c/editing/pull/407

Unfortunately, the PRs do not standardize the behavior enough...

Comment 16

[Simon Pieters [:zcorpan]]

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

Unfortunately, the PRs do not standardize the behavior enough...

Other than line breaks (LF vs <br>), what should the spec for plaintext-only cover?

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I checked the behavior in Chrome roughly now, then, I see only the following commands work, so their definitions are required:

• Handling steps of Document.execCommand("insertParagraph") (Chrome/Safari handle this command differently from pressing Enter)
• Handling steps of Document.execCommand("insertLineBreak") (LF vs <br> (Chrome vs. Safari)
• Handling steps of the commands when caret is in special elements such as <li>
• Handling steps of Document.execCommand("insertText") (including line breaks causes insertParagraph in both, but I'm not sure it's intended since the behavior looks odd)
• Handling steps of Document.execCommand("insertHTML") (especially which elements need to be handled as line breaks)

And the other commands (except undo, redo and clipboard commands) should be defined as NOOP (including not deleting Selection).

Comment 19

[Dennis Schubert [:denschub]]

Bumping the priority a bit higher because we've now found more implementations that break (see the see-also's)

Comment 20

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Am I right in thinking that the open spec issue https://github.com/w3c/editing/issues/419 still blocks the implementation of this bug?

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yes and no. No standardized spec blocks us to implement this, and there are too few tests. Additionally, the examples in the issue may not all of what should be standardized.

Comment 22

[Simon Pieters [:zcorpan]]

Yeah I think we can plan to implement. The spec issue should be fixed but it seems relatively easy.

Comment 23

[Raul Bucata]

Verified this issue and still reproduces on Firefox Nightly for http://jsbin.com/kaladi/edit?html,output as the first input field does not accept input at all

Tested with:

Browser / Version: Firefox Nightly 128.0a1 (2024-05-29) (64-bit)
Operating System: Windows 10 PRO x64

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, I found ugly hack of Chrome. They use line feeds as line breakers in the plaintext-only mode. However, it requires some white-space property valuses to make them visible. Therefore, they forcibly replace the white-space value with corresponding value which makes line feeds visible.
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/resolver/style_adjuster.cc;l=343;drc=99d1b90e58c0aeaf0693f0652bfe1569c8663f95

It's hard to align to Chrome and it does not conform to any standards. So I think that we should use <br>s at least when line feeds are not visible.

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Emilio, I found user-modify: read-write-plaintext-only. Should we support this? And can we implement it only when a pref is enabled?

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, we need to add new pseudo-class here. https://searchfox.org/mozilla-central/rev/f2c181a7ab3bfea4d2266521e6eac713630479b3/dom/html/nsGenericHTMLElement.cpp#1318-1319

Comment 27

[Emilio Cobos Álvarez (:emilio)]

Why would you need a new pseudo-class? Other browsers don't (afaict) have a new pseudo-class for plaintext-only, they'd just match :read-write wouldn't they?

You'd map the read_only state of the contenteditable attribute to ReadWritePlaintextOnly here.

As for whether you can parse a value only when a pref is set, of course, though we'd need to move this code out of simple_keyword, then you'd be able to do something like this.

I can do the refactor for you, then you can add the new value and pref :)

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #27)

Why would you need a new pseudo-class?

Oh, I just thought that it's required for the consistency. If it's enough that contenteditable=plaintext-only causes :read-write, I don't think we should add the pseudo-class since adding it must make the contenteditable.css have complicated selectors.

Other browsers don't (afaict) have a new pseudo-class for plaintext-only, they'd just match :read-write wouldn't they?

I've not checked the other browsers' behavior. Indeed, it's important that whether they make the pseudo-class active or not.

You'd map the read_only state of the contenteditable attribute to ReadWritePlaintextOnly here.

Thanks. That's where I found.

As for whether you can parse a value only when a pref is set, of course, though we'd need to move this code out of simple_keyword, then you'd be able to do something like this.

I can do the refactor for you, then you can add the new value and pref :)

Thank you. If you think that it's required, I'll request you to do that. However, honestly, I'm not sure whether we really need to change the style system.

Comment 29

[Emilio Cobos Álvarez (:emilio)]

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

Thank you. If you think that it's required, I'll request you to do that. However, honestly, I'm not sure whether we really need to change the style system.

I think it might be useful for consistency with other browsers perhaps, but only if you think it's useful. I'm not sure what the behavior should be when switching from / to the plaintext mode from style. Seems weird.

Actually looking at -moz-user-modify, it might be worth removing that property altogether. In WebKit, it does cause the text to be editable (it is the thing that actually triggers "contenteditable" behavior. But we only check it in one caret-painting code-path?

Comment 30

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

As far as I've tested, Chrome does not work with :read-write-plaintext-only { color: red; } (querySelector too). So I think it's fine not to support it at least for now. So, let's keep current implementation as-is about the layout module.

Comment 31

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Link to jira https://mozilla-hub.atlassian.net/browse/FFXP-2459

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1291467 - Enable `contenteditable="plaintext-only"` in all channels r=m_kato!,#dom-core

Comment 33

[Sebastian Zartner [:sebo]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Allows authors to make elements editable but only allows to enter plain text.
[Affects Firefox for Android]: yes
[Suggested wording]: The value plaintext-only can now be specified for the contenteditable attribute, making the raw text of an element editable but without supporting rich text formatting.
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/90c80473729b
Enable `contenteditable="plaintext-only"` in all channels r=m_kato

Comment 35

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/90c80473729b

Comment 36

[Donal Meehan [:dmeehan]]

Added to the Fx136 nightly release notes, please allow 30 minutes for the site to update.
Keeping the relnote-firefox flag as ? to keep it on the radar for inclusion in the final Fx136 release notes.

Comment 37

[Dave Letorey]

Related issues and pull requests

• Firefox Release PR
• BCD PR