462735 - Setting contentEditable=false inside a document with designMode='on' fails

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P5)

Description

[Alfonso Martinez]

Attachment: testcase

According to http://www.w3.org/html/wg/html5/#contenteditable if an element has contentEditable=false then it should not be editable, even if the rest of the document has designMode='on'.

This testcase proves that Firefox, Safari and Opera fail to disable the editing in such situation.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The designMode isn't same as contenteditable="true" on root element. designMode property of the *document* makes all contents editable. You can think that desingMode emulates HTML editor, contenteditable attribute makes a part of static document editable.

# I think that the spec should explain more.

Comment 2

[Alfonso Martinez]

The steps detailed in the spec states that given that condition the element shouldn't be editable, and it explains how to handle both contentEditable and designMode. It clearly states that if an element is marked as contentEditable=false then the user shouldn't be able to edit it, no matter if the surrounding content is made editable due to setting in a higher node contentEditable = true or designMode = true in the document.

Without this feature it's not possible to create non-editable blocks in a document with designMode, so in the end it means that it isn't useful to use designMode at all because people sometimes want the ability to mark some sentence/word/html as block that it's a single entity that can't be edited in the normal way, and the solution for those situations is to use contentEditable=false.

Until the spec is changed to remove this sentence this is a bug. 
"or if it and its ancestors all have their contenteditable  attribute set to the inherit state but the Document  has designMode  enabled, then the UA must treat the element as editable (as described below)."

Comment 3

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.

Comment 4

[Leo Tenenbaum [:ltenenbaum]]

Attachment: Bug 462735 - Respect contenteditable=false in design mode document. r=masayuki

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/bf0c9c56445e
https://hg.mozilla.org/integration/autoland/rev/0f0bb7232161
Respect contenteditable=false in design mode document. r=masayuki

Comment 6

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/58912 for changes under testing/web-platform/tests

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8f624c8dead8
https://hg.mozilla.org/integration/autoland/rev/36954367884c
Revert "Bug 462735 - Respect contenteditable=false in design mode document. r=masayuki" for causing ba failures at browser_caching_states.js

Comment 8

[rperta]

Backed out for causing ba failures at browser_caching_states.js
Backout link
Push with failures
Failure log(s)

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4f45c623ee6e
https://hg.mozilla.org/integration/autoland/rev/06e778e00fe4
Respect contenteditable=false in design mode document. r=masayuki

Comment 11

[amarc]

https://hg.mozilla.org/mozilla-central/rev/06e778e00fe4