Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Thu, Oct 20, 2011 at 3:16 AM, Ryosuke Niwa rn...@webkit.org wrote: However, there's no easy way for the user agent to figure out whether a given transaction wants to select some contents on undo or not. In fact, we don't even know whether we want to restore selection at all. If an automatic transaction was modifying non-text nodes (e.g. SVG line elements), then restoring selection isn't desirable at all. I think I'm missing something: why isn't it desirable?
Re: [whatwg] UndoManager: restoring selection after undoing deletion
Say you had hello world and world is deleted by an user. When the user undoes the deletion, WebKit selects world whereas Firefox and Internet Explorer do not select world. WebKit's behavior matches Mac's NSTextView and we probably would like to keep the current behavior. This confuses me. I think that WebKit's behavior doesn't make a lot of sense (at least in every case). For example, when Ctrl+Backspacing after a word. But moreover, why is this relevant to the question of whether/how we should restore a selection after undoing an operation? Ehsan
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 1:03 PM, Ehsan Akhgari eh...@mozilla.com wrote: Say you had hello world and world is deleted by an user. When the user undoes the deletion, WebKit selects world whereas Firefox and Internet Explorer do not select world. WebKit's behavior matches Mac's NSTextView and we probably would like to keep the current behavior. This confuses me. I think that WebKit's behavior doesn't make a lot of sense (at least in every case). For example, when Ctrl+Backspacing after a word. But moreover, why is this relevant to the question of whether/how we should restore a selection after undoing an operation? WebKit's trying to match Mac's NSTextView here. This is relevant because unapplying / reapplying an automatic transaction should behave like unapplying / reapplying native editing actions. - Ryosuke
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:03 PM, Ehsan Akhgari eh...@mozilla.com wrote: Say you had hello world and world is deleted by an user. When the user undoes the deletion, WebKit selects world whereas Firefox and Internet Explorer do not select world. WebKit's behavior matches Mac's NSTextView and we probably would like to keep the current behavior. This confuses me. I think that WebKit's behavior doesn't make a lot of sense (at least in every case). For example, when Ctrl+Backspacing after a word. But moreover, why is this relevant to the question of whether/how we should restore a selection after undoing an operation? I was assuming that Ryosuke meant that the word world was selected, and the user hit delete, then undo. So it was selected before the delete, and undoing should re-select it.
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:21 PM, Aryeh Gregor a...@aryeh.name wrote: I was assuming that Ryosuke meant that the word world was selected, and the user hit delete, then undo. So it was selected before the delete, and undoing should re-select it. No text is selected, the user hits control-backspace, and then undo. The restored word world now may or may not be selected, depending on the UA and platform. -- Glenn Maynard
Re: [whatwg] UndoManager: restoring selection after undoing deletion
On Wed, Oct 26, 2011 at 4:25 PM, Glenn Maynard gl...@zewt.org wrote: No text is selected, the user hits control-backspace, and then undo. The restored word world now may or may not be selected, depending on the UA and platform. Ah, okay. Got it.
[whatwg] UndoManager: restoring selection after undoing deletion
Hi, The way selection is restored on WebKit after undoing selection is different from the way it is done on Firefox and Internet Explorer. Say you had hello world and world is deleted by an user. When the user undoes the deletion, WebKit selects world whereas Firefox and Internet Explorer do not select world. WebKit's behavior matches Mac's NSTextView and we probably would like to keep the current behavior. However, there's no easy way for the user agent to figure out whether a given transaction wants to select some contents on undo or not. In fact, we don't even know whether we want to restore selection at all. If an automatic transaction was modifying non-text nodes (e.g. SVG line elements), then restoring selection isn't desirable at all. I can think of two approaches to solve this problem: 1. Let automatic transactions also have unapply/reapply and call them after user agents had done its work, and make the user agent do nothing in regards to selection. We can name them afterUnapply/afterReapply if we want. The benefit of this approach is that it's very general and authors can do other things as well while the disadvantage being author needs to be fully aware of platform-convention of how selection is restore upon undo/redo. 2. Add a boolean restoreSelection and isDeletion properties to the Transaction interface. The user agent restores the selection when the value is true and does not restore selection when the value is false. isDeletion is true when the transaction is meant to delete contents and false otherwise. (Maybe negate the property so that common case will be easy?) The user agents can probably use some heuristics to determine whether a given transaction is deleting contents or not. But I don't like either solution so I'm open to your ideas and thoughts on this. Best, Ryosuke Niwa Software Engineer Google Inc.
