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

commit 462ca4d55b56fa45f85ec613e73d3e52d306b82d
Author: Eric Karl <ericrk@chromium.org>
Date: Sun Jan 14 01:27:20 2018

Reset texture bindings when unlocking discardable textures used by Skia

Before we unlock a discardable texture in CC, we tell Skia to flush
pending IO on the texture. However, this doesn't clear any outstanding
texture bindings involving this texture which Skia has created.
Unfortunately, the act of unlocking in CC does clear these bindings on
the GPU service side, leaving Skia's understanding of GL state incorrect.
This leads to errors if we quickly re-lock this texture and use it in
Skia, as Skia  will assume the texture is still bound, won't re-bind
it, and we'll hit an error when trying to draw.

This change resets Skia's texture bindings whenever we unlock textures,
preventing this scenario.

R=khushalsagar

Bug:  801769 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I4cdfa58b6696e95fb40fa7d48a8fec3f09e8398e
Reviewed-on: https://chromium-review.googlesource.com/866111
Commit-Queue: Khushal <khushalsagar@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#529179}
[modify] https://crrev.com/462ca4d55b56fa45f85ec613e73d3e52d306b82d/cc/tiles/gpu_image_decode_cache.cc

This bug is very likely to cause users to have missing images during page display, and is a regression. The fix is very targeted / safe, and I'd like to merge to M64.

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

Thanks for the details.
Eric - can you please confirm this bug is well tested in canary and extremely safe? This is our last M64 Beta tomorrow, so would like to ensure only critical and absolutely safe merges are in.

abdulsyed@, The fix should be extremely safe, and was tested on ToT. I'll spend some time this morning doing additional testing on today's Canary to verify that everything is as expected and will update here. when is the merge cutoff for tomorrow's beta?

Thanks! I'm pre-approving this merge for now (branch:3282). Can you please merge after you're done with additional testing/verifications and if things look good? Please merge before 5PM PDT to make it to tomorrow's release. 

After additional testing, we don't believe this bug hittable with the code that exists in M64 (repro case was a WIP CL on ToT, which was believed to generalize to current code, but turns out to not do so). Removing merge request.