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

[bugzilla-daemon at webkit.org]

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





--- Comment #30 from Ryosuke Niwa <rniwa at webkit.org>  2013-01-23 17:17:20 PST ---
(In reply to comment #29)
> Ok, so here's the problem:
> chromium-android needs EditingBehavior::shouldMoveCaret[...] to return true
> chromium-linux needs EditingBehavior::shouldAllowSpelling[...] to return false
> both of these otherwise want EditingUnixBehavior.

First off, it's unclear to me why Chromium Linux wants to return false in shouldAllowSpellingSuggestionsWithoutSelection. As far as I can tell, nobody from Chromium port voiced such need: https://bugs.webkit.org/show_bug.cgi?id=103520

We need to see if we can make Chromium Linux behave like the rest of Linux ports.

> The approach that I would prefer/think is best would be to modify EditingBehavior such that each of the behaviors can be set individually by an embedder (like WebCore::Settings). We could keep the EditingBehaviorTypes and have a constructor (or setter) that takes an EditingBehaviorType and sets all of the behaviors based on that EditingBehaviorType. Then if a particular port (chromium-linux or chromium-android, for example) wanted different behavior for a single function, they could initialize the EditingBehavior based on a platform and then change only those (few) functions/behaviors that they wanted.

The whole point of editing behavior was so that we didn't have to add a setting for each new editing behavior we want. Given that, I don't think making everything configurable by each port appears to defeat the point of having this class. We might as well as use settings at that point.

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