IE11 Flickering When Canvas Height > Browser Window Height

GoJS
1

Using the example here with IE11:

Resize your browser window so that the canvas height is greater than window height resulting in scroll bars appearing on the right:

image
image850×593 130 KB

Now, left-click anywhere on the diagram repeatedly and eventually (sometimes it takes awhile), you will see the flicker. It appears that the canvas tries to move to the top of the browser before re-adjusting to where it should be. It happens very quickly causing the browser to appear to flicker.

In our own more complex implementation with GoJS with many more nodes and groups, the flickering is more apparent and pretty annoying. I have no clue as to how to fix this. Any ideas? Or, if it is IE11 being IE11 ( a bug with it handling canvas), any idea on how to reduce the frequency of it?

Best regards,
Steve

2

My guess that’s a non-optimization of some scrolling of the page when the Diagram gets focus.
Try setting Diagram.scrollsPageOnFocus to true.

3

Just tried that on a test page on my machine. The flickering issue stops, however, it scrolls the browser window down so the canvas is at the top. Anything above that, like a row of buttons, is now out of view.

Before mouse click:

image
image.png778×399 19 KB

After mouse click:

image
image.png779×341 13.3 KB

4

Yes, that is the intended behavior implemented by IE when scrollsPageOnFocus is true.

5

Right, I got that. :-) I need it set to false to stop that behavior (and false is the default value I believe) so that content above the GoJS diagram remains in view. But, the flicker issue occurs in IE11. Chrome behaves just fine. Most of our customers are relegated to using IE11.

6

Well, I don’t know what to suggest, since the code is the same for all browsers.

Here’s what Diagram.focus does:

  public focus(): void {
    if (!this._canvas) return;
    if (this.scrollsPageOnFocus) {
      this._canvas.focus();
    } else {  // root is normally window
      const x = root.scrollX || root.pageXOffset;
      const y = root.scrollY || root.pageYOffset;
      this._canvas.focus();
      root.scrollTo(x, y);
    }
  }

You can also implement “GainedFocus” and “LostFocus” DiagramEvent listeners, which get called upon “focus” and “blur” events.

Please do not modify any HTMLCanvasElement that the Diagram creates for the HTMLDivElement.

7

I was curious as to why it is necessary to call the scrollTo function in the “else” branch? I’m thinking this is causing the issue since IE11 seems to have various scrolling bugs, one being “smooth scrolling”. I disabled that on my end, but the issue still persists.

As far as implementing “GainedFocus” and “LostFocus” DiagramEvent listeners, I’m not sure what to do inside that code. Will it override Diagram.focus? We are trying to keep any hacks to a minimum. :-)

8

The scrollTo call is to restore the page’s scroll position after IE has scrolled the page to have the focussed element occupy the window’s viewport.

9

Well, out of curiosity, when I comment out the focus line in the else branch, the flickering issue stops. I don’t immediately see any adverse effects. Thoughts?

public focus(): void {
    if (!this._canvas) return;
    if (this.scrollsPageOnFocus) {
      this._canvas.focus();
    } else {  // root is normally window
      const x = root.scrollX || root.pageXOffset;
      const y = root.scrollY || root.pageYOffset;
      //this._canvas.focus();
      root.scrollTo(x, y);
    }
  }
10

Note that the ._canvas property is not public, and in fact is minified.

But then the canvas element might not have focus! That’s the purpose of the Diagram.focus method, after all. And there would be no reason for calling scrollTo.

I suppose you could see if it already has focus…