My change doesn't concern Windows. it's chromeos/linux only.

Update:
as per comment no #1 reassigning issue
 
Narrow bisect:
https://chromium.googlesource.com/chromium/src/+log/6ee0391693f4aa448833d50e2c61c8d86f884441..a1dee391232d54b3f32cb7db0518bfc84b88352c?pretty=fuller&n=10000

Suspect: r563676?

samans@: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thank you..

Adding release blocker label for this issue.Please reduce priority or remove if not the case.

Thank You!

This CL was reverted in 563676 and relanded in 564691. I can see the same bug even in the builds that contain the revert.

Ligi, can QA team do a bisect on this?

pranjali.mahabdi@ please provide the per revision bisect.

With respect to comment #6

Tried with per revision bisect and getting below error : 
Traceback (most recent call last):
  File "bisect_builds.py", line 1684, in <module>
    sys.exit(main())
  File "bisect_builds.py", line 1640, in main
    evaluator, opts.verify_range)
  File "bisect_builds.py", line 1033, in Bisect
    revlist = context.GetPerfRevList()
  File "bisect_builds.py", line 667, in GetPerfRevList
    revision_files = self.GsutilList(perf_bucket)
  File "bisect_builds.py", line 657, in GsutilList
    stdout = RunGsutilCommand(['ls', query])
  File "bisect_builds.py", line 250, in RunGsutilCommand
    raise Exception('Error running the gsutil command: %s' % stderr)

Tried with chromium bisect and getting same suspect :
https://chromium.googlesource.com/chromium/src/+log/6ee0391693f4aa448833d50e2c61c8d86f884441..a1dee391232d54b3f32cb7db0518bfc84b88352c?pretty=fuller&n=10000

Suspect: r563676 ?

Tried with other windows systems Win(7 ,8, 8.1 & 10) and able to reproduce the issue.

Please find the GPU details of the Win 7,8,10 OS

Deleted: win7 gpu.pdf 134 KB

win7 gpu.pdf 134 KB Download

Deleted: Win-8.1.pdf 144 KB

Win-8.1.pdf 144 KB Download

Deleted: Win-10 GPU.pdf 142 KB

Win-10 GPU.pdf 142 KB Download

Deleted: Canary_behaviour.mp4 586 KB

	Canary_behaviour.mp4 586 KB View Download

As per comment #7 untriaging this issue.Some one from Internals>GPU dev team could you please take a look in to this issue.

Thank You!

I'll take another look.

My CL is definitely not at fault. I can reproduce this way before my CL landed.

This bug only happens when passthrough command decoder is enabled. Assigning to geofflang@.

Removing ReleaseBlock-Stable because passthrough command decoder is just an experiment in canary and isn't going to ship with M69.

samans@, thank you for the update.

- 'RB-Stable' as per c#11.

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

commit 216b18af80890c27d26bf881c68ee59dac996027
Author: Geoff Lang <geofflang@chromium.org>
Date: Tue Jul 10 14:34:07 2018

Create a dummy texture when the mailbox is invalid in CreateAndConsumeTexture.

If glCreateAndConsumeTextureINTERNAL fails to find a mailbox, the client still
expects the texture ID to be valid.  If the texture does not exist, the ID could
overlap with another and display incorrect textures.

BUG= 851878 

Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I53cea969fcace7246ebce8fc193b3246f511fbc3
Reviewed-on: https://chromium-review.googlesource.com/1129464
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#573719}
[modify] https://crrev.com/216b18af80890c27d26bf881c68ee59dac996027/gpu/command_buffer/service/gles2_cmd_decoder_passthrough_doers.cc

Update:
Rechecked the above issue on Win(7,8,8.1,10) OS using latest canary build#69.0.3488.0 and issue is fix. Page does not distort after terminating GPU process.
please refer attached screencast for reference.

Thank You....

Deleted: Canary_behaviour.mp4 423 KB

	Canary_behaviour.mp4 423 KB View Download