[Webkit-unassigned] [Bug 62536] [EFL] Supports to execute "redo" command.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jul 11 21:17:53 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=62536





--- Comment #22 from Jaehun Lim <ljaehun.lim at samsung.com>  2011-07-11 21:17:52 PST ---
(In reply to comment #21)
> (In reply to comment #20)
> > (From update of attachment 100375 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=100375&action=review
> > 
> > > Source/WebKit/efl/WebCoreSupport/EditorClientEfl.cpp:214
> > > +        ASSERT(!m_isInRedo);
> > > +        m_isInRedo = true;
> > 
> > I'm still not happy about the fact there's asymmetry between undo and redo.
> 
> It looks the m_isInRedo flag is used by registerCommandForUndo() in GTK port.
> 
> http://trac.webkit.org/browser/trunk/Source/WebKit/gtk/WebCoreSupport/EditorClientGtk.cpp#L354
> 
> So, if we don't know why redoStack is cleared when m_isInRedo is false, we should not add the m_isInRedo to redo().

I think we should check redo status when a command is added into undoStack.

In general, when a new command is added into undoStack, commands in redoStack are useless, So redoStack should be cleared.
But when a command is moved from redoStack to undoStack by redo function, we should not clear the redoStack, because user could redo next commands in redoStack continuously.

But current registerCommandForUndo() has no redostack clearing codes.
I'll make a new patch.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list