Re: [UndoManager] Disallowing live UndoManager on detached nodes

On 08/22/2012 11:16 PM, Maciej Stachowiak wrote:
>
> On Aug 22, 2012, at 11:08 PM, Olli Pettay <Olli.Pettay@helsinki.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 Gecko's current
>> behavior would be horribly complicated.)
>
> It might be ok to let Web pages conditionally get Gecko-like separate undo stack behavior inside Firefox, at least on Windows.


> (Firefox even seems
> to do per-field undo on Mac, so I'm starting to think that it's more of a Gecko quirk than a Windows platform thing.)

It is not. Also some other browser engines behave the same way.



>
> But, again, letting webpages force that behavior in Safari seems wrong to me. I don't think we should allow violating the platform conventions for
> undo so freely. You seem to feel strongly that webpages should be able to align with the Gecko behavior, but wouldn't it be even worse to let them
> forcibly violate the WebKit behavior?

It is not worse either way. Equally bad both ways. But, we're designing a new API here, so we should make the API as good as possible from the start.
And I think that means allowing multiple undo stack must be in. The default handling could be somehow platform specific.


>
> So if there is an API for separate undo stacks, it has to handle the case where there's really a single undo stack. And that would potentially be
> hard to program with.
>
> On the other hand, there are certainly use cases where a single global undo stack is right (such as a page with a single rich text editor). And
> it's easy to handle those cases without adding a lot of complexity. And if we get that right, we could try to add on something for conditional
> multiple undo stacks.
>
> Regards, Maciej
>
>
>
>

Received on Thursday, 23 August 2012 13:54:09 UTC