No, I don't think it's related.  This bot looks like it was flaky before.

cc'ing johnme@ who maintained this bot before (and might know the current maintainer)

Yeah, that bot has definitely been flaky for a long time, but that build was the first time I've seen this particular layout test failing (svg/overflow/overflow-on-outermost-svg-element-in-xhtml-defaults.xhtml
). That being said, I wouldn't be at all surprised if it's unrelated.

^ and I didn't go through every single previous failure, so I may even be wrong about that. Thanks for taking a look

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

commit 9510363bb4235124e23e59641440651c2b0fddd9
Author: kjellander <kjellander@chromium.org>
Date: Tue Apr 12 13:25:32 2016

Ignore failing svg/overflow/overflow-on-outermost-svg-element-in-xhtml-defaults.xhtml

Its failures are making sheriffing hard.

BUG= 602268 
TBR=johnme@chromium.org

Review URL: https://codereview.chromium.org/1878203003

Cr-Commit-Position: refs/heads/master@{#386665}

[modify] https://crrev.com/9510363bb4235124e23e59641440651c2b0fddd9/third_party/WebKit/LayoutTests/TestExpectations

@aelias: Are you sure this isn't due to the changes to visualViewportSuppliesScrollbars in your patch? The only diff[1] is the length of the overlay scrollbar.

@schenney: Do you know who owns SVG these days? This is one of only ~10 SmokeTests (layout tests that get run on Android), so it would be nice to keep it running.

The test says "You should not see any scrollbars", but I see that both the before and after screenshots[1] have overlay scrollbars (varying only in the length of the scrollbar), so it seems both are wrong :-|

[1]: https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Android__Nexus4_/45247/layout-test-results/results.html

This looks like a dupe of  issue 541601 , but since this seems to have some activity, I'll dupe that one to this one.

Regarding the "should see scrollbars (or not)" issue I think this might be complicated by the dimensions of the SVG matching those of the viewport (this test uses an inline SVG in XHTML, as one might guess from the filename.), so the scrollbars could be (likely is) those of the XHTML document.

 Issue 541601  has been merged into this issue.

Hmm, I think if my visualViewportSuppliesScrollbars change had a problem, we would see a very large number of test failures, not just this one.

It looks from the dup that this test has been flaky for a long time, and then in https://chromium.googlesource.com/chromium/src/+/b2eda0ef5806332223af383ded63908712e6a155%5E%21/#F0 it was reenabled by accident.  I'm guessing the pre-existing flakiness was also in the scrollbar although the test output history is now lost.

I'll make a change to the test CSS to simply hide the scrollbar since it's not what's intended to be tested by it.

Ah, sorry, the test is actually intending to test that the scrollbar is not shown, so the baseline has been wrong since it was reenabled accidentally in December.  So it would require digging in to figure out what's going on with the overflow sizing -- maybe something like an off-by-one rounding error -- and I don't have the cycles to investigate that.

johnme@, instead of overfocusing on this one, can we simply switch to a non-flaky test to be part of the smoke suite?  I assume our intent is simply to test some kind of basic SVG content?  How about svg/in-html/circle.html instead?

On a further look, let me propose "svg/as-image/svg-as-image.html" as the smoke test since it's a rectangle, and less likely to be brittle to antialiasing than the circle.

Since build #45783 from Apr 25 17:03 [1] this bot started mostly succeeding: 1 failure for ~5 successful runs. And the failure happening doesn't look like a coding issue (but still could be). I'm going to file a new issue for that one.

I will not close this issue because there's still work/reply expected from johnme@ in regards to changing the smoke tests selection. Please mark as fixed when done with that.

[1] https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Android%20%28Nexus4%29/builds/45783

The problem I mentioned above is being tracked in issue 598449.

There doesn't seem much point replacing svg/overflow/overflow-on-outermost-svg-element-in-xhtml-defaults.xhtml with svg/as-image/svg-as-image.html, since that functionality is already covered by svg/as-image/svg-canvas-not-tainted.html.

The smoke tests were mainly selected by peter and dpranke based on speed, rather than to optimize coverage. So instead perhaps we can just remove this: https://codereview.chromium.org/1922843003

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

commit d44c1ceb457056687627ad0addbb7398d8e8d0de
Author: johnme <johnme@chromium.org>
Date: Tue Apr 26 18:04:17 2016

Remove a flaky Android layout SmokeTest

Removes
svg/overflow/overflow-on-outermost-svg-element-in-xhtml-defaults.xhtml
from the list of SmokeTests, since it's flaky on Android and doesn't
seem to be maintained.

BUG= 602268 

Review URL: https://codereview.chromium.org/1922843003

Cr-Commit-Position: refs/heads/master@{#389819}

[modify] https://crrev.com/d44c1ceb457056687627ad0addbb7398d8e8d0de/third_party/WebKit/LayoutTests/SmokeTests

Thanks!  I think we should really be trying to maximize coverage-per-speed ratio, so removing this test seems fine.