Re: [UndoManager] Disallowing live UndoManager on detached nodes

On Wed, Aug 22, 2012 at 10:44 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> BTW, I don't think the API should impose any requirements on how browsers
> handle undo for their built-in form controls. I have not read the spec
> close enough to know if that is the case.
>

No, the spec. currently doesn't specify this behavior on purpose partially
because I'm doubtful that Microsoft can change IE's behavior.

On Wed, Aug 22, 2012 at 11:05 PM, bugs@pettay.fi <bugs@pettay.fi> wrote:

> On 08/22/2012 10:44 PM, Maciej Stachowiak wrote:
>
>>
>> On Aug 22, 2012, at 6:53 PM, Ojan Vafai <ojan@chromium.org <mailto:
>> ojan@chromium.org>> wrote:
>>
>>  On Wed, Aug 22, 2012 at 6:49 PM, Ryosuke Niwa <rniwa@webkit.org <mailto:
>>> rniwa@webkit.org>> wrote:
>>>
>>>     On Wed, Aug 22, 2012 at 5:55 PM, Glenn Maynard <glenn@zewt.org<mailto:
>>> glenn@zewt.org>> wrote:
>>>
>>>
>>>         On Wed, Aug 22, 2012 at 7:36 PM, Maciej Stachowiak <
>>> mjs@apple.com <mailto:mjs@apple.com>> wrote:
>>>
>>>             Ryosuke also raised the possibility of multiple text fields
>>> having separate UndoManagers. On Mac, most apps wipe they undo queue when
>>>             you change text field focus. WebKit preserves a single undo
>>> queue across text fields, so that tabbing out does not kill your ability to
>>>             undo. I don't know of any app where you get separate
>>> switchable persistent undo queues. Thins are similar on iOS.
>>>
>>>
>>> Think of the use-case of a threaded email client where you can reply to
>>> any message in the thread. If it shows your composing mails inline (e.g. as
>>> gmail does), the most common user expectation IMO is that each email
>>> gets it's own undo stack. If you undo the whole stack in one email you
>>> wouldn't
>>> expect the next undo to start undo stuff in another composing mail. In
>>> either case, since there's a simple workaround (seamless iframes), I don't
>>> think we need the added complexity of the attribute.
>>>
>>
>> Depends on the user and their platform of choice. On the Mac I think it's
>> pretty much never the case that changing focus within a window changes your
>> undo stack, it either has a shared one or wipes undo history on focus
>> switch. So if GMail forced that, users would probably be surprised. I can
>> imagine a use case for having an API that allows multiple undo stacks on
>> platforms where they are appropriate, but merges to a single undo stack on
>> platforms where they are not. However, I suspect an API that could handle
>> this automatically would be pretty hairy. So maybe we should handle the
>> basic single-undo-stack use case first and then think about complexifying
>> it.
>>
>
>
> I think the undo-stack per editing context (like <input>) is pretty
> basics, and certainly something I wouldn't remove from Gecko.
> (Largely because using the same undo for separate <input> elements is just
> very weird, and forcing web apps to use iframes to achieve
>  that would be horribly complicated.)
>

I certainly respect that decision.

This is why the current specification does not even mention about this. As
far as the specification is concerned, it's up to the implementation to
decide although input and textarea element's value IDL attribute is
tentatively tied to the document's undo manager at the moment (waiting for
implementation feedback as the rest of the spec).

Editing is one of very few areas on the platform where we can't necessarily
agree on one behavior because there are different platform conventions and
platform specific features.

- Ryosuke