[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 #20 from Ryosuke Niwa <rniwa at webkit.org>  2013-01-18 15:45:00 PST ---
(In reply to comment #19)
> (From update of attachment 183554 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=183554&action=review
>
> >> LayoutTests/platform/chromium-android/TestExpectations:114
> >> +fast/writing-mode/flipped-blocks-hit-test-line-edges.html [ WontFix ]
> > 
> > It doesn't seem like a good idea to regress these tests. If anything the said chromium issue should be fixed first.
> 
> These tests use internals.settings.setEditingBehavior("somePlatform") and then depend on EditingBehavior::shouldMoveCaret[...] to behave according to that platform's editing behavior. This is not the case if it is #ifdeffed for chromium-android to always return false. So I see 3 options:
> 
> 1. Rebaseline the tests for the new behavior. I didn't like this because these tests use testPassed and testFailed and the new behavior has a lot of FAILs (i.e. for all the parts of the test that assume mac or linux editing behavior). That makes the expected behavior look wrong and I don't know of a good way to notify someone looking at that new expected behavior that the FAILs are actually "PASSes".
> 
> 2. Change the test to detect that it's actually on chromium-android and then understand that they won't get mac or linux behavior for shouldMoveCaret[...] and change all their checks accordingly. With this approach, chromium-android would still need new baselines for these tests, but the expected behavior wouldn't look like it was wrong. However, I don't really like the idea of such an invasive change to the tests just to support this odd chromium-android behavior.
> 
> 3. Let the tests fail and mark them WontFix. This is clean and we can have a notification at the same point saying what's wrong with the tests and when they should be fixed. However, it's major failing is that chromium-android loses the coverage of these tests.
> 
> I did (1) and was working on (2) when I decided to go with (3). You know better than me, though, so if you'd prefer one of the other 2 options (or something else I didn't list) that'll be fine with me.

Option 1 is what we do in WebKit. When you land thrse changes, just mention that FAILs are expected.

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