When there is a huge amount of input fields on a page, the typing performance is very bad. Such pages do exists, for example string translation backends with collapsable fieldsets for each single set/page to translate. In this cases the PHP backend even needs to increase the max_input_vars. I created a page that shows how even on a current MBP Retina, performance is terrible. https://gist.github.com/mcdado/35d8ccb3d5c165c28ed6f70ffca68948 Also, after a while fans start spinning up and they wind down only when the backlog of typed characters are displayed. I made a video here comparing performance with latest Firefox 48, Chrome 50, and Safari Technnology Preview 3: http://cl.ly/0v1g3a3P3h3o I hope this helps!
This seems to be happening due an issue in Safari's form auto-fill mechanism. Apple people can see <rdar://problem/8555317> for more information.
Any news about this? Performance still sucks in this use case.
Created attachment 284093 [details] Test case 1. Input any high number 2. Click GO 3. Try to type in the text fields What do i see? It's extremely slow and laggy. What is the expected result? Fast and snappy.
Still an issue in Safari Technology Preview release 26.
<rdar://problem/31234059>
The correct radar number is <rdar://problem/21705952>
rdar://problem/21705952 was used to fix an issue on https://www.boe.ca.gov/trace/report/ on pages having <select>s with lots of options. This bug now corresponds with rdar://problem/31460933.
Since release 29 of Safari TP things seems to be much better! Still there is an initial delay when starting to type, and changing fields also has a noticeable delay.
Safari 11 handles the attached test-case better but only because the input fields don't have a "value" attribute. Adding the attribute value="123" to the input fields immediately makes the test-case unusably slow even in Safari 11. Could somebody please have a look at this issue?
It‘s a bit frustrating to have this in the WebKit bug tracker since there is no problem in WebKit clients other than Safari. I believe this is a Safari problem and should not be tracked with an open WebKit bug.
This is actually: <rdar://problem/21705952>