Very slow focus-calls with Chrome 62

[markok]

Hi,

In our app when using Chrome, we are experiencing strange issues when focusing items on the screen. The focus() calls seem to be really slow. Included is a screenshot from performance profiler for a simple click on a ListGrid cell with an editor: What happens is that the editor pops up and then it takes almost two seconds before the cursor is in the editor and the user can type.

I stumbled on this reported bug in Chrome: https://bugs.chromium.org/p/chromium...tail?id=780834 it references the password manager and I have tried to workaround the issue by disabling the password management from my Chrome. It seems that it has no effect on my issue.

Is this a known issue and/or is there something that could be done to fix the issue SmartGWT side ?

Chrome: Version 62.0.3202.94 (Official Build) (64-bit) on Mac OS X
SmartGwt: 6.0p latest nightly (2017-12-02)

[Isomorphic]

There's no known issue here, and the timing you're showing doesn't make a lot of sense - it seems to show the native focus() function taking forever, but that function is instant and doesn't involve SmartGWT code.

We would suggest trying your timing on the live Showcase. If it's slow there, you probably have a browser extension or other special setting which is creating the issue.

[markok]

You are right, the issue is something in Chrome as the delay is in the native call. My question was in lines of if you have experienced this before or somebody else has contacted you with the same matter.

In any case, we debugged this further today and if somebody else bumps into this issue we have narrowed it down to the fact that the DOM tree just has too many visible elements around which seems to slow down Chrome. We suspect something has changed in Chrome in the latest version (62 probably) as the complexity of our app has not changed significantly. The focusing of elements seems to slow down, otherwise, we are not seeing any considerable slowdowns in our app.

Our application is quite complex. We have a number of "views" which the users change in and out frequently. We have implemented these views as Layouts which we change with our custom "CardLayout" implementation. Our implementation uses the common logic of moving the inactive views out of screen (something like setTop(-10000) & setTop(0)). We have implemented this logic sometime in the past because we had some issues with embedded iframes stealing events from widgets over them (even when the iframes we're hidden and sent to back with z-index, nothing seemed to work). Destroying and re-creating the views on the fly does not work as it is too expensive op in the way the users are using the app.

Anyway, we got this optimized a bit by calling .hide() and .show() in addition to the offscreen moving logic. This seemed to speed up Chrome considerably but still, it has some lag in it (for example by comparing it to Firefox Quantum which seems noticeably snappier). We suspect that the large DOM tree still has an impact in Chrome but hiding the elements speeds up the native focus function under the hood somehow.

And in addition, we tried the app by disabling all extensions and plugins from Chrome and it had no impact on the issue.

[Isomorphic]

This new Chrome issue is one of about 5 fairly serious issues discovered so far with 61/62. Hopefully this is a temporary thing and not a new trend for Chrome.

See the QuickStart Guide, architecture "Tips" section: there's information about deferred component creation and component lifecycles.

You *definitely* want lazily create views that the user is not immediately using, and you definitely want to hide components that aren't in use, and you should consider clear() for components that won't be reused soon.

As far as this particular Chrome bug's impact, if hide/clear isn't doing enough, you should also consider using hideUsingDisplayNone, which is sort of like a stronger version of hide() but not quite clear(). The docs tell you that there are issues in some browsers with this setting, but there are no known ones for Chrome at the moment.

[markok]

As far as this particular Chrome bug's impact, if hide/clear isn't doing enough, you should also consider using hideUsingDisplayNone, which is sort of like a stronger version of hide() but not quite clear(). The docs tell you that there are issues in some browsers with this setting, but there are no known ones for Chrome at the moment.

Thanks for the tip! We got a considerable speedup with this setting, atleast in Chrome.