The test is expecting the emulation of a tap on specific pieces of text on a page. That tap should trigger the interpretation of the text around it to try and find a valid geo address, and that should then launch an intent with the correct full address. But the intent is never fired (or not detected; although that seems less likely) so a timeout exception is raised 10s later. Looking at the output logs nothing jumps to my eyes as a potential root cause.

3 months ago this test (and a few others in the same file) has been tagged with retry-on-failure [1] so this is already considered flaky for a while. And a some days after that the flakiness dashboard picked it up.

This is the test failure log:

org.chromium.content.browser.AddressDetectionTest#testAddressLimits (run #1):
java.util.concurrent.TimeoutException: waitForCallback timed out!
	at org.chromium.base.test.util.CallbackHelper.waitForCallback(CallbackHelper.java:183)
	at org.chromium.base.test.util.CallbackHelper.waitForCallback(CallbackHelper.java:194)
	at org.chromium.content.browser.ContentDetectionTestBase.scrollAndTapExpectingIntent(ContentDetectionTestBase.java:72)
	at org.chromium.content.browser.AddressDetectionTest.testAddressLimits(AddressDetectionTest.java:68)
	at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:214)
	at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:199)
	at android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:192)
	at org.chromium.content_shell_apk.ContentShellTestBase.runTest(ContentShellTestBase.java:256)
	at org.chromium.base.test.BaseTestResult.runParameterized(BaseTestResult.java:161)
	at org.chromium.base.test.BaseTestResult.run(BaseTestResult.java:124)
	at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:191)
	at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:176)
	at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:555)
	at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1879)


CCing hush@ who was the last person that made a meaningful change to the tested logic in content/common/android/address_parser.cc (almost 2 years ago though) [2].

Also adding a few potentially related components to have more eyes at this that might have a better clue of what's going on.


[1] https://chromium.googlesource.com/chromium/src/+/0abf7f1128d6e42aa565e4547763c120659cd8c6

[2] https://chromium.googlesource.com/chromium/src/+/f406672b3f713ca0fdbfe38656b18dae285262c6

mvanouwerkerk@chromium.org,  timvolodine@chromium.org:
you are listed as owners for geolocation related APIs. Can you guys take a look?

This seems to be some kind of US address detection mechanism, perhaps built into Android itself? This is not the Geolocation API.

I'm gonna unassign myself so that someone in WebView can take a look at this.

The n5x_swarming bot is very unhappy today, there are a bunch of other failures that look very similar. So this is likely not related to this particular test at all.

This one still flaked today as reported by tryflakes:
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_swarming_rel/builds/90914

Interesting question though.. where is that failure on the flakiness dashboard?
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=content_shell_test_apk%20(with%20patch)&tests=testAddressLimits

Seems like flakiness dashboard should go back further, and would have displayed that flake, but it doesn't for some reason..

50 iterations locally without issue, and looking at frequency on tryflakes, that's totally expected, hmm...

Detected 3 new flakes for test/step "org.chromium.content.browser.AddressDetectionTest#testAddressLimits". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyTgsSBUZsYWtlIkNvcmcuY2hyb21pdW0uY29udGVudC5icm93c2VyLkFkZHJlc3NEZXRlY3Rpb25UZXN0I3Rlc3RBZGRyZXNzTGltaXRzDA. This message was posted automatically by the chromium-try-flakes app. Since flakiness is ongoing, the issue was moved back into Sheriff Bug Queue (unless already there).

Detected 3 new flakes for test/step "org.chromium.content.browser.AddressDetectionTest#testAddressLimits". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyTgsSBUZsYWtlIkNvcmcuY2hyb21pdW0uY29udGVudC5icm93c2VyLkFkZHJlc3NEZXRlY3Rpb25UZXN0I3Rlc3RBZGRyZXNzTGltaXRzDA. This message was posted automatically by the chromium-try-flakes app.

Leandro, I'm aware this test probably wasn't written by you, but I'm not sure about the history of this code prior to your upstream commit (crrev.com/161101). Are you able to take a look, or do you know someone else who can?

This looks related to content intent detection, which is being removed according to  issue 664307 . Theresa, does anyone still care about AddressDetectionTest?

-leandrogracia who no longer works on chrome

Yes - we decided to leave the code for content detectors in, but disabled for a release. If we decide to re-enable them for any reason we need to be sure that they are still working correctly.

OK, thanks. Since this has an owner, I'm going to remove this from the sheriff queue. A CL to disable the flaky test should also land shortly.

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

commit 8fb83f45f0bc9322eed96b6415a285ff130cee55
Author: samuong <samuong@chromium.org>
Date: Tue Jan 03 18:48:34 2017

Disable AddressDetectionTest.testAddressLimits, which is flaky.

BUG=671647
TBR=qinmin@chromium.org
CC=twellington@chromium.org

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

[modify] https://crrev.com/8fb83f45f0bc9322eed96b6415a285ff130cee55/content/public/android/javatests/src/org/chromium/content/browser/AddressDetectionTest.java