I think the test should live in site_per_process_interactive_tests.cc to being with since it relies on a keyboard input being passed on to the renderer to make the warning appear.

cc-ing vabr@ since he might also be working on similar tests.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9febb1f84922d7307712a044550c9ad0640b64d3

commit 9febb1f84922d7307712a044550c9ad0640b64d3
Author: ekaramad <ekaramad@chromium.org>
Date: Fri Mar 24 20:26:02 2017

Rename AutofillClientPositionWhenInsideOOPIF and move it to interactive tests

The test is currently flaking on different platforms. The failure is due
to incorrect boudns reported either through focused node change event,
or AutofillClient. The failure is hard to reporoduce locally and the
logs do not provde proper visibility as to what the root cause could be.

This CL will:
  1- Move the test from browser_tests to interactive_ui_tests.
  2- Renames the test move appropriately to address vabr@'s comment in the
  original CL https://codereview.chromium.org/2754033002 (we are testing
  a popup position and the term "AutofillClient" is incorrect).
  3- Adds a log when the test fails to show the focused node bouds as
  well as those reported by autofill client and give us a hint on which
  one might be incorrect.

BUG= 704943 , 686129 

Review-Url: https://codereview.chromium.org/2773823003
Cr-Commit-Position: refs/heads/master@{#459535}

[modify] https://crrev.com/9febb1f84922d7307712a044550c9ad0640b64d3/chrome/browser/chrome_site_per_process_browsertest.cc
[modify] https://crrev.com/9febb1f84922d7307712a044550c9ad0640b64d3/chrome/browser/site_per_process_interactive_browsertest.cc

The new test is still flaky. I believe the conversion of local coordinates to root coordinates for FocusNodeChanged is not doing its job properly. I am working on a way to wait for those transformations be valid which should theoretically fix the flake.

 Issue 705914  has been merged into this issue.

FYI: here is a flakiness trend of rerun at different build points on the Waterfall. It is still consistently flake.

https://findit-for-me.appspot.com/waterfall/check-flake?key=ag9zfmZpbmRpdC1mb3ItbWVy3QELEhdNYXN0ZXJGbGFrZUFuYWx5c2lzUm9vdCKmAWNocm9taXVtLmNocm9taXVtb3MvTGludXggQ2hyb21pdW1PUyBUZXN0cyAoMSkvMzYwNjAvaW50ZXJhY3RpdmVfdWlfdGVzdHMvVTJsMFpWQmxjbEJ5YjJObGMzTkJkWFJ2Wm1sc2JGUmxjM1F1VUdGemMzZHZjbVJCZFhSdlptbHNiRkJ2Y0hWd1VHOXphWFJwYjI1SmJuTnBaR1ZQVDFCSlJnPT0MCxITTWFzdGVyRmxha2VBbmFseXNpcxgBDA

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0d112490bb36604ec3f89951188d41fa111ea248

commit 0d112490bb36604ec3f89951188d41fa111ea248
Author: ekaramad <ekaramad@chromium.org>
Date: Tue Mar 28 22:08:35 2017

Modify a test to wait for compositor frame of OOPIF synced with CSS modifications in parent process

A recent test which compares bounds reported from a focused node inside
OOPIF against those reported for the same element throught AutofillAgent
falkes 15% of the time. The reason seems to be that transforming the
node bounds from child frame coordinates to root frame coordinates is
failing for the focused node (which comes first and before autofill's
update). The root cause is most probably a delayed updated in compositor
frame's metadata for the OOPIF.

This CL will modify the test so that we will wait for a known transform
to happen, that is, for a fixed position frame and no border,
transforming (0, 0) to root view should (almost) return the left and top
properties of the frame (which we set).

BUG= 704943 

Review-Url: https://codereview.chromium.org/2781903002
Cr-Commit-Position: refs/heads/master@{#460219}

[modify] https://crrev.com/0d112490bb36604ec3f89951188d41fa111ea248/chrome/browser/site_per_process_interactive_browsertest.cc

The test seems to have stopped flaking. Closing this bug.