The other day I described how forms and form inputs work in WebKit. So today I’d like to discuss how text editting for “text”/etc <input>s, <textarea>s, and the “contenteditable” attribute is implemented.
This “Editor” is associated with a given <frame>, and the frame’s “EventHandler” will send it keyboard events that aren’t otherwise handled. I will start my tour from that Editor class.
Those keyboard events are then forwarded to the platform-specific EditorClient, which for WebKitGTK has already been handled outside of the sandbox for the commands to be forwarded to the Editor out-of-band.
The Editor will then process those into an undo/redo stack, whose objects will then manipulate the DOM via some abstractions provided by their super-class CompositeEditCommand and/or a suite of functions.
These undo/redo operations are based heavily on what text is selected, so where does that selection come from?
I’ve mentioned before that drag and drop gestures fallback to being interpreted as a text selection, iterating over the hovered text in order to find the exact start and points.
Or keyboard input is routed to the FrameSelection object, which’ll manipulate it’s VisibleSelection object and handle cursor rendering. Which’ll then handle enforcing editing boundaries and telling the render tree where to render the text selection in it’s own rendering pass.