IE11 slowdown related to Canvas.adjustOverflow

[markok]

Hello,

- SmartGWT version: 6.1p Nightly 2018-10-06 (latest at the time of writing)
- OS: Windows 7, Windows 10
- Browser: IE11 (and Edge)

We have an application with quite complex UI and we noticed performance degradation related to Internet Explorer. We've been trying to implement a simple standalone test case for this with little luck, sorry. I'm reporting this anyway, with as many details added, in a hope that you as experts of the framework might be able to shed some light on this issue.

There seems to be an endless loop of some kind relating to the adjustOverflow function which triggers with IE. The effect is, that the CPU usage rises and rises and eventually gets so bad that it starts to impact the responsiveness of the UI. When we load our application, the CPU usage is low (around 0%) but by resizing the browser window, it is quite easy to get the CPU usage up. The issue seems to be related to (re)drawing the UI somehow. This said, resizing the browser is not needed to trigger the problem - it is just the easiest way to cause many redraws which seem to trigger the issue. The same issue happens with no resizing by just using our application for a while, but of course slower. By resizing, the problem is very easy to trigger.

When we break the execution with the debugger this can be seen:



The code highlighted inside the red box is the code which seems to be running endlessly. By looking at the code, the adjustOverflow seems to delay itself for later execution by checking if the "browser is done drawing". For IE, this check is done by (see the yellow highlighted code) looking if the scrollHeight for the canvas is != 0 and in our case, the scrollHeight seems to always be "undefined". When undefined, the code just churns away endlessly and hogs the CPU.

In our case, the problem happens with IE11 and also with Edge, although in Edge, the CPU usage rises much slower (probably due to the more performant JS-engine).

Sorry to submit this problem in so technical manner, but as said, we have not been able to reproduce the issue with any sensible simple test case. We have a suspicion that using SectionStacks extensively might trigger this bug easier (as the queue for adjustOverflows seems to be full of components somehow related to section stacks in our UI) but this is not at all verified. For us, the problem is quite severe as this problem renders the application unusable quite fast for users of IE browser.

[Isomorphic]

What widget is showing scrollHeight perpetually undefined? Presumably it’s some kind of custom widget and perhaps contains some kind of unusual content. Whatever the content is, it looks like due to some kind of bug in Internet Explorer, the size is never actually reported.

If you are also doing any unsupported operations, like manipulating the DOM that SmartGWT renders, you could create this issue. And example would be applying display:none to the DOM rendered by SmartGWT.

Finally, applying CSS styles to, for example, all HTML elements of a given type (like all TD elements) could create a problem like this by changing the normal behavior of IE.

[markok]

Actually, it seems that the scrollHeight is actually 0 instead of undefined. And to answer your question, if we peek at the "_delayedAdjustOverflowQueue" after we resize the browser a few times, we have 4203 canvases in the queue with various different classes of canvases. If I would have to guess, it seems that the whole UI of our app is in the queue waiting for scrollHeight.

We are using Canvas.setHideUsingDisplayNone(true) on some of our Canvases/Layouts for speedup. Could this be the reason for this? We are trying to narrow this down as we speak and will report back if we find the culprit for this.

[markok]

We managed to write a simple test case which demonstrates this issue.

    public void doOnModuleLoad() {
        viewport = new VLayout();
        viewport.setWidth100();
        viewport.setHeight100();

        Canvas container = new Canvas();

        SectionStack card1 = new SectionStack();
        SectionStackSection sss1 = new SectionStackSection("our stack");
        sss1.setExpanded(true);
        VLayout l1 = new VLayout();
        l1.setHideUsingDisplayNone(true);
        sss1.setItems(l1);

        card1.setSections(sss1);
        card1.hide();

        Label card2 = new Label("our label");
        card2.hide();

        container.addChild(card1);
        container.addChild(card2);

        viewport.addMember(container);
        viewport.draw();
    }

How to reproduce with IE11:

1. Run the above code
2. Resize the browser rapidly for few times
3. Open up developer tools / debugger, click pause and note that there is a "adjustOverflow" loop endlessly running

We know the code does not make much sense, but this is a minimal test case which probably matches the situation with our app. We have a wrapper class (a kind of "CardLayoutCanvas") which shows and hides our app views accordingly. The "container" in above simulates this. Also as said, some of our sub-canvases are set up to be hidden with display:none.

