Caret not shown when setting document.designMode = 'on' in a keyboard event listener
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox91 | --- | fixed |
People
(Reporter: danny0838, Assigned: masayuki)
References
Details
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Steps to reproduce:
- Visit the attached test-bug-designmode-caret1.html
- Click on the "design" button.
- Click on anywhere in the document (such as the "paragraph 1").
Actual results:
A blinking caret should show at the clicked point.
Expected results:
No caret is shown.
Sorry, I have input the actual and expected results reversely: the actual result is no caret shown, while the expected result is a blinking caret.
This will still happen even if the setting document.designMode inside a timer:
<!DOCTYPE html>
<p>paragraph 1</p>
<button type="button">design</button>
<script>
document.querySelector('button').addEventListener('click', () => {
setTimeout(() => {
document.designMode = 'on';
}, 0);
});
</script>
This doesn't seem to happen if setting document.designMode in the main thread:
<!DOCTYPE html>
<p>paragraph 1</p>
<script>
setTimeout(() => {
document.designMode = 'on';
}, 3000);
</script>
Comment on attachment 9224460 [details]
test-bug-designmode-caret2.html
This will still happen even if the setting document.designMode inside a timer.
This doesn't seem to happen if setting document.designMode in the main thread.
|
||
Comment 7•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
In the cases that the caret is not shown. Unfocusing and refocusing the tab (window) will get the caret show again.
|
||
Updated•3 years ago
|
|
|
||
Comment 9•3 years ago
|
||
Setting severity to S3, because workarounds exist and this feature is presumably not used by many users. Would be nice to fix it, though.
|
|
||
Updated•3 years ago
|
|
Reporter | |
Comment 10•3 years ago
|
||
(In reply to Mirko Brodesser (:mbrodesser) from comment #9)
Setting severity to S3, because workarounds exist and this feature is presumably not used by many users. Would be nice to fix it, though.
What workaround?
|
|
||
Comment 11•3 years ago
•
|
||
(In reply to Danny Lin from comment #10)
(In reply to Mirko Brodesser (:mbrodesser) from comment #9)
Setting severity to S3, because workarounds exist and this feature is presumably not used by many users. Would be nice to fix it, though.
What workaround?
The one mentioned in #c8. Which can be achieved for instance by switching tabs back and forth. It's quite unsatisfying, though.
I presume designMode = "on" is used rarely by end-users, therefore S3 still seems reasonable.
Danny: if you have a convincing use case we can increase the severity.
|
|
Reporter | |
Comment 12•3 years ago
|
||
Setting document.designMode = 'on' is similar to setting document.documentElement.contentEditable = true, but the latter doesn't have the same caret issue, there must be something wrong for the former.
We are developing an extension that supports document content editing, while need to avoid changing the original DOM content, so contentEditable is less preferable. I think there may be similar cases that designMode is preferable when the developer wants to avoid changing the DOM content of the original document, e.g. when developing a bookmarklet.
|
Assignee | |
Comment 13•3 years ago
|
||
(In reply to Danny Lin from comment #8)
In the cases that the caret is not shown. Unfocusing and refocusing the tab (window) will get the caret show again.
Well, then, window.blur() and window.focus() might be a workaround from point of view of the developers.
I guess that this is caused by a default action handler in ESM or something resets focus state after HTMLEditor handles it.
|
|
Reporter | |
Comment 14•3 years ago
|
||
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #13)
(In reply to Danny Lin from comment #8)
In the cases that the caret is not shown. Unfocusing and refocusing the tab (window) will get the caret show again.
Well, then,
window.blur()andwindow.focus()might be a workaround from point of view of the developers.I guess that this is caused by a default action handler in
ESMor something resets focus state afterHTMLEditorhandles it.
Unfortunately it doesn't work...
Adding something like:
window.blur();
window.focus();
or:
document.activeElement.blur();
document.activeElement.focus();
or with a timer:
setTimeout(() => {
window.blur();
window.focus();
}, 2000);
after setting designMode = 'on' don't work.
|
|
Assignee | |
Comment 15•3 years ago
|
||
Ah, no. This is a simple editor module's bug.
|
|
Assignee | |
Comment 16•3 years ago
•
|
||
(In reply to Danny Lin from comment #14)
(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #13)
I guess that this is caused by a default action handler in
ESMor something resets focus state afterHTMLEditorhandles it.Unfortunately it doesn't work...
Sorry for that. I have a simple fix. So, It'd be fixed in 91.
|
|
Assignee | |
Comment 17•3 years ago
|
||
While initializing HTMLEditor for designMode, blur event for the
previously focused element will be fired after HTMLEditor initialization
because of the script blocker in Document::EditingStateChanged():
https://searchfox.org/mozilla-central/rev/c0f286b1f541c675bbe052b21bdefa80d150ec35/dom/base/Document.cpp#5878,5891,5923
This causes EditorEventListener::Blur() calling
EditorBase::FinalizeSelection() to make the editor stop handling selection.
Therefore, if the design mode is turned on from an event listener run by a
user operation cannot make the caret visible.
This patch makes the Blur() ignore blur events whose target is element
in the design mode since the target of blur events should be handled in the
design mode is always the DOM window or the document node.
|
||
Comment 18•3 years ago
|
||
|
||
Comment 19•3 years ago
|
||
| bugherder | ||
Description
•