[Webkit-unassigned] [Bug 107171] shouldMoveCaretToHorizontalBoundaryWhenPastTopOrBottom should return true on Android

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jan 17 14:38:45 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=107171





--- Comment #13 from Chris Hopman <cjhopman at chromium.org>  2013-01-17 14:40:31 PST ---
(From update of attachment 183268)
View in context: https://bugs.webkit.org/attachment.cgi?id=183268&action=review

>>>>> Source/WebCore/ChangeLog:11
>>>>> +        of behavior for other platforms.
>>>> 
>>>> I don't think adding a new editing behavior makes sense here. r-.
>>>> The only reason we decided to have these editing behaviors is so that we can test these behaviors in layout tests.
>>>> Given that we're not doing it, ifdef will suffice.
>>> 
>>> I don't agree that encapsulating these classes of behavior in an enum makes less sense than adding ifdefs for them when the enum exists. I'd be happier covering this in layout tests than needing to disable/add specific expectations for Android, which would occur if just #ifdefing EditingUnixBehavior.
>> 
>> We already have an if-def for chromium. If we're adding a new editing behavior, then all existing layout tests need to be updated to test "android" editing behaviors as well as exiting ones.
> 
> The existing #ifdef seems like more of a design choice by Chromium than an editing behavior related to a platform. It seems to me that mobile does represent a new class of editing behavior.

rniwa: Are you suggesting adding something like: "#if PLATFORM(CHROMIUM) && defined(ANDROID) \ return false; \ #endif" to EditingBehavior::shouldMove[...]? That seems reasonable to me.

I think it would probably be best if these settings could be set individually (rather than as a group based on the existing EditingBehaviorTypes) by an embedder like all of WebCore::Settings, then we wouldn't need to stick any CHROMIUM stuff in here. What do you think?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list