can no longer type over some selections in unknown contenteditable element
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | unaffected |
firefox93 | --- | wontfix |
firefox94 | --- | wontfix |
firefox95 | --- | verified |
firefox96 | --- | verified |
People
(Reporter: stef.busking, Assigned: masayuki)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0
Steps to reproduce:
Minimal repro at https://codepen.io/Bwrrp/pen/ExvYLwZ and in attachment.
- Place cursor at the end of the text, after the .
- Press shift-home to select the entire line
- Type a letter
Actual results:
In Firefox 92 and earlier, the selection is deleted and replaced with the typed letter. Starting from Firefox 93, nothing happens.
When using the Japanese IME built into Windows 10 set to Hiragana, composition does start, but the selected text is still not removed and the initial composition text is not visible. The IME window is sometimes positioned in an unexpected place, overlapping the text. Continuing to type into the IME in this way finally ends up prepending text rather than overtyping the selection. Again, this did work correctly in Firefox 92 and earlier.
Expected results:
Expected typing to immediately replace the selected text, whether composition is used or not.
Replacing the custom-element
tag with a div
makes this work as expected. If the contenteditable element only contains text, this also works. The combination of the unknown element and the nested inline seems to cause this to break.
No js is involved. The CSS in the repro case only serves to make placing the cursor easier, the unexpected behavior also occurs if this is removed and custom-element
defaults to being inline.
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Mozregression says that this is a regression from Bug 1726064
Assignee | ||
Comment 3•3 years ago
|
||
Hmm, editor may not be able to refer the latest layout information, it means that editor can/should not refer CSS display
value. Therefore, the unknown element is treated as inline and it's handled as error. I think that the caller's check (in PrepareToDeleteNonCollapsedRanges()
) should be changed.
Comment 4•3 years ago
|
||
Set release status flags based on info from the regressing bug 1726064
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
Currently, it assumes that first range is always in editable block parent,
but if the range is in an inline editing host, it's not true.
The given ranges should always be in same editing host at this time because of:
- https://searchfox.org/mozilla-central/rev/011ed92913b38e950977ab3fc56ae68a8f3bca12/editor/libeditor/HTMLEditorDeleteHandler.cpp#1031,1064
- https://searchfox.org/mozilla-central/rev/011ed92913b38e950977ab3fc56ae68a8f3bca12/editor/libeditor/HTMLEditorDeleteHandler.cpp#1080,1117
Therefore, it's enough to check whether the range crosses or not editing host
boundaries only with MOZ_ASSERT(_IF)
.
Comment 8•3 years ago
|
||
bugherder |
Comment 10•3 years ago
|
||
The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 11•3 years ago
|
||
This was not reported immediately. So I think that there is no web apps which hit this bug. And I'm afraid to uplift the patch to beta because the changed path is used in other cases too.
Reporter | ||
Comment 12•3 years ago
|
||
This is actually affecting the Fonto Editor (see for instance https://trial.fontoxml.com/), which makes heavy use of custom elements both inside and outside of contenteditable.
Assignee | ||
Comment 13•3 years ago
|
||
(In reply to stef.busking from comment #12)
This is actually affecting the Fonto Editor (see for instance https://trial.fontoxml.com/), which makes heavy use of custom elements both inside and outside of contenteditable.
Indeed, this bug causes sometimes cannot edit the text when I move caret with outline of the right side-bar.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 14•3 years ago
|
||
Comment on attachment 9248837 [details]
Bug 1737540 - Make AutoBlockElementsJoiner::PrepareToDeleteNonCollapsedRanges()
consider to delete given range when there is no editable block parent r=m_kato!
Beta/Release Uplift Approval Request
- User impact if declined: Fonto Editor (see for instance https://trial.fontoxml.com/) is not usable in some cases. I confirmed that when I move caret from outline of the right side bar, and type something, then select some characters, I cannot type text to replace the non-collapsed selection.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): The changed path runs when deletion in the other patterns because it considers which path should be used to delete under each situation. But the change is simple and I believe that it's reasonable.
- String changes made/needed: None
Assignee | ||
Comment 15•3 years ago
|
||
It seems that this fixes bug 1740492 too. If so, this is more important than I've expected.
Comment 16•3 years ago
|
||
Comment on attachment 9248837 [details]
Bug 1737540 - Make AutoBlockElementsJoiner::PrepareToDeleteNonCollapsedRanges()
consider to delete given range when there is no editable block parent r=m_kato!
Approved for 95.0b6
Comment 17•3 years ago
|
||
bugherder uplift |
Updated•3 years ago
|
Updated•3 years ago
|
Comment 18•3 years ago
|
||
Was able to reproduce the issue on macOS 10.15 under 95.0a1 (2021-10-25) by following the info provided in Comment 0.
The issue is fixed on Firefox 95.0b6 and Firefox 96.0a1 (2021-11-11). Tests were performed on macOS 10.15, Windows 10 and Ubuntu 20.04.
Description
•