If webView:shouldDeleteDOMRange: replies NO, WebCore/editing/TypingCommand.cpp still performs selection changes and webView:shouldChangeSelectedDOMRange:toDOMRange:affinity:stillSelecting: is called shortly thereafter (incidentally with dangling proposed selection nodes). What seems to be happening is that TypingCommand::deleteKeyPressed(TextGranularity) and TypingCommand::forwardDeleteKeyPressed(TextGranularity) are performing selection changes before making sure that document()->frame()->shouldDeleteSelection(selectionToDelete) is checked.
Created attachment 11214 [details] Test case Run the sample, move to middle text, press delete. When linked with TOT this test shows that the selection change editing delegate is called right after the delete editing delegate, even though NO is returned to the delete request.
Forgot to mention this is a regression from 2.0.4/419.3
radar 4826940
r17981