[webkit-dev] Unapplying execCommand

Ryosuke Niwa rniwa at webkit.org
Sat Oct 9 15:07:14 PDT 2010

On Fri, Oct 8, 2010 at 5:51 PM, Darin Adler <darin at apple.com> wrote:

> On Oct 8, 2010, at 3:47 PM, Ryosuke Niwa wrote:
> > Does anyone know if this was a UI / functionality decision or it is a
> bug?
> This undo behavior you describe in Safari is what is automatically
> implemented by Cocoa’s NSUndoManager. The concept is that when a user undoes
> something, they want to undo everything they did that corresponds to one end
> user event, not a single command from some lower level point of view.

I see. Thanks for the info.

Getting different behavior on Mac OS X might be challenging. The Mac version
> of WebKit ties undo in with the Cocoa undo management rather than creating
> its own separate undo mechanism. This allows the end user to undo a set of
> operations that involve web views interleaved with other operations. That’s
> good for the Undo menu items in applications. But when a webpage does
> execCommand("undo") that behavior is not as useful. If this turns out to be
> important from a web compatibility point of view we can try to find some way
> to change it without losing the beneficial effects.

IMHO, the current behavior of Safari is very confusing to developers.  Can
we add a new editor command (e.g. UndoUntilLastUserInitiatedAction) to
support the current behavior of undo  and change the DOM initiated undo's
behavior to match that of other browsers?

According to the latest HTML5 spec, execCommand('undo') should undo exactly
one execCommand (
 undo *Summary*: Acts as if the user had requested an undo.*Action*: The
user agent must move back one
its undo transaction
restoring the associated state. If the undo
at the start of the undo transaction
the user agent must do nothing. See the undo
. *Enabled When*: The undo
not at the start of the undo transaction
. *Indeterminate When*: Never.*State*: Always false. *Value*: Always the
string "false".

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101009/17a6927a/attachment.html>

More information about the webkit-dev mailing list