I forgot to mention that even though that blank space appears there it looks like it is just a rendering issue(like a white veil) as the elements that are supposed to be there and are not visible but are still clickable

Unable to test this issue as there is no link to signup in https://repaircenter-dev.mymitchell.com/ui/main/ . 

@Reporter: Could you provide sample credentials to check this issue from TE end. This would help in triaging the issue in better way.

Thanks!

There have been some similar bugs but I can't find an exact match. The log of changes from 64.0.3282.119 to 64.0.3282.140 do not show anything obvious, so I suspect the change goes much farther back than that.

We do need to be able to sign in to be able to reproduce the problem, or you need to provide us with a public test case.

Hi guys,

You can use the following credentials to reproduce it:
  -Username: chromeTest
  -Password: password 
In order to reproduce the problem with this user you need to Resize your Chrome to 1300pxx441px (the width is not important it happens with any width over 1281px the height is important, it is reproducible with any height lower than 441px)
Once you login click on the only item in the list (or just paste the url "https://repaircenter-dev.mymitchell.com/UI/MAIN/#/job-overview/63ba0bdc-cb88-4eb4-d750-137cf871d508" and it will navigate straight)
Once you are in the job page scroll down to the botton of the page and at some point you will size that white space

See the attached video to see how to reproduce it if you have any doubts

Deleted: 2018-02-12_09h16_30.mp4 546 KB

	2018-02-12_09h16_30.mp4 546 KB View Download

Able to reproduce this issue on reported version 64.0.3282.140, on latest beta 65.0. 3325.51 and on latest canary 66.0.3345.0 using Mac 10.13.3, Ubuntu 14.04 and Windows 10 with credentials given in comment#5.

Good Build: 64.0.3249.0
Bad Build: 64.0.3250.0

You are probably looking for a change made after 511578 (known good), but no later than 511579 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/8c7e87211aa02c337795f9260705c47d8a277e5b..eeaf4c2326de12c9b36324a805e46ab933057e54

Reviewed-on: https://chromium-review.googlesource.com/735751

Suspecting same from changelog.

@sunxd: Please confirm the bug and help in re-assigning if it is not related to your change. Adding RB-Stable for M-64. Please change if not the case.

Can we target this for M65? There haven't been widespread issues about this. 

I think so. This seems a duplicated bug with  issue 808372 . My patch for that bug fixes this issue as well.

Hi again,
It looks like the mentioned bug has been fixed/is going to be fixed as part of the M65. I tested it with the beta Version 65.0.3325.73 and it's still reproducible, I understand the bug fix is not included in that version, could you please confirm?
Also, do you have any expected date that you can share when the version where you plan to include the bug fix is being released?
Thanks in advance, Rafa

Sorry the bug fix is still in code review. I will update this thread once that's landed.

Friendly ping to get an update on this issue as it is marked as release block stable.
Thanks.!

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

commit cf699d7fef4e3f03743cc916209c7ebff5dc7b7a
Author: sunxd <sunxd@chromium.org>
Date: Tue Feb 20 16:36:15 2018

cc: Make solid color mask layer ignore occlusion

Mask layer's occlusion is actually its render surface's occlusion in the
contributed parent surface space.

However, when tiling a solid color mask layer, we used to adopt the logic
from normal picture layers: overwrite the occlusion's transform with the
layer's draw transform. This is problematic because mask layer's draw
transform is to the render surface that owns the mask. In this way, we
can generate the wrong visible quad rect and result in blanks when
rendering.

Since solid color mask layer does not do anything but cannot be fully
avoided in the current code base, we should never apply an occlusion to
it. Any occlusion to the masked content can still take effect by
applying itself to the owning render surface.

Bug:  811143 ,  810820 ,  808372 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I821492c107c2abadb9b9e6986369c9f6262d0ad4
Reviewed-on: https://chromium-review.googlesource.com/916625
Commit-Queue: Xianda Sun <sunxd@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537794}
[modify] https://crrev.com/cf699d7fef4e3f03743cc916209c7ebff5dc7b7a/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/cf699d7fef4e3f03743cc916209c7ebff5dc7b7a/cc/layers/picture_layer_impl_unittest.cc

Hello can you verify if this is fixed in Canary and if so we can merge this bug into 808372.

Sorry the new patch is not baked in canary yet, maybe try it after a few hours.

M65 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Merge has to happen latest by 4:00 PM PT Monday (02/26/18) in order to make it to last M65 beta release next week. Thank you.

Pls update the bug with canary result tomorrow.

Verified the fix on Windows 10, Ubuntu 14.04 and Mac 10.13.1 using latest chrome version #66.0.3352.0 as per the comment #5.
Attaching screen cast for reference.
Observed that, while scrolling the page text rendered normally with out any white space.
Hence, the fix is working as expected.
Note: Able to reproduce the issue on reported chrome version. 
Adding the verified labels.

Thanks...!!

Deleted: 810820.mp4 6.0 MB

	810820.mp4 6.0 MB View Download

The NextAction date has arrived: 2018-02-22

Thank you so much guys.Do you guys have any planned date/timeframe to realease M66? I don't need an exact date just an approximation to keep our users informed

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

commit 8b24864f6fb735764abf5e7f2cfd5d269a881b3b
Author: sunxd <sunxd@chromium.org>
Date: Thu Feb 22 17:57:33 2018

cc: Make solid color mask layer ignore occlusion

Mask layer's occlusion is actually its render surface's occlusion in the
contributed parent surface space.

However, when tiling a solid color mask layer, we used to adopt the logic
from normal picture layers: overwrite the occlusion's transform with the
layer's draw transform. This is problematic because mask layer's draw
transform is to the render surface that owns the mask. In this way, we
can generate the wrong visible quad rect and result in blanks when
rendering.

Since solid color mask layer does not do anything but cannot be fully
avoided in the current code base, we should never apply an occlusion to
it. Any occlusion to the masked content can still take effect by
applying itself to the owning render surface.

Bug:  811143 ,  810820 ,  808372 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Change-Id: I821492c107c2abadb9b9e6986369c9f6262d0ad4
Reviewed-on: https://chromium-review.googlesource.com/916625
Commit-Queue: Xianda Sun <sunxd@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#537794}(cherry picked from commit cf699d7fef4e3f03743cc916209c7ebff5dc7b7a)
Reviewed-on: https://chromium-review.googlesource.com/931903
Reviewed-by: Xianda Sun <sunxd@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#549}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/8b24864f6fb735764abf5e7f2cfd5d269a881b3b/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/8b24864f6fb735764abf5e7f2cfd5d269a881b3b/cc/layers/picture_layer_impl_unittest.cc

Hi rafa.lagares@, thanks for the feedback. I have merged the patch into M65 and I think it will be released on Mar 6.

Pls mark bug as fixed if nothing is pending. Thank you.