This was sort of what I was concerned with. It indicates that ChromeVox should probably have its own test target, since it is trying to test the surrounding environment. Pulling chromevox into browser tests would limit our ability to test chromevox end to end in the future.
Editing tests are always going to be sensitive to layout and that's actually good because that's what we're really testing.
The problem appears to be the width of "fi" in "first" vs. "se" in "second". Changing the test to use "123" and "456" makes things pass, because you can rely on digits having the same width.
I doubt the test actually want to assert that going down by 1 line from "fi" puts you at a particular character position in the string "second".
Owner: jamescook@chromium.org Status: Started (was: Untriaged)
I have a fix.
The test puts a text cursor after the second character of the phrase "first line" then goes down by a line and relies on the caret appearing after the second character of "second line". This depends on the exact character widths, but isn't important to the test.
No other chromevox tests appear to be sensitive to font config.
I doubt the test actually want to assert that going down by 1 line from "fi" puts you at a particular character position in the
I don't it does either, but it does want to have a sane baseline. If we actually incorrectly report the selection (which happens more often than you'd expect), we would want to catch that.
Comment 1 by dtseng@chromium.org
, Oct 23