[webkit-dev] Fwd: webkit editing rewrite?

[Ryosuke Niwa]

>  > -Ensures that editing code never crashes (outside of JSC/V8 bugs)
>
> JavaScript can still crash -- you just get an unhandled exception instead
> of a segfault. It's not clear to me why that would be better.


I think the kind of crashes Ojan is talking about are ones caused by DOM
mutation events.  When we're in a middle of a composite event and fire a
DOMModified or whatever appropriate mutation event is, JavaScript can come
in and remove node, delete the entire document, or some other crazy things.
 To avoid this, we have to consider all possible ways in which DOM can be
modified.  This is really hard to do, and implementing some of editing
commands in JavaScript will at least stop us from crashing although it'll
probably end in some unexpected behavior.  But I'd suspect unexpected
behavior is better than crashing for most of users.

- Sometimes, instead of an unhandled exception, you'll just get incorrect
> behavior that's very hard to track down.
>

But many incorrect behaviors we get in editing is to produce incorrect DOM,
and that's very easy to detect & fix using inspector.  Or we have a problem
where Position / VisiblePosition becomes null or point to somewhere we don't
intend to point but this problem can be solved if we had used JavaScript
although incorrect behavior problem persists.

> Cons:
> > -Potentially slower since DOM calls are now JS-->C++
> > -Potential for regressions due to holes in the layout test coverage
> > -Not statically typed
>
> I notice that you don't mention the added complexity of gluing two
> languages together for core DOM operations. I think that's probably the main
> con.
>

If we exposed a good set of APIs to JavaScript, then I don't think gluing
will be much of an issue.  Things like typing style and undo/redo could pose
a challenge though.

However, I don't agree that refactoring inevitably introduces just as many
> bugs as rewriting. I would submit that the entire history of the WebKit
> project demonstrates the value of refactoring over rewriting.
>

I would agree that refactoring is better than rewriting in general.  And
porting all commands without making regression is extremely hard at the
moment.  However, there's something to consider here.

Bugs like https://bugs.webkit.org/show_bug.cgi?id=25607 (*Need a way to
catch (and cancel?) any execCommand. Maybe document.onexeccommand = ?*)
indicate that web developers want more control over how editing commands are
performed.  For example, new version of Google docs doesn't use our editing
ability but rather implements its own, and I'm very sad
and embarrassed about it since I've been working full-time just to improve
RTE in WebKit.

Now, suppose we provided some solution to the bug 25607 and started to let
sites overriding editing commands. Naturally, we want to make it easier for
web developers to implement their own editing commands.  Things like
ApplyStyleCommand or typing style might be something developer want to have
access to then. Or otherwise they have to implement an equivalent function,
class, etc... in JavaScript themselves.  And if we did provide a good set of
APIs such that web developers themselves can implement their own editing
commands, then there's no reason we can't implement our editing commands in
terms of those public APIs, putting aside, whether we should do it or not.
 To put it another way, our not being able to implement the existing editing
commands using the public APIs indicates that we're not providing good set
of APIs now.

Best,
Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100804/82dd3dd8/attachment.html>