Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify whether dataTransfer may have text/html when pasting rich text into contenteditable=plaintext-only #162

Open
masayuki-nakano opened this issue Sep 25, 2024 · 3 comments
Open

Clarify whether dataTransfer may have text/html when pasting rich text into contenteditable=plaintext-only #162

masayuki-nakano opened this issue Sep 25, 2024 · 3 comments
Labels
Agenda+ Queue this item for discussion at the next WG meeting level 3 Needs to be resolved for level 3

Comments

@masayuki-nakano
Copy link

According to Input Events Level 2, beforeinput of insertFromPaste should have data as null and dataTransfer when contenteditable. However, it's unclear that whether the dataTransfer should or should not have text/html when the user pasts into contenteditable=plaintext-only.

From point of view of web apps, if dataTransfer has text/html as same as contenteditable=true, they can serialize the HTML to plaintext by themselves to avoid dependency of browser/OS.

On the other hand, inputType does not have insertFromPaste for "Paste without format" (Ctrl + V on Firefox/Chrome for Windows). Therefore, web apps cannot distinguish whether the user pasting with or without format.

Perhaps, there should be new inputType value and dataTransfer may have text/html data even when pasting without format.
@johanneswilm johanneswilm added the Agenda+ Queue this item for discussion at the next WG meeting label Sep 25, 2024
@johanneswilm johanneswilm mentioned this issue Sep 25, 2024
Open
@masayuki-nakano
Copy link
Author

On the other hand, inputType does not have insertFromPaste for "Paste without format" (Ctrl + V on Firefox/Chrome for Windows). Therefore, web apps cannot distinguish whether the user pasting with or without format.

I meant in the case of contenteditable=true. E.g., Ctrl-V vs. Ctrl-Shift-V.

@smaug----
Copy link

On linux/Firefox when pasting with ctrl+shift+v I seem to get only plain/text, not text/html
https://mozilla.pettay.fi/moztests/paste_contenteditable.html

And Chrome doesn't seem to get access to .dataTransfer ever when inputType is insertFromPaste.

moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Oct 2, 2024
@masayuki-nakano @moz-wptsync-bot
part 1: Make HTMLEditor paste/drop things as plaintext when `conten…
189c86b 
…teditable=plaintext-only

Chrome sets `beforeinput.data` instead of `beforeinput.dataTransfer`, but
Input Events Level 2 spec defines that browsers should set `dataTransfer` when
**contenteditable** [1].  Therefore, the new WPT expects `dataTransfer`.

However, it's unclear that the `dataTransfer` should have `text/html` or only
`text/plain`.  From web apps point of view, `text/html` data may make them
serialize the rich text format to plaintext without any dependencies of browsers
and OS.  On the other hand, they cannot distinguish whether the user tries to
paste with or without formatting when `contenteditable=true`.  Therefore, I
filed a spec issue for this.  We need to be back later about this issue.

1. https://w3c.github.io/input-events/#overview
2. w3c/input-events#162

Differential Revision: https://phabricator.services.mozilla.com/D223908

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1920646
gecko-commit: 2e3f866560e2c750fe1e4469b81d89f10bffc6a1
gecko-reviewers: m_kato
@moz-wptsync-bot moz-wptsync-bot mentioned this issue Oct 2, 2024
Merged
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Oct 3, 2024
@masayuki-nakano
Bug 1920646 - part 1: Make HTMLEditor paste/drop things as plaintex…
7e9bbe2 
…t when `contenteditable=plaintext-only` r=m_kato

Chrome sets `beforeinput.data` instead of `beforeinput.dataTransfer`, but
Input Events Level 2 spec defines that browsers should set `dataTransfer` when
**contenteditable** [1].  Therefore, the new WPT expects `dataTransfer`.

However, it's unclear that the `dataTransfer` should have `text/html` or only
`text/plain`.  From web apps point of view, `text/html` data may make them
serialize the rich text format to plaintext without any dependencies of browsers
and OS.  On the other hand, they cannot distinguish whether the user tries to
paste with or without formatting when `contenteditable=true`.  Therefore, I
filed a spec issue for this.  We need to be back later about this issue.

1. https://w3c.github.io/input-events/#overview
2. w3c/input-events#162

Differential Revision: https://phabricator.services.mozilla.com/D223908
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Oct 3, 2024
@masayuki-nakano @moz-wptsync-bot
part 1: Make HTMLEditor paste/drop things as plaintext when `conten…
e0e8311 
…teditable=plaintext-only

Chrome sets `beforeinput.data` instead of `beforeinput.dataTransfer`, but
Input Events Level 2 spec defines that browsers should set `dataTransfer` when
**contenteditable** [1].  Therefore, the new WPT expects `dataTransfer`.

However, it's unclear that the `dataTransfer` should have `text/html` or only
`text/plain`.  From web apps point of view, `text/html` data may make them
serialize the rich text format to plaintext without any dependencies of browsers
and OS.  On the other hand, they cannot distinguish whether the user tries to
paste with or without formatting when `contenteditable=true`.  Therefore, I
filed a spec issue for this.  We need to be back later about this issue.

1. https://w3c.github.io/input-events/#overview
2. w3c/input-events#162

Differential Revision: https://phabricator.services.mozilla.com/D223908

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1920646
gecko-commit: 2e3f866560e2c750fe1e4469b81d89f10bffc6a1
gecko-reviewers: m_kato
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Oct 3, 2024
@masayuki-nakano
Bug 1920646 - part 1: Make HTMLEditor paste/drop things as plaintex…
cd9b90d 
…t when `contenteditable=plaintext-only` r=m_kato

