-
Notifications
You must be signed in to change notification settings - Fork 68
[FIX] composer: fix get/setText of the content editable helper #7394
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.
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
Closed
fw-bot
wants to merge
1
commit into
master
from
master-saas-18.4-fix-contenteditable-plaintext-only-behaviour-rar-474347-fw
Closed
[FIX] composer: fix get/setText of the content editable helper #7394
fw-bot
wants to merge
1
commit into
master
from
master-saas-18.4-fix-contenteditable-plaintext-only-behaviour-rar-474347-fw
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The recent use of the property "plaintext-only" came with a change of
behaviour in the composers, specifically in Firefox.
How to reproduce in FF:
- write a single character in a grid composer
- delete the character
-> a new line is inserted
Apparently, when setting the attribute `contentEditable` to
`plaintext-only`, deleting the single character does not delete the span
that encapsulates it if the latter has a class attribute. This couples
with a recent refactoring of the content editable helper to handle new
line characters and the empty composer is not detected as such
What happens currently?
Consider the composer content after inputing the letter 'W':
```html
<p>
<span class="">
w
</span>
</p>
```
The cursor is set just after the letter W.
In a chromium-based browser, hitting the `Delete` key yeilds the
following result:
```html
<p>
<span>
<br>
</span>
</p>
```
The letter is replaced by `<br>` which could be interpreted as a
newline, except that in this situation, we do not want a newline to
appear as we meerly deleted the single character of the composer, so
we do not want new characters.
Also, we introduced some logic to fight this side-effect when we
introduced the support of newlines of pasted content (#6467)
However, it turns out that in firefox, hitting `Delete` will yield this
result
```html
<p>
<span class="">
<br>
</span>
</p>
```
The class attribute is not cleared up! And unfortunately, the logic that
counteracts the presence of the unwelcome `<br>` would test against the
exact form seen in a chromium-based browser, so it did not work on
Firefox.
This commit extends the check to work on both Firefox-based and
Chromium-based browsers.
Note that other leads were investigated and it seems that if we stopped
using paragraphs to represent new lines, this issue with the `<br>`
doesn't seem to occur. An improvement (and good cleanup) could be
achieved by dropping that paragraph strategy and rely on spans and br
characters.
Task: 5082601
X-original-commit: 828ee0b
Collaborator
Collaborator
Author
|
@rrahir @LucasLefevre this PR targets master and is the last of the forward-port chain containing: To merge the full chain, use
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
Collaborator
|
robodoo r+
…On Fri, 31 Oct 2025, 16:31 Otis - Odoo Forward-Port Steward [bot], < ***@***.***> wrote:
*fw-bot* left a comment (odoo/o-spreadsheet#7394)
<#7394 (comment)>
@rrahir <https://github.com/rrahir> @LucasLefevre
<https://github.com/LucasLefevre> this PR targets master and is the last
of the forward-port chain containing:
- #7393 <#7393>
To merge the full chain, use
@robodoo <https://github.com/robodoo> r+
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port
—
Reply to this email directly, view it on GitHub
<#7394 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACO24XWLETRIWGBAJNRP7VT32N6FXAVCNFSM6AAAAACKZFM6HGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINZTGYYTANBQHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
robodoo
pushed a commit
that referenced
this pull request
Oct 31, 2025
The recent use of the property "plaintext-only" came with a change of
behaviour in the composers, specifically in Firefox.
How to reproduce in FF:
- write a single character in a grid composer
- delete the character
-> a new line is inserted
Apparently, when setting the attribute `contentEditable` to
`plaintext-only`, deleting the single character does not delete the span
that encapsulates it if the latter has a class attribute. This couples
with a recent refactoring of the content editable helper to handle new
line characters and the empty composer is not detected as such
What happens currently?
Consider the composer content after inputing the letter 'W':
```html
<p>
<span class="">
w
</span>
</p>
```
The cursor is set just after the letter W.
In a chromium-based browser, hitting the `Delete` key yeilds the
following result:
```html
<p>
<span>
<br>
</span>
</p>
```
The letter is replaced by `<br>` which could be interpreted as a
newline, except that in this situation, we do not want a newline to
appear as we meerly deleted the single character of the composer, so
we do not want new characters.
Also, we introduced some logic to fight this side-effect when we
introduced the support of newlines of pasted content (#6467)
However, it turns out that in firefox, hitting `Delete` will yield this
result
```html
<p>
<span class="">
<br>
</span>
</p>
```
The class attribute is not cleared up! And unfortunately, the logic that
counteracts the presence of the unwelcome `<br>` would test against the
exact form seen in a chromium-based browser, so it did not work on
Firefox.
This commit extends the check to work on both Firefox-based and
Chromium-based browsers.
Note that other leads were investigated and it seems that if we stopped
using paragraphs to represent new lines, this issue with the `<br>`
doesn't seem to occur. An improvement (and good cleanup) could be
achieved by dropping that paragraph strategy and rely on spans and br
characters.
closes #7394
Task: 5082601
X-original-commit: 828ee0b
Signed-off-by: Lucas Lefèvre (lul) <[email protected]>
Signed-off-by: Rémi Rahir (rar) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.

The recent use of the property "plaintext-only" came with a change of
behaviour in the composers, specifically in Firefox.
How to reproduce in FF:
-> a new line is inserted
Apparently, when setting the attribute
contentEditabletoplaintext-only, deleting the single character does not delete the spanthat encapsulates it if the latter has a class attribute. This couples
with a recent refactoring of the content editable helper to handle new
line characters and the empty composer is not detected as such
What happens currently?
Consider the composer content after inputing the letter 'W':
The cursor is set just after the letter W.
In a chromium-based browser, hitting the
Deletekey yeilds thefollowing result:
The letter is replaced by
<br>which could be interpreted as anewline, except that in this situation, we do not want a newline to
appear as we meerly deleted the single character of the composer, so
we do not want new characters.
Also, we introduced some logic to fight this side-effect when we
introduced the support of newlines of pasted content (#6467)
However, it turns out that in firefox, hitting
Deletewill yield thisresult
The class attribute is not cleared up! And unfortunately, the logic that
counteracts the presence of the unwelcome
<br>would test against theexact form seen in a chromium-based browser, so it did not work on
Firefox.
This commit extends the check to work on both Firefox-based and
Chromium-based browsers.
Note that other leads were investigated and it seems that if we stopped
using paragraphs to represent new lines, this issue with the
<br>doesn't seem to occur. An improvement (and good cleanup) could be
achieved by dropping that paragraph strategy and rely on spans and br
characters.
Task: 5082601
Task: 5082601
Description:
description of this task, what is implemented and why it is implemented that way.
Task: 5082601
review checklist
Forward-Port-Of: #7331