`contenteditable` does not work with elements outside `<body>`, e.g., `<title>`
Categories
(Core :: DOM: Editor, defect, P3)
Tracking
()
People
(Reporter: sergeykish, Unassigned)
References
(Depends on 3 open bugs, Blocks 4 open bugs)
Details
(Keywords: parity-chrome, Whiteboard: [h2review-noted])
Attachments
(3 files, 1 obsolete file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Steps to reproduce:
I've displayed <head><title> with head, title { display: block }
And tried to edit title
Actual results:
title unchanged
text appended to <body>
Expected results:
title should have changed
(works in chrome)
|
||
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Hmm, contenteditable does indeed behave oddly here.
|
||
Comment 3•5 years ago
|
||
Well, HTMLEditor restricts editable content only under <body>. So, for allowing this, we need to fix a lot of places. Without that and we just allow to edit only in this case, probably, we will get various bug reports for similar issues.
|
Reporter | |
Comment 4•5 years ago
|
||
Yes, behaviour is not limited to <title> - same on <style> and <script>.
This sample better reflects my usage - authoring in browser, PUT entire document to server.
|
|
Reporter | |
Comment 5•5 years ago
|
||
Interestingly if applied on <head> it works.
Even if <body> is contenteditable as well.
So it is only about <html contenteditable> / designMode = 'on' application.
|
|
Reporter | |
Comment 6•5 years ago
|
||
designMode has same problem as <html contenteditable>.
Del removes both <h1> tag and first letter.
I believe I saw it removed only first letter.
Can't reproduce.
|
|
Reporter | |
Comment 7•5 years ago
|
||
Oh, usually Del on the end of a tag removes next tag and appends its content.
In Opera <body> is not removed (both in HTML and XHTML documents).
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Updated•4 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•2 years ago
|
|
||
Comment 8•2 years ago
|
||
(Pardon quick question; hope this is right place for asking.)
Why it is not possible to delete text from <title contenteditable>, while it is possible to append it there?
Currently there is quite this weird state WRT <title contenteditable>: it works -- you can write there, changes are even mapped to DOM and reflected in document.title (so it effectively "renames tab") -- but it is only possible to insert text there, not delete.
Simple test:
data:text/html,<!doctype html><head style="display:block"><title style="display:block" contenteditable>TITLE: Write OK, delete not(?)</title>
This test works in all modern browsers, only Firefox does not allow to remove characters. (Tested for example in Firefox 106.0.5 20221104133228). The "works" test in this issue suggests it might have worked in the past. So is it some regression, or is it being implemented but not ready?
|
|
||
Comment 9•2 years ago
•
|
||
Why don't you read comment 3?
We don't want to create invalid DOM tree with builtin editor due to invalid structure causes other issues. How do you think that what should happen if user types Enter or Shift-Enter in <title contenteditable>, especially when its white-space is not pre-*? <title> element must not have any other elements including <br>. This kind of issues should be agreed between browser vendors, but the other browser vendors do not want to work on around this issue because of less important than the other (new) features. Therefore, we also do not work on around this unless there is broken web apps caused by this (the reason why only insertText is available outside <body> is this, an odd editor library used <div> outside <body> as a placeholder of paste).
Note that before we limited editable region in <body>, some useless bug reports came. There must be a crazy number of edge cases in editing feature, but most of them are not important for usual web apps. Therefore, we temporarily disabled the ability to edit outside <body> for concentrating to more important compatible issues.
I have a question to you. How do you want to use editable <title> element? If it's reasonable, I'd notify the editing working group of the use case.
|
|
||
Comment 10•2 years ago
|
||
Oh, sorry, I misunderstood that comment as "we are not supporting [contenteditable outside body] at all", what contradicted my observation.
As for my use-case: I have one concrete one, mostly explorative. Since I rarely have browser tabs wide enough to see whole title, I've made a whimsical global userstyle [1] that makes title element visible in each page (and as a result even frame), resembling "status-bar bubble", with mechanism allowing to get it out the way and bring it back on demand. That works well for me and I really got used to it. After a while I realized that with simple userscript [2] I could make it editable, what would have nice benefits:
- Introduced (ephemeral) "tab rename" feature, what comes in handy from time to time.
- Allowed me to edit bookmark title before drag-dropping URL into bookmarks toolbar, what saves several clicks compared to other means. (Sure, similar outcome could be equally achieved with even simpler bookmarklet, but its UX would not match the "WYSIWYG" nature of editable title.)
[1] https://userstyles.world/style/5119/display-title-as-status
[2] https://greasyfork.org/en/scripts/454707-editable-title/code
|
|
||
Comment 11•2 years ago
|
||
(In reply to Michal Čaplygin [:myf] from comment #10)
After a while I realized that with simple userscript [2]
I think that you should create new <input> and do:
theInputElement.addEventListener("input", event => document.title = event.target.value);
instead of making the <title> dirctly editable for the purpose because only one builtin HTML editor is created per Document and undo/redo stack is shared by all editable elements except <input> and <textarea>. Therefore, your approach may cause data loss especially in editable elements created by the web page when you unexpectedly undo a lot. And note that creating HTML editor instance is not cheap and it keeps staying until last editable element is removed. Therefore, from performance point of view, it's not good approach.
Description
•