Steps to reproduce the problem:
1. Create a very simple Android app with WebView control. In layout XML use android:importantForAccessibility="noHideDescendants" for your WebView control. Load some very simple text content into it. Activate TalkBack, start the debug build of the app.
2. Connect to the device or emulator from a desktop Chrome with chrome://inspect, see the content of the WebView. 
3. Under head - script note that a bunch of JavaScript code was added by TalkBack despite setting the WebView as "not important for accessibility. Some of these scripts are also executed, waiting memory and processor cycles, battery. If long content is loaded into such WebView, it may take minutes to process, even though the result of this processing is never used. This makes app unresponsive for minutes at a time.

What is the expected behavior?
Do not load TalkBack JavaScripts and do not try to execute them, when android:importantForAccessibility="noHideDescendants" is used. This was the default behavior in Chrome 65 and older WebView versions.

What went wrong?
TalkBack JavaScript code loaded and executed without any need, causing the system hang for long minutes if text loaded into webview is long (say about 64 KB)

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 66.0.3359.126  Channel: stable
OS Version: 4.1 - 8.1
Flash Version: n/a

Can prepare a simple demo project, but the issue should be obvious to developers. This is a big problem for some apps that are popular among blind and visually disabled users, that need to load long chunks of text (e.g. ebook chapters etc.), and where alternative ways of navigating such text were developed. TalkBack unnecessary JavaScript processing of text causes long delays (several minutes on older phones) before TalkBack and the app become responsive.