Layout Test editing/spelling/spellcheck-editable-on-focus.html is flaky

Layout Test editing/spelling/spellcheck-editable-on-focus.html is flaky

Do not use 'shouldBe' helper to check markers when asynchronous spell checking
is being used. Even if they should not have markers, we need to wait for them.

According to r158283 use shouldBecomeEqual. However, the spelling markers are
verified synchronously. As a result, we will check next marker only when the
current one appears. It allows us to set focus on elements and make sure
that it does not influence the previous expectations (where markers should not be
present).

BUG=278318
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=161840

[grzegorz, 2013-10-01 12:32:55]

Hi,

According to
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40...
the test is always passing. However, I found out issue that could influence on
its flakiness.

[tony, 2013-10-01 17:22:09]

LGTM

[grzegorz, 2013-11-12 14:12:22]

Hi,
This commit has been waiting for commit since month. In the meantime, it has
been removed from TestExpacations as it started passing. However, I wouldn't
verify markers synchronously via 'shouldBe' when spellchecikg uses async patch.

I'd appreciate if you could have a look at it.

[eseidel, 2013-11-12 15:00:10]

I don't think this works. You can't focus 3 elements at once. Each focus call
will steal focus from the previous focused node. This new test only tests one of
the 3 cases I think

[eseidel, 2013-11-12 15:00:53]

Not lgtm

[grzegorz, 2013-11-12 15:43:37]

On 2013/11/12 15:00:10, eseidel wrote:
> I don't think this works. You can't focus 3 elements at once. Each focus call
> will steal focus from the previous focused node. This new test only tests one
of
> the 3 cases I think

Focus on those editable elements will trigger spell checking for them. As a
result, misspellings will be marked even if focus has gone to another element
(apart from input fields but they are tested by other test). What I wanted to
achieve by doing this was to use shouldBecomeEqual() to wait for markers instead
of its synchronous version shouldBe().

[eseidel, 2013-11-12 15:48:53]

I see.  Well, that's something I can't say I know much about. :)

If others are OK with this, I am.  Sounds like Tony thought the test was OK.

You should probably get a new lg on your latest patch, but I retract my not-lg.

[tony, 2013-11-12 17:39:51]

Still LGTM.

grzegorz: If you have an LGTM, you can commit the change yourself using the
"Commit" checkbox.  See http://www.chromium.org/developers/testing/commit-queue
.  Normally, reviewers don't commit code for you unless you ask.

[commit-bot: I haz the power, 2013-11-12 17:40:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/g.czajkowski@samsung.com/25507002/5001

[grzegorz, 2013-11-12 17:45:37]

On 2013/11/12 17:39:51, tony wrote:
> Still LGTM.
> 
> grzegorz: If you have an LGTM, you can commit the change yourself using the
> "Commit" checkbox.  See
http://www.chromium.org/developers/testing/commit-queue
> .  Normally, reviewers don't commit code for you unless you ask.

Thanks for the info. I wasn't aware of this. I've thought that only committers
have permissions to land the changes (Webkit habit).

[commit-bot: I haz the power, 2013-11-12 18:48:03]

Change committed as 161840