Thanks for filling the issue...

Unable to reproduce the issue on reported chrome 72.0.3603.0 using Mac 10.14.0. Attaching screencast for reference.
Steps:
-----
1. Launched reported chrome 
2. Navigated to https://accounts.google.com
3. Entered text and removed the text
As we have not seen flickering 

@Reporter: Could you please check the attached screen cast and please let us know if anything missed from our end and verify this issue with fresh profile that is not having any extensions and apps or reset all the flags. Let us know whether issue still persists.

Deleted: 901897.mp4 718 KB

	901897.mp4 718 KB View Download

Sorry about miscommunication. The issue is only in Chromium. Not Chrome. Please take a look at the attached screenshot.

Deleted: Screen Shot 2018-11-06 at 9.03.08 AM.png 424 KB

	Screen Shot 2018-11-06 at 9.03.08 AM.png 424 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Interesting.  I confirmed with Chromium as of today, and couldn't reproduce with today's canary.

To what extent do we need to fix Chromium bugs if Chrome is working fine? Maybe there's something different related to GPU/Software in Chromium vs. Chrome? Different flags or field trials?

I would look into the latter in particular.

vmpstr@, could you please look into this, or at least reproduce it. All I can think of is a failure to clear some display list. But honestly it seems like it has more to do with API access or something like that where it's always set up in Chrome but might not be in chromium.

I can't reproduce on linux on Chromium	72.0.3610.0 (Developer Build) (64-bit), so I'm guessing it's a mac only bug.

Unfortunately, I don't have a macbook today, I'll try again tomorrow. It's possible that this is also being caused by cc if it's reusing a texture for partial invalidation where it's not supposed to use it or something along those lines. Other than different layerization, I'm not sure how else the paint system would diverge on a specific platform.

+ericrk, is this something you can reproduce and just quickly check that the texture use is all correct?

This seems to be a consequence of partial raster and oop raster. Specifically, I think the oop raster earlies out at the time before clearing the previous partially rasterized texture. I'm working on a fix

Note that I don't think OOP raster is "enabled by default" which is why probably some channels have it and some don't

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

commit ac3cbdf51a653088dfd3ee377192f63510b66e0b
Author: Vladimir Levin <vmpstr@chromium.org>
Date: Thu Nov 15 16:25:48 2018

OOP: Ensure to clear tiles when needed even if no display items.

This patch ensures that we don't early out under requires_clear when
doing OOP raster. If we early out, and we were doing a partial raster,
then we might end up with previous content on the texture.

R=enne@chromium.org, piman@chromium.org

Bug:  901897 
Change-Id: I9e74e7f5b04d14385b733df50b08e027f5e6d1d3
Reviewed-on: https://chromium-review.googlesource.com/c/1335662
Commit-Queue: vmpstr <vmpstr@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608391}
[modify] https://crrev.com/ac3cbdf51a653088dfd3ee377192f63510b66e0b/cc/paint/oop_pixeltest.cc
[modify] https://crrev.com/ac3cbdf51a653088dfd3ee377192f63510b66e0b/gpu/command_buffer/client/raster_implementation.cc

The NextAction date has arrived: 2018-11-26