Input slow and high CPU on large forms

[eeaquino]

When having a large table with several inputs there is a noticeable lag in the input box. Also CPU usage stays at 12.5% table is about 1500 rows.

Commenting out in line 250 bootstrap.css stopped the issue :

a,
area,
button,
[role="button"],
/*input:not([type="range"]),*/
label,
select,
summary,
textarea {
  -ms-touch-action: manipulation;
      touch-action: manipulation;
}

[patrickhlauke]

In which OS/browser do you see this happening?

related: as most browsers now do the 300ms optimization for width=device-width (see https://patrickhlauke.github.io/touch/tests/results/#suppressing-300ms-delay) we can probably consider dropping this directive.

[Herst]

Is that a known browser bug?

[kamelkev]

Above issue is affecting us as well.

We have some legacy administrative forms that can contain up to 5000 divs, each containing an input or select and a button element. Loading this page brings Chrome to a crawl. A full pageload in Firefox take approximately 6 seconds, in Chrome it takes approximately 50s.

Commenting out the entire rule solved the problem, similar to what @eeaquino noted, but in our case we have input fields and sometimes select fields.

The pageload behavior for Chrome is pretty interesting. When the above rule is in place the 'Content Download' portion of the waterfall is approximately 45s. However when the rule is commented out that drops to 241ms.

I did not know that CSS rules could affect document transport? This behavior can only be seen on Chrome. Most notably I don't see it on Safari.

My guess is most people don't see this issue because they have shorter documents - but the performance contrast is... stark. See attached screenshots.

Waterfall with the rule in place:
https://imgur.com/PqY6JdC

Waterfall with the rule removed:
https://imgur.com/VnikdCT

Please let me know if you have any additional questions relating to this. We are happy to help however we can.

[Herst]

Please someone report this to the Chromium team: https://crbug.com/

[patrickhlauke]

we'd need a reproducible test case. i just tested a document with 5000 <div><input><button>foo</button></div> with and without the touch-action directive, using a local server on my machine, and chrome loaded both the same with no noticeable delay nor difference.

[eeaquino]

https://codepen.io/anon/pen/aEqReQ

input must be type text, or some of the other types that have the css rule applied.

[patrickhlauke]

filed https://bugs.chromium.org/p/chromium/issues/detail?id=800522 /cc @mustaqahmed @RByers @NavidZ

in the meantime, i think we can consider removing the touch-action directive, as for mobile-optimized viewport sites we're only missing out fast click behavior in iOS when the user actively zoomed in, and on desktop with touch it's only the Windows 10 / Microsoft Edge case that would incur the tap delay.

[kamelkev]

@patrickhlauke Spent some time working on a reproduction. Part of the problem appears to be that we start returning a response from our application server before all of the content is generated. As a result the timing seen is quite different from what you'd see with a static document, even a static document that exactly matches the final content generated by the app server.

I'm thinking that the touch-action property is very sensitive to response timing, iteratively executing a repaint/reflow every Xms.

I've been using the Chrome profiler, but for this particular set of circumstances the tool never finishes. Every 400ms "update layer tree" executes, seemingly forever. Pretty interesting.

[kamelkev]

@eeaquino Thank you for your sample. This seems to produce the identical result I'm seeing with my response.