-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