Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 14.04 using chrome reported version #65.0.3325.181 and latest canary #68.0.3397.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Can reproduce. I needed to resize the text area so it had a scrollbar.

Just to show you this happens with non-textarea elements too:
http://www.woodpecker.hu/temp/disappearing_table/Darusin_disappearing.html

All I do is change the innerHTML of a div when you click the button.

I tried stripping the example code of any unneccesary stuff, but the content and structure might be more compilcated then needed for this example.

Should I file a seperate bug report?

Deleted: disappearing_table.zip 24.7 KB

disappearing_table.zip 24.7 KB Download

Possible workaround until bug is fixed:

1. TextArea, using javascript and jquery:
function redrawElement(id) {
    var opacity = document.getElementById(id).style.opacity;    
    if(opacity == null || opacity == '' || opacity == 1) document.getElementById(id).style.opacity = 0.99;
    else document.getElementById(id).style.opacity = (parseFloat(opacity) + 0.01);          
}

window.addEventListener('load', function() { 
  jQuery('textarea').bind('keyup input', function(i, e){redrawElement(this.id);});   
});

2. Disappearing table after setting innerHTML:
 
//Do this after setting innerHTML
element.innerHTML = ...;
element.style.transform = "translate3d(0, 0, 0)";

This is a paint bug, maybe root scrolling related?

After scrollbar disappears, the text area is positioned correctly (you can see
it in DevTools), but it does not paint. 

Very odd bug. Still happening on ToT with SPv175.

I see this issue has a Target-68 tag, so I just tested it with the chrome beta (version: 68.0.3440.25 64bit on Windows10). 
Both issues (textarea and table) persist. This is quite important for us, because the workaround I suggested ruins the table if we use a fixed table header. When do you think this will get fixed?

Found a hack-workaround to the dissapearing table (div). When setting innerHtml, do this:

element.innerHTML = newContent;
element.style.transform = "translate3d(0, 0, 0)";  
setTimeout( function() { 
  element.style.transform = "";
},10);
setTimeout( function() { 
  element.innerHTML = element.innerHTML;
},30);

The problem is probably that the object loses its shouldPaint bit on the 
FloatingObject, in combination with compositing (the workaround suggested
in comment 12 hints at this also).

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

commit 80f9e6e7a9840612aa15233920df0cc152ac014c
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Mon Aug 27 17:42:01 2018

[PE] Fix float painting under inline when self-painting status changes

Previously we did not consider non-BlockFlow elements in the containing block chain
between the float and the containing BlockFlow.

The code being fixed was introduced here, as part of solving a similar situation:
https://codereview.chromium.org/1661523002. It seems that the case of under-inline was not
skipped on purpose.

Bug:  833602 

Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I311ebb3d9f2172ed041bf0e6c8a583d89ae1a74a
Reviewed-on: https://chromium-review.googlesource.com/1188980
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#586301}
[modify] https://crrev.com/80f9e6e7a9840612aa15233920df0cc152ac014c/third_party/WebKit/LayoutTests/FlagExpectations/enable-slimming-paint-v2
[add] https://crrev.com/80f9e6e7a9840612aa15233920df0cc152ac014c/third_party/WebKit/LayoutTests/paint/float/float-under-inline-self-painting-change-expected.html
[add] https://crrev.com/80f9e6e7a9840612aa15233920df0cc152ac014c/third_party/WebKit/LayoutTests/paint/float/float-under-inline-self-painting-change.html
[modify] https://crrev.com/80f9e6e7a9840612aa15233920df0cc152ac014c/third_party/blink/renderer/core/layout/layout_block_flow.cc
[modify] https://crrev.com/80f9e6e7a9840612aa15233920df0cc152ac014c/third_party/blink/renderer/core/paint/paint_layer.cc

Good news, thank you!
One more question: what do you think, which version of Chrome will include this fix?

This seems to have been resolved for version: 70.0.3538.67
Thank you!