On Feb 11, 2013, at 5:16 PM, Ryosuke Niwa <[email protected]> wrote:
> On Mon, Feb 11, 2013 at 5:11 PM, Maciej Stachowiak <[email protected]> wrote:
> On Feb 11, 2013, at 4:23 PM, Ryosuke Niwa <[email protected]> wrote:
>> On Mon, Feb 11, 2013 at 3:53 PM, Enrica Casucci <[email protected]> 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
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-dev
