August 2010 - webkit-dev - lists.webkit.org

Fwd: webkit editing rewrite?
by Ryosuke Niwa 09 Aug '10

09 Aug '10

> > -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

5 5

Commit Queue Outage
by Eric Seidel 06 Aug '10

06 Aug '10

The Commit Queue will be down as of this afternoon, as we have to move the machine this weekend. Any patches you mark cq+ this weekend will get landed early next week (likely monday). I'll reply to this thread once it's back up and running. Sorry for any inconvenience. -eric

1 0

New wiki page for Visual Studio debugging tips
by Adam Roben 05 Aug '10

05 Aug '10

While working on WebKit2 I've had to become a bit more savvy in my Visual Studio usage. I started a wiki page to record useful tips I've learned. You can find it here: <https://trac.webkit.org/wiki/Debugging%20With%20Visual%20Studio>. I hope others will find it useful, too. Please add your own tips to it! -Adam

1 0

Some new coding style rules
by Nikolas Zimmermann 05 Aug '10

05 Aug '10

Good morning WebKit crowd, I'd like to discuss some style issues, that I'm frequently unsure about: 1. namespace closing brace It was discussed in http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10563 , but with no real result. When writing headers, do we need the "// namespace Foo" comment after the namespace closing brace? I think it's visual noise and would like to see a style rule that forbids it. (A rule that says we need this would also be fine with me, as long as we write it down. But I'd vote for removing those comments, I don't trust them anyways, if I'm unsure.) namespace WebCore { ... } // namespace WebCore 2. ENABLE(FOO) #endif comments #if ENABLE(FOO) .. #endif // ENABLE(FOO) Shall we remove the comment, or require it explicitely in the style rules? 3. Inclusion order Say Foo.h is guarded with ENABLE(FOO) macros Foo.h: #if ENABLE(FOO) namespace WebCore { class Foo... } #endif What's the correct inclusion order in Foo.cpp: #include "config.h" #include "Foo.h" #if ENABLE(FOO) .. #endif or #include "config.h" #include "Foo.h" #if ENABLE(FOO) .. #endif (I think the former, as it makes no sense to process the header, if I already know it's enclosed in ENABLE(FOO) blocks) I'd be happy if we could agree on rules and write them down. Cheers, Niko

8 8

HTML5 tree builder enabled
by Adam Barth 05 Aug '10

05 Aug '10

The HTML5 tree builder is enabled as of <http://trac.webkit.org/changeset/64712>. Check out our awesome SVG-in-HTML demo (in a post r64712 build, of course): http://trac.webkit.org/export/LATEST/trunk/LayoutTests/svg/in-html/circle.h… In light of the other thread about wanting more blog posts, I'm working on a blog post about this change that I hope to post some time later today. If we've horribly broken everything, please file a bug and CC me and Eric. Thanks again, Adam

2 1

Re: [webkit-dev] webkit editing rewrite?
by Geoffrey Garen 04 Aug '10

04 Aug '10

If you'll permit me to expert two of your thoughts: > If we exposed a good set of APIs to JavaScript, then I don't think gluing will be much of an issue. > 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. Notice that you take "a good set of APIs" to be a given, from which you start to reason about the value of a rewrite done in JavaScript. As Maciej and Darin have already mentioned, a good set of abstractions upon which to build editing is not a given. It is the critical part of the task. So far, I haven't seen a proposal for a good set of abstractions upon which to build editing. I'd like to see a proposal for that. I worry that talk of a rewrite and a new language is just a distraction from that real task. Geoff

2 1

webkit editing rewrite?
by Ojan Vafai 04 Aug '10

04 Aug '10

At the editing meeting at the WebKit conference in April, we discussed the idea of coming up with a replacement to Position/Range, using that throughout the editing code and then eventually exposing that API to the web to supersede DOM Ranges. Specifically, the idea was to get rid of node/offset pairs and instead having the following possible positions: beforeNode, nodeStart, afterNode, nodeEnd. We would then only use offsets for positions inside text nodes. There are also a slew of other APIs web developers need to make editing work well, e.g., undo management, better selection control, position normalizing, etc. Finally, the editing code is crashtastic. Some of that is due to less than great foundations like the current Position class. Some of it is due to editing just being complicated. Some of us had a somewhat crazy idea to rewrite much of the editing code (e.g. document.execCommand) in JavaScript. Pros: -Ensures that the APIs we expose to the web are at least good enough for our own editing code -Ensures that editing code never crashes (outside of JSC/V8 bugs) -Gives a clean slate for starting the editing code anew -Moves code out of WebCore -If other browser vendors choose to expose the same APIs, then we can share the editing library and make the world better for web developers 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'm not too concerned about the perf hit. It should be no more than a constant-factor and, historically, the editing perf problems have been order-of-magnitude issues. As for the functionality regressions, I think they're inevitable. We'd hit most of the same issues trying to refactor the existing C++ code on top of better APIs. The best we can hope for is to write extra tests for each bit that we port over. We don't need to do this as one large atomic swap. We can port one command at a time over to keep this as incremental changes. There's also the question of whether we should expose the library code to JS. But that's orthogonal really. I think we shouldn't to start with not exposing the code. We can always decide to expose it later if we think it's worthwhile. What do you think? Ojan

6 6

How can I stop getting buildbot ChromeOS failure mails?
by Darin Adler 04 Aug '10

04 Aug '10

I got a large mail that started with this: http://build.chromium.org/buildbot/chromiumos/ Automatically closing tree for "build image" on "x86 slab full" I don’t want to receive these mails. I don’t understand them. They are full of hex numbers that probably relate to git and check-ins in Chromium and I don’t work on that project. And I have no idea who to write to since the mail comes from nobody(a)example.com. -- Darin

2 1

commit-queue works again <EOM>
by Eric Seidel 04 Aug '10

04 Aug '10

It was down for the last 36 hours due to Leopard bustage and moving machines. It's back up and running again now. Apologies for (my part) of the trouble. http://queues.webkit.org/queue-status/commit-queue -eric

3 4

Question about A Usage of RefPtr
by Yuxiang Luo 04 Aug '10

04 Aug '10

Hi, I'm currently looking into a bug (42799), and find that class CSSComputedStyleDeclaration has a property 'RefPtr<Node> m_node', which means this class takes ownership of the Node to which the computedStyle object belongs back to. Does this mean that if the computedStyle object get released, the owner Node will be released too? For example, the class Position owns the node object 'RefPtr<Node> m_anchorNode', and in method 'Position::computedStyle', it passed the raw pointer m_anchorNode.get() to CSSComputedStyleDeclaration, after that, both 'Position' and 'CSSComputedStyleDeclaration' own the Node pointer. Is this a mistake in CSSComputedStyleDeclaration which incorrectly uses RefPtr to wrap the Node? (another similar class CSSMutableStyleDeclaration only has the raw pointer) Another question is, as the bug 42799 shows, when getting 'pixel*' or 'pos*' properties, if the unit type is 'em' or 'ex', the result is not multiplied with factor. The factor for these two unit types depends on the RenderStyle of corresponding element, but the class CSSStyleDeclaration does't provide any access to corresponding element/node. I find that both CSSComputedStyleDeclaration and CSSMutableStyleDeclaration have the field 'm_node’. So to fix the bug, we might need to put the field up to the base class CSSStyleDeclaration. But I'm not very familiar with the code base yet, and not sure whether the change will break other logic? Thanks in advance for your help. Best Regards. -- Yuxiang Luo Engineer@Google <luoyx(a)google.com>

1 2