Chrome sets `beforeinput.data` instead of `beforeinput.dataTransfer`, but
Input Events Level 2 spec defines that browsers should set `dataTransfer` when
**contenteditable** [1].  Therefore, the new WPT expects `dataTransfer`.

However, it's unclear that the `dataTransfer` should have `text/html` or only
`text/plain`.  From web apps point of view, `text/html` data may make them
serialize the rich text format to plaintext without any dependencies of browsers
and OS.  On the other hand, they cannot distinguish whether the user tries to
paste with or without formatting when `contenteditable=true`.  Therefore, I
filed a spec issue for this.  We need to be back later about this issue.

1. https://w3c.github.io/input-events/#overview
2. w3c/input-events#162

Differential Revision: https://phabricator.services.mozilla.com/D223908
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this issue Oct 6, 2024
@masayuki-nakano
Bug 1920646 - part 1: Make HTMLEditor paste/drop things as plaintex…
36901d5 
…t when `contenteditable=plaintext-only` r=m_kato

Chrome sets `beforeinput.data` instead of `beforeinput.dataTransfer`, but
Input Events Level 2 spec defines that browsers should set `dataTransfer` when
**contenteditable** [1].  Therefore, the new WPT expects `dataTransfer`.

However, it's unclear that the `dataTransfer` should have `text/html` or only
`text/plain`.  From web apps point of view, `text/html` data may make them
serialize the rich text format to plaintext without any dependencies of browsers
and OS.  On the other hand, they cannot distinguish whether the user tries to
paste with or without formatting when `contenteditable=true`.  Therefore, I
filed a spec issue for this.  We need to be back later about this issue.

1. https://w3c.github.io/input-events/#overview
2. w3c/input-events#162

Differential Revision: https://phabricator.services.mozilla.com/D223908
@johanneswilm
Copy link
Contributor

From TPAC 2024 minutes:

w3c/input-events#162

Sanket: Sounds fine to give access to HTMl when pasting even in plaintext.

Dan: How about input?

Johannes: We prefixed all the types of inputTypes to make it possible for an old editor to handle new input types with the same prefix.

Sanket/Ryosuke: We could add another attribute that would not cause the same web compat issues.
https://w3c.github.io/uievents/#idl-inputeventinit

Dan: Another option is to only deliver plaintext.

Dan: If we can do whatever, we can add new input type. But webcompat is an issue.

Johannes: second best is attribute. Where could that live.

Sanket: we could put it into the init where isComposing lives.

Olli: Maybe put it in the data transfer?

(Olli: what is the order in DataTransferItemList? Could ctrl+shift+v put text/plain first?
https://mozilla.pettay.fi/moztests/paste_contenteditable.html Firefox gives only text/plain when doing ctrl+shift+v. text/html is there without ‘shift’. Chrome doesn’t have .dataTransfer with insertFromPaste ? Tested on linux. The test is about normal contenteditable, not plaintext-only)

gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Oct 9, 2024
@marco-c
Bug 1920646 - part 1: Make HTMLEditor paste/drop things as plaintex…
4d939db 
…t when `contenteditable=plaintext-only` r=m_kato

Chrome sets `beforeinput.data` instead of `beforeinput.dataTransfer`, but
Input Events Level 2 spec defines that browsers should set `dataTransfer` when
**contenteditable** [1].  Therefore, the new WPT expects `dataTransfer`.

However, it's unclear that the `dataTransfer` should have `text/html` or only
`text/plain`.  From web apps point of view, `text/html` data may make them
serialize the rich text format to plaintext without any dependencies of browsers
and OS.  On the other hand, they cannot distinguish whether the user tries to
paste with or without formatting when `contenteditable=true`.  Therefore, I
filed a spec issue for this.  We need to be back later about this issue.

1. https://w3c.github.io/input-events/#overview
2. w3c/input-events#162

Differential Revision: https://phabricator.services.mozilla.com/D223908

UltraBlame original commit: 2e3f866560e2c750fe1e4469b81d89f10bffc6a1
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Oct 9, 2024
@marco-c
Bug 1920646 - part 1: Make HTMLEditor paste/drop things as plaintex…
8e00c94 
…t when `contenteditable=plaintext-only` r=m_kato

Chrome sets `beforeinput.data` instead of `beforeinput.dataTransfer`, but
Input Events Level 2 spec defines that browsers should set `dataTransfer` when
**contenteditable** [1].  Therefore, the new WPT expects `dataTransfer`.

However, it's unclear that the `dataTransfer` should have `text/html` or only
`text/plain`.  From web apps point of view, `text/html` data may make them
serialize the rich text format to plaintext without any dependencies of browsers
and OS.  On the other hand, they cannot distinguish whether the user tries to
paste with or without formatting when `contenteditable=true`.  Therefore, I
filed a spec issue for this.  We need to be back later about this issue.

1. https://w3c.github.io/input-events/#overview
2. w3c/input-events#162

Differential Revision: https://phabricator.services.mozilla.com/D223908

UltraBlame original commit: 2e3f866560e2c750fe1e4469b81d89f10bffc6a1
@johanneswilm johanneswilm added the level 3 Needs to be resolved for level 3 label Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Agenda+ Queue this item for discussion at the next WG meeting level 3 Needs to be resolved for level 3
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@johanneswilm @masayuki-nakano @smaug----