Re: [webkit-dev] Controlling use of Deletion UI with ENABLE_DELETION_UI
On Feb 11, 2013, at 5:16 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 11, 2013 at 5:11 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 11, 2013, at 4:23 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 11, 2013 at 3:53 PM, Enrica Casucci enr...@apple.com wrote: with http://trac.webkit.org/changeset/142533 I've added the ability to control the use of the Deletion UI. I've explicitly enabled the feature for MAC and disabled it for iOS but I left in on by default for all the other ports, since I wasn't sure if how other WebKit clients were using it. I suspect many ports use it only in the tests. If this is the case I would encourage every port to take explicit action and decide whether this is something you want or not. You forgot to mention that you did this as a part of upstreaming iOS code :) I'm going to move delete button controller tests to platform/mac and delete corresponding code in non-Mac ports. Would it be worthwhile to make the editing deletion UI runtime switchable instead, so the behavior with it on and off can be tested on all ports? That's the status quo but I don't think that's useful given no other port ships it. A lot of refactoring we want to do in this area will be much easier if non-Mac ports such as Qt and Chromium didn't enable the feature just to pass layout tests. Also, the use of DeleteButtonController comes with a cost even when the client is not interested in the DeletionUI. The delegate call takes as parameter the 'deletable' element which needs to be computed before figuring out that the client is not interested in using it. As an example this is computed for every selection change. The next step is to improve it for ports like Mac where we want to use this but not on every client. Enrica - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The tree is on fire: a tragedy of the commons
I didn't know that failing tests would block the commit queue. I saw they were failing yesterday afternoon and I thought it was ok to wait until this morning to fix them. My apologies for the inconvenience. I believe a reasonable approach to handle these situations is to try to contact the person responsible for braking the tests in IRC and if there is no response within an hour, roll back. I believe that requiring everyone to run the layout tests (the entire suite) before committing is the right thing to do. The only time I haven't done it was yesterday :-(. Lesson learned. Enrica On Feb 26, 2010, at 10:15 AM, Jeremy Orlow wrote: On Fri, Feb 26, 2010 at 7:06 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 26, 2010, at 9:56 AM, Alexey Proskuryakov wrote: On 26.02.2010, at 9:29, Maciej Stachowiak wrote: I'd like it if we had an IRC bot that announced build breakage on #webkit. Perhaps better yet, on #webkit-build, as buildbot used to do. In the past, no one ever joined #webkit-build so this was not an effective means of notification. I didn't even know it existed until now. Was there ever an email sent out on this? If so, I missed it. ___ 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
