[webkit-dev] Fwd: webkit editing rewrite?
rniwa at webkit.org
Wed Aug 4 15:48:29 PDT 2010
> > -Ensures that editing code never crashes (outside of JSC/V8 bugs)
> 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
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
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
although incorrect behavior problem persists.
> > -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
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,
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev