Roadmap:

1. Declare all existing functions that check editability as deprecated. The criteria are that they are:
(i) Either functions defined in EditingUtilities.h with word "Editable" in function names, which are:
 - hasEditableStyle
 - hasRichlyEditableStyle
 - isRootEditableElement
 - rootEditableElement
 - rootEditableElementOf (all three overloads)
 - highestEditableRoot (both overloads)
 - firstEditablePositionAfterPositionInRoot (both overloads)
 - lastEditablePositionAfterPositionInRoot (both overloads)
 - isEditablePosition (both overloads)
 - isRichlyEditablePosition
 - firstEditableVisiblePositionAfterPositionInRoot (both overloads)
 - lastEditableVisiblePositionBeforePositionInRoot (both overloads)

(ii) Or functions outside EditingUtilities.h whose names coincide with a function in (i), which are:
 - SelectionEditable::hasEditableStyle
 - VisibleSelectionTemplate::hasEditableStyle
 - VisibleSelectionTemplate::rootEditableElement
 - FrameSelection::hasEditableStyle
 - FrameSelection::rootEditableElement
 - static function hasEditableStyle in VisibleUnits.cpp
 - static function rootEditableElement in VisibleUnits.cpp
 - static function highestEditableRoot in VisibleUnits.cpp
 - SpellCheckRequest::rootEditableElement

We will land a mechanical patch that appends "Deprecated" to the name of all the functions listed above.

2. For each deprecated function, do either of the following:
- If it already has DCHECKs for clean style, remove "Deprecated" from its name;
- Otherwise:
 - Introduce a proper version that DCHECKs clean style
 - Add a Document::updateStyleAndLayoutTree call to the beginning of the deprecated function

3. For each remaining deprecated function, hoist the Document::updateStyleAndLayoutTree call to proper places in the code paths, and prune the deprecated function with the proper version.

isEditablePosition seems tricky to handle. It can be entered during style recalculation, as shown in the stack trace below:

isEditablePosition()
VisibleSelectionTemplate<>::isContentEditable()
FrameSelection::hasEditableStyle()
LayoutBlock::hasCursorCaret()
LayoutBlock::hasCaret()
LayoutObject::adjustStyleDifference()
LayoutObject::setStyle()

The following layout tests have this pattern:

fast/forms/search/search-disabled-readonly.html
fast/forms/search/input-search-press-escape-key.html
fast/forms/number/number-wheel-event.html
fast/forms/number/number-keyoperation.html
fast/forms/autofilled.html

Renaming and back functions that has DCHECK looks redundant. 

For functions that doesn't have DCHECK, 
 1. Rename to "deperecated"
 2. Define functions that have DCHECK of deprecated ones.
 3. Replacing 1 with 2 appending Document::updateStyleAndLayoutTree
Right?

#3. Yes, isEditablePosition in style recalc is a cancer of this cleaning.
Do you have plan?

For the roadmap, let's refine the list of functions to be deprecated as follows:

(i) Functions defined in EditingUtilities.h, have word "Editable" in names but do not DCHECK clean style:
 - hasEditableStyle
 - hasRichlyEditableStyle
 - isRootEditableElement
 - rootEditableElement
 - rootEditableElementOf (all three overloads)
 - highestEditableRoot (both overloads)
 - isRichlyEditablePosition

(ii) Or functions outside EditingUtilities.h whose names coincide with a function in (i), which are:
 - SelectionEditable::hasEditableStyle
 - VisibleSelectionTemplate::hasEditableStyle
 - VisibleSelectionTemplate::rootEditableElement
 - FrameSelection::hasEditableStyle
 - FrameSelection::rootEditableElement
 - static function hasEditableStyle in VisibleUnits.cpp
 - static function rootEditableElement in VisibleUnits.cpp
 - static function highestEditableRoot in VisibleUnits.cpp
 - SpellCheckRequest::rootEditableElement


For the issue with isEditablePosition, we should stop LayoutObject::adjustStyleDifference from checking LayoutBlock::hasCaret. The reason of the call is to invalidate caret when text color changed. We should move the logic to paint invalidation. yosin@'s http://crrev.com/1958093002 contains a prototype of this change.

I'll isolate and land the relevant parts. The fixing doesn't seem to have conflict with the first two steps of the roadmap, though. We can do it in parallel.

There seems to be more blockers... Investigating...

All blockers are identified, and the conversion process is clear:

https://docs.google.com/document/d/1BHqhZQnCDBexNYzg_GethMmm4NqZKVj_eLpNZMPXMzg/edit?usp=sharing

We have another option that put |hasEditableStyle()| as is, since nobody complain about unreliability, and start deprecating "webkit-user-modify" CSS property, since it is not standard.

Once "webkit-user-modify", editaiblity is defined by INPUT/TEXTAREA's readonly attribute and contentEditable attribute. Both of them are independent from style system.

Should we close this issue (and related ones) in favor of the deprecation and removal of -webkit-user-modify?

WontFix as we are going to deprecate -webkit-use-modify instead.