[webkit-dev] Some landed patches have incorrect date in commit messages and ChangeLog
Hi, I noticed that several patches landed recently have the incorrect date put in the commit messages and ChangeLog. Please fix the incorrect information in ChangeLog. For the commit messages, anyone know if we can fix them or not? Please make sure the correct date is used when you land your patch manually. Thanks. Jian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Hi guys, As some of you know, we are working on a remote debugging feature in Web Inspector. There are many good reasons behind the project including the following: - Debugging WebKit on embedded devices - Shaping up a good protocol for ourselves - Introducing external SDKs on top of the protocol for IDE integrations and alternate front-ends We've had serialized interaction with the out-of-process inspector for quite a while in Chromium. We were upstreaming it into WebKit and have reached an important milestone recently: all the interaction between the inspected page and inspector is entirely serialized on the WebKit level. All the embedder needs to do is to implement a socket that would serve the inspector front-end files and provide our messaging with appropriate transport. Now this socket is likely to be platform-specific, implemented on the WebKit and/or host browser levels. It also makes more sense to implement socket on mobile platforms first. However, we've done a proof-of-concept implementation in Chromium and it is now in a demoable state! See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + WebKit nightly to the right. WebKit nightly connects remotely to Chromium over HTTP on the port 9222 and does remote debugging including DOM inspection, breakpoints and such. The communication is established by means of a WebSocket. The interesting thing about the implementation is that inspector front-end is fetched from the host browser, so that there is no mess with protocol versioning and no need in exposing the interaction protocol any time soon. So I made the demo and it looked cool. I thought maybe we do a blog post on it. The blog post would draw attention to the Web Inspector and its progress, share the remote debugging vision with the interested parties and would simply look cool. Front-end is working as a pure HTML5 application (obviously full of WebKit-specific styles, but still) which is impressive. Now the project is nowhere complete in terms of finalizing the message format and the protocol itself, but there is no intention to expose it right now. We'd like to let it live with fetchable front-end and mature before we expose the protocol and commit to any level of interface support. What do you think, is it ready for a blog post? Thanks Pavel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some landed patches have incorrect date in commit messages and ChangeLog
What about the case where between the time you submit the patch and it gets committed, a day passes by...does the commit queue fix this automatically, or does someone have to go back and fix it manually? Fady On Mon, Aug 9, 2010 at 1:51 PM, Jian Li jia...@chromium.org wrote: Hi, I noticed that several patches landed recently have the incorrect date put in the commit messages and ChangeLog. Please fix the incorrect information in ChangeLog. For the commit messages, anyone know if we can fix them or not? Please make sure the correct date is used when you land your patch manually. Thanks. Jian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some landed patches have incorrect date in commit messages and ChangeLog
Yes. The commit-queue uses svn-apply which knows how to fix the date using: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/VCSUtils.pm#L1231 -eric On Mon, Aug 9, 2010 at 2:06 PM, Fady Samuel fsam...@google.com wrote: What about the case where between the time you submit the patch and it gets committed, a day passes by...does the commit queue fix this automatically, or does someone have to go back and fix it manually? Fady On Mon, Aug 9, 2010 at 1:51 PM, Jian Li jia...@chromium.org wrote: Hi, I noticed that several patches landed recently have the incorrect date put in the commit messages and ChangeLog. Please fix the incorrect information in ChangeLog. For the commit messages, anyone know if we can fix them or not? Please make sure the correct date is used when you land your patch manually. Thanks. Jian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
On Aug 9, 2010, at 12:48 PM, Pavel Feldman wrote: See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + WebKit nightly to the right. WebKit nightly connects remotely to Chromium over HTTP on the port 9222 and does remote debugging including DOM inspection, breakpoints and such. Great demo! [...] The blog post would draw attention to the Web Inspector and its progress, share the remote debugging vision with the interested parties and would simply look cool. [...] What do you think, is it ready for a blog post? The concern I had was that this isn't readily available in the browser for download on webkit.org (WebKit nightly). In that way, I think for many it will feel a bit like a teaser. However, WebKit is an open source project, so I'd expect to see all kinds of WebKit related news and blog posts available there. In the end I feel the more publicity the better. Especially when someone just expressed an interest in seeing more interesting blog posts. The last blog post on the Web Inspector was in April. Before that it was November. That was a 5 month spread, and this would be a 4 month spread. Thats a pretty consistent rate showing off awesome work. - Joe ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some landed patches have incorrect date in commit messages and ChangeLog
On Mon, Aug 9, 2010 at 10:51 AM, Jian Li jia...@chromium.org wrote: I noticed that several patches landed recently have the incorrect date put in the commit messages and ChangeLog. Please fix the incorrect information in ChangeLog. For the commit messages, anyone know if we can fix them or not? Please make sure the correct date is used when you land your patch manually. I didn't realize this was a bad thing. I thought it was potentially useful information in the ChangeLog to know the date a change was written, especially since the commit time is available from SVN already; obviously the position within the ChangeLog shows where it lies in the history of the project. I agree that if tools don't manage this it will be easy to overlook. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
I would be interested as well in seeing a blog post about this new feature. Very cool stuff, good work! Josh ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Canvas performance and memory usage
There are other cases as well where you want a copy. Patterns are another example. For example you can create a pattern from another canvas, and I don't think it's supposed to be live if that other canvas later changes. There are examples in SVG as well where patterns are used and I am pretty sure a copy is the desired behavior. I don't think it's as simple as saying image() should never copy. I spent some time thinking about this from a CG perspective, and I couldn't really come up with a good solution. We use a bitmap context for efficient pixel access for get/putImageData. Any platform that wants these functions to be efficient has to keep the pixels easily obtainable. This means, for example, that we can't produce a live image using CGLayers. Looking at Qt, the only current platform to return a live image to canvas for rendering, it looks like they made this tradeoff, i.e., it looks to me like get/putImageData are slower than other platforms. (The get is having to call toImage() on a pixmap and then has to convert to obtain a good representation of the data for a QImage). The put has to render the changes into the pixmap. I tried renaming the two methods (image() and imageForRendering()) to copiedImage and liveImage, and ended up with about an 80/20 split at the call sites between the two. It looked really ugly to me, since in nearly every case the liveImage was just being used to paint the current contents of the ImageBuffer, i.e., it was just being passed to drawImage. The copiedImage was typically passed to somebody who needed to retain it for later rendering, e.g., a pattern. So to sum up, the call sites want two things: (1) To render the current contents of the image buffer efficiently. (2) To obtain a copied image that is independent of the image buffer that is typically retained by someone else. And the current implementations of image()/imageForRendering() do three things: (1) Make a copy of the image buffer into an Image (e.g., Skia). (2) Make an Image that is a live representation of the Image buffer contents (e.g., Qt using imageForRendering). (3) Make a copy-on-write image wrapper (e.g., CG). Assuming the copy-on-write stuff in CG is actually working (and I suspect that it is), then it's actually a pretty good solution. You don't copy to do throwaway drawing. Pixel access is efficient using get/PutImageData. There's no need to distinguish between copied images vs. live, with the caveat that the cached image has to be cleared (only an issue for canvas, since nobody else does continual drawing to ImageBuffers). Anyway I'm open to suggestions here. :) As for removing the ImageBuffer completely, I don't think you can get away with that. The canvas buffer's size does not necessarily match the size into which it is drawn. You need to be able to get to the image pixels of a possibly larger (or smaller) buffer. You also have to be able to draw the contents of one canvas into another canvas, so you have to be able to treat the canvas as an image. Again that means being able to get to the contents of the canvas itself as a separate buffer/image. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: webkit editing rewrite?
On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak m...@apple.com wrote: I think this carries an assumption that the right internal abstractions are necessarily also a sensible public API. I don't know if that is a good assumption. You're right that I was making this assumption. My intuition is that the majority of the APIs we'd need internally will be the same as the ones we'd want in a public API, but I can believe that won't be true across the board. I've been very focused on this Position/Range discussion, where I do think a very similar, if not identical API makes sense. Anchoring to nodes instead of index+offset is just a better API for editing web content. I think creating better abstractions to implement the legacy editing API on the one hand, and creating a better public editing API for Web content on the other, are both quite difficult problems. If you assume that they must be solved with a single solution, that's probably overconstraining the problem space. Fair enough. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth aba...@webkit.org wrote: On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak m...@apple.com wrote: If mutation events tend to break editing, one simple solution is to turn then off within the scope of editing operations and send a single mutation event at the end. It's not clear if that kind of solution would be appropriate to expose to Web content, though; you can't do the RAII idiom in JavaScript so there could be too much risk of staying stuck in the mutation events deferred state. On the other hand, a dynamic-wind-style solution might be appropriate. This is one tiny example of how the same abstractions might not be right internally and externally. If we don't already have it, we definitely want a RAII for turning off mutation events (or at least ASSERTing that we're not trying to fire them) for the parser. The new and old tree builders might explode if they ever fire a mutation event. I'm trying to figure out what we should do with DOM Mutation Events. The general agreement from the www-dom discussion of mutation events was that they are the wrong abstraction for editing related code. beforeinput/input events meet editing needs better. So, that leaves a small list of relatively low-priority use-cases. See http://www.w3.org/2008/webapps/wiki/MutationReplacement for some of them. Mutation events are a huge source of crashes and they complicate WebCore code considerably. Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event. Here's some options I see: 1. Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously. 2. Drop support for them with no replacement. 3. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. 4. Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html). Do any of these options sound feasible or is the only option to do the very large amount of work to make existing mutation events work? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
On Mon, Aug 9, 2010 at 4:39 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Aug 5, 2010 at 2:22 AM, Adam Barth aba...@webkit.org wrote: On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak m...@apple.com wrote: If mutation events tend to break editing, one simple solution is to turn then off within the scope of editing operations and send a single mutation event at the end. It's not clear if that kind of solution would be appropriate to expose to Web content, though; you can't do the RAII idiom in JavaScript so there could be too much risk of staying stuck in the mutation events deferred state. On the other hand, a dynamic-wind-style solution might be appropriate. This is one tiny example of how the same abstractions might not be right internally and externally. If we don't already have it, we definitely want a RAII for turning off mutation events (or at least ASSERTing that we're not trying to fire them) for the parser. The new and old tree builders might explode if they ever fire a mutation event. I'm trying to figure out what we should do with DOM Mutation Events. The general agreement from the www-dom discussion of mutation events was that they are the wrong abstraction for editing related code. beforeinput/input events meet editing needs better. So, that leaves a small list of relatively low-priority use-cases. See http://www.w3.org/2008/webapps/wiki/MutationReplacement for some of them. Mutation events are a huge source of crashes and they complicate WebCore code considerably. Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event. Here's some options I see: 1. Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously. 2. Drop support for them with no replacement. 3. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. 4. Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html). Do any of these options sound feasible or is the only option to do the very large amount of work to make existing mutation events work? An additional data point is that the DOM events level 3 specification declares mutation events to be deprecated and includes the following text: Many single modifications of the tree can cause multiple mutation events to be dispatched. Rather than attempt to specify the ordering of mutation events due to every possible modification of the tree, the ordering of these events is left to the implementation. This means that the mutation event behavior for anything but the absolute simplest of cases is implementation-defined, and in practice different across browsers and browser versions. Additionally, the DOM events spec currently has no editor and so there's not a great chance of improvements in the spec in the short term. I'd strongly suggest that we go with option 2. Problems with editing and input should be fixed by editing and input APIs and there honestly are not many other compelling use cases that actually work today. Mutation events have caused a lot of nasty crashes and complexity in WebKit and there's no reason to believe that this will improve in the short term. - James Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
Hi Ojan. Mutation events are a huge source of crashes and they complicate WebCore code considerably. Indeed. I also think mutation events unnecessarily complicate the API space from a web content author's perspective. Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event. I think this is the key question -- how does existing content use mutation events, and what would we risk by changing or eliminating them? Another important question is whether/how important DOM API compatibility tests, like the Acid tests, use mutation events. What's the best way to answer these questions? I think that answer will probably guide our perspective on the options you listed. Here's some options I see: Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously. This seems like the most appealing option if (a) backwards compatibility requires us to keep mutation events, but (b) making them asynchronous doesn't harm that backwards compatibility in significant ways. Drop support for them with no replacement. This seems like the most appealing option if mutation events just aren't used. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. This seems like the most appealing option if we're going to try to coordinate our action on mutation events with third party changes. (Otherwise, the beforeinput/input events can be an independent concern.) Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html). I just skimmed this API description, but my take on it is that it's very similar to #1 -- it's still a pretty intrusive set of mutation-related APIs, just an asynchronous one. I'm not convinced by Jonas Sicking's claim that this API is significantly different because it lacks a bubble / capture phase. I don't think that was ever the main problem with mutation events. So, I prefer #1 to #4, since #4 just seems like a more complicated way to avoid the burden of synchronous mutation events. Geoff___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
I am very, very tempted to just get rid of them. As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway. However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.). So I think we will upset a bunch of extensions developers if we just go cold turkey, which is probably not the right thing -- regardless of whether techniques they employ are sound or not. With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.). :DG On Mon, Aug 9, 2010 at 5:11 PM, Geoffrey Garen gga...@apple.com wrote: Hi Ojan. Mutation events are a huge source of crashes and they complicate WebCore code considerably. Indeed. I also think mutation events unnecessarily complicate the API space from a web content author's perspective. Also, I don't see any evidence that mutation events are used much other than as a blunt dirty bit for editing code, which can now be replaced with the input event. I think this is the key question -- how does existing content use mutation events, and what would we risk by changing or eliminating them? Another important question is whether/how important DOM API compatibility tests, like the Acid tests, use mutation events. What's the best way to answer these questions? I think that answer will probably guide our perspective on the options you listed. Here's some options I see: Make the existing mutation events them async. That would address all the issues with them except for the performance cost and would only be backwards-incompatible for the small percentage of sites that depend on the events firing synchronously. This seems like the most appealing option if (a) backwards compatibility requires us to keep mutation events, but (b) making them asynchronous doesn't harm that backwards compatibility in significant ways. Drop support for them with no replacement. This seems like the most appealing option if mutation events just aren't used. Complete the implementation of beforeinput/input events to support editing use-cases then do 1 or 2. This seems like the most appealing option if we're going to try to coordinate our action on mutation events with third party changes. (Otherwise, the beforeinput/input events can be an independent concern.) Same as above, but also implement a low-level replacement for mutation events (e.g. something like http://lists.w3.org/Archives/Public/www-dom/2009AprJun/0081.html). I just skimmed this API description, but my take on it is that it's very similar to #1 -- it's still a pretty intrusive set of mutation-related APIs, just an asynchronous one. I'm not convinced by Jonas Sicking's claim that this API is significantly different because it lacks a bubble / capture phase. I don't think that was ever the main problem with mutation events. So, I prefer #1 to #4, since #4 just seems like a more complicated way to avoid the burden of synchronous mutation events. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote: I am very, very tempted to just get rid of them. As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway. However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.). So I think we will upset a bunch of extensions developers if we just go cold turkey, which is probably not the right thing -- regardless of whether techniques they employ are sound or not. With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.). Adding input/beforeinput events (#3) wont solve the need of most extension developers that use mutation events today (the examples you cite). So that makes it hard to remove them, especially over time, no matter how much warning you give. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Mutation Events. WAS: Fwd: webkit editing rewrite?
As Ojan indicated, the use cases for DOM Mutation events are extremely limited and to me, most of them feel like we should be solving them differently anyway. This is the question I'm most interested in. You say the use cases are limited. How do you know? Are you speaking about when you would use mutation events, or do you have data on when authors use them on the web? Is one of the limited use cases on a high traffic web site? Does Mozilla share your opinion? Do others? I have the same questions about Ojan's claim. However, with the introduction of extensions into Chromium and Safari, DOM Mutation events experience a sort of renaissance, being used to sense the DOM changes to re-apply modifications (rewrite URLs, text, etc.). This is an interesting data point. If we just need an event for an extension to reapply its magic to new content, a global, asynchronous DOMContentChanged event might work. If we introduced an API like that, and gave extensions developers time to update, we could probably remove mutation events without harming extensions. I'd like to give the same kind of consideration to data about web content. With this in mind, I think we should do #1 and #3, then #2 after some time and loud over-communication (like Inspector warnings, blog posts, billboards on Hwy 101 etc.). I'm not sure this plan makes sense. If we plan to do #2 (remove mutation events), #1 (make mutation events asynchronous) may not be worth the effort. Also, I'm not sure that the best time to remove mutation events depends on what we do (communication) -- it most likely depends on what others do (changing web content not to use mutation events, or not). On the other hand, I would be willing to chip in to see Friends Don't Let Friends Use DOM Mutation Events in big letters over highway 101 :). Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