The problem lies in the setHideUsingDisplayNone call. If you comment out this call from the above code, the problem goes away. We are not sure if this is the underlying reason but anyway, this is something we noticed as you mentioned the "display:none" thing in your earlier reply.

[markok]

To report back, we just accidentally noticed that this seems to be happening also in Chrome. Might be the same on all browsers? We only noticed this originally with IE as it has a direct responsiveness impact due to the JS engine in it.

[Isomorphic]

In the problem case, we're seeing adjustOverflow() repeatedly fire on the VLayout - and no other canvii. Is that what you see as well?

[markok]

In the above test case, yes. We haven't tried what actually would happen if the VLayout would have members or children - they probably would get stuck in the queue too?

In our app, where we originally noticed the problem, the adjustOverflow queue is full of widgets. These widgets _do not_ have the display:none hide setting set but I suspect these canvases might be sub-members or children of some Layouts with this display:none setting set.

[Isomorphic]

We've added a fix for the problem shown by your sample code to SC 10.1p/SGWT 5.1p and newer releases. It will be in the nightly builds dated 2018-10-13 and beyond.

We tried adding various children underneath the VLayout in question, with various overflow settings and raw HTML content that overflows. We did not see the problem arise again, even though such children don't have hideUsingDisplayNone:true. Therefore, if you see the problem persist, you'll need to provide additional repro code so we can study it.

[markok]

Hi, still fails with NIGHTLY 2018-10-18.

Had some trouble updating the test case as we don't really know what was fixed, but it seems that tabs exhibit the same issue.

Reproducable with the following:

       
        viewport = new VLayout();
        viewport.setWidth100();
        viewport.setHeight100();

        Canvas container = new Canvas();

        SectionStack card1 = new SectionStack();
        SectionStackSection sss1 = new SectionStackSection("our stack");
        sss1.setExpanded(true);
        VLayout l1 = new VLayout();
        l1.setHideUsingDisplayNone(true);

        HLayout pane = new HLayout();
        pane.setHideUsingDisplayNone(true);
        TabSet ts = new TabSet();
        Tab tab = new Tab();
        tab.setPane(pane);
        ts.setHideUsingDisplayNone(true);
        l1.addMember(ts);

        sss1.setItems(l1);

        card1.setSections(sss1);

        Label card2 = new Label("our label");

        card1.hide();
        container.addChild(card1);
        card2.hide();
        container.addChild(card2);

        viewport.addMember(container);
        viewport.draw();

[Isomorphic]

We've applied another change to SGWT 5.1p/SC 10.1p and newer releases. The change is in today's nightly builds for SGWT 12.0p/SC 12.0p and newer releases, and will be in the builds dated 2018-10-23 for the remaining releases.

[markok]

Hi,

Still fails with the above test case using "SmartClient Version: v11.1p_2018-10-26/LGPL Development Only (built 2018-10-26)".

Should the fix be in place for this version?

[Isomorphic]

The code for SGWT 6.1p/SC 11.1p and earlier is a bit different, which required a modification to the fix that unfortunately had a bug. We'll correct this in SGWT 5.1p/SC 10.1p to SGWT 6.1p/SC 11.1p in the next nightlies dated 2018-10-27.

[markok]

Testing now with SmartClient Version: v11.1p_2018-10-27/LGPL Development Only (built 2018-10-27).

Yes, the eternal loop for adjustOverflow() is now gone. But using setHideUsingDisplayNone-containers in our app results in various glitches in the UI. The glitches seem to be quite random but do note that all these glitches are in components inside these containers. With earlier versions, these glitches are not present.

I attached some shots to highlight the issues below. There might be some others too. The glitches seem to appear randomly when the containers are hidden/shown. Resizing the browser might affect the glitches (in the currently hidden) containers.

Record components are incorrectly placed in grid cells:


ToolStrip heights are calculated incorrectly:


Members do not stretch 100% correctly:



Sometimes content overflows from the layout:

[Isomorphic]

Do these happen in both Chrome and IE11? Do you have sample code that reproduces the issue?

[markok]

In both yes, Chrome and IE.

No sample code available at the moment.