[webkit-help] Fwd: Problem extending WebViewUndoableEditing

[Alexander Shulgin]

On 21.08.2010 21:04, Ryosuke Niwa wrote:
> On Sat, Aug 21, 2010 at 8:10 AM, Alexander Shulgin
> <alexander.shulgin at yessoftware.com
> <mailto:alexander.shulgin at yessoftware.com>> wrote:
>
>     For content editing capabilities we've found that WebKit behavior is
>     often surprising or plain broken.  So we've patched it (on Windows)
>     to accept our custom editing commands through newly introduced COM
>     interface.  Now, if we design the commands carefully we can enjoy
>     arbitrary editing capabilities and undo/redo operations work smoothly.
>
> I'm sorry about that :(  Could you mind listing problems you had with
> our behavior so that we can fix them in the future?

Our biggest concern is paragraphs merging.  We use 
replaceSelectionWithNode method in quite a few places and far too often 
we get unsatisfactory results: while the look of rendered HTML might be 
well expected, the HTML text itself is ridden with gigantic <span 
style="-list-of-almost-all-possible-css-properties-">.

Another problem we're constantly struggling with is visual cursor 
position.  Inserting content at cursor was all but what expected until 
we've implemented that ourselves.  For example, pasting text right 
before <h1> would go under the heading tag and/or introduce a span with 
style imitating h1 look...

As I understand these quirks come from the initial application of 
content editing: mail composer.  Typical user doesn't care about 
internal HTML representation of the letter as long as it looks nicely 
and as expected.  But unfortunately, this behavior is unacceptable for 
our application.

I also think there is unlikely to be a silver bullet fixing these 
problems, as we find we need different workarounds for different editing 
actions using the same replace-selection/insert-at-cursor commands.

>     I think I can, but that would be no different from my current
>     approach.  And this will just complicate things further w/o the real
>     need for it.
>
>     Trying to sketch this move of CustomEditingCommand to WebCore I see
>     the strong need for some proxy object (or three separate ``functor
>     objects'') to be passed from WebKit to WebCore:
>
> Right, the proxy is required but I don't think it's a minus because
> EditCommand::* are really meant to be used inside WebCore.

 > What you
> really should be doing is to make your editing commands inherit from
> CompositeEditCommmand and use simple commands to do your work because
> I'm sure things like splitElement and removeNodePreservingChildren are
> useful in any implementation of editing.  That way, you don't have to
> manually save & restore states in each of your editing command.

Oh I would do that with great pleasure only if I could.  I have to 
mention that again: our custom commands are in C# realm and from WebCore 
point of view they all are just SimpleEditCommands with 
apply/unapply/reapply triplet of primitives.

> But if you're saying that you've implemented a better
> SimpleEditCommand's or found a better way of implementing editing
> commands, I'm very interested in knowing what you did because we can
> take the same approach in WebCore itself.

Unfortunately, not--we didn't any significantly better.  We're using the 
same concept of simple and composite commands, only we don't need to 
recompile WebKit to fix every single problem in editing commands.

So basically, we (ab)use this new possibility to re-implement parts of 
WebKit the way we like it w/o the need to dig deeply into its internals.

--
Alex