[INFO REQ] Firefox/safari breaks zoom but not Chrome

[dennisli]

Hi,

I'm running into a rather nasty issue that has taken a very long time to track down.. I've been using bryntum's scheduler.umd.js build in a typescript project for a while now without encountering any sort of wild cross browser issues

However, after upgrading to bryntum 4.0.3 from 3.1.9, I started encountering a rather odd behavior wherein on safari, zoomTo does not work as expected. That is, zoomTo zooms and scrolls to the startDate instead of the center date. Moreover, zooming in/out is broken and simply renders an empty screen without any timeline labels or the like.

I dug into the code a bit and chrome/safari seem to diverge here, in SubGridScroller.scrollTo

Unexpected(Safari)

Screen Shot 2020-12-04 at 6.47.55 PM.png (1.01 MiB) Viewed 1195 times

Expected (chrome)

Screen Shot 2020-12-04 at 6.48.08 PM.png (790.95 KiB) Viewed 1195 times

After zoomTo and events trigger and such, safari's output no longer changes. However, chrome completes its lifecycle and looks like this. Notice how it's centered around today's date, unlike in safari.

Screen Shot 2020-12-04 at 7.14.18 PM.png (152.13 KiB) Viewed 1195 times

There might be a race condition here, I'm not sure. I tried it on another laptop and there it also seemed to both firefox and chrome, too.

[s]
My suspicion here is that it has to do with how the UMD bundle was built. I've tried switching to .module.js instead but presumably because I'm using both Grid and Scheduler, but I get the following error: Uncaught Error: Bundle included twice, check cache-busters and file types (.js)

I saw this thread: viewtopic.php?f=43&t=10455 but it looks like that shouldn't be the reason why i cannot import via module as the bug was marked as fixed....[/s]

[alex.l]

Hi dennisli,

Seems like you updated not all imports from umd to module. You need to use one build at once. Please check if you still importing umd.js somewhere.

All the best,
Alex

[dennisli]

Hi Alex,

Sorry, apologies, I mispoke -- ignore the bit on bundle included twice. I switched everything to '.module.js' but i'm still running into the bug described above..

[dennisli]

I'm stepping through the code still with the debugger and the issue becomes apparent in scroller.updateX

  updateX(x) {
    const {
      element,
      widget
    } = this; // When element is outside of DOM, this can have no effect

if (element && !(widget === null || widget === void 0 ? void 0 : widget.isConfiguring)) {
  this.trigger('scrollStart', {
    x
  });

  if (this.translate) {
    DomHelper.setTranslateX(element, -x);
  } else {
    element.scrollLeft = x;
  }
} // The scroll position will need to be read before we can return it.
// Do not read it back now, we may not have our element, or if we do,
// that would cause a forced synchronous layout.

this.positionDirty = true;
  }

element.scrollLeft updates as expected, ie

element.scrollLeft
25580

however, in the case of safari, this only scrolls left 5 px:

element.scrollLeft
5

Perhaps the issue is related to infinite scroll https://github.com/bryntum/support/issues/1114?

At any rate, this issue is causing a huge headache on my end...

[mats]

Perhaps the issue is related to infinite scroll

#1114 Infinite scroll along the time axis

No, that's a feature request - not a bug.

At any rate, this issue is causing a huge headache on my end...

Please provide us a simple test case and we can debug it.

[dennisli]

Please provide us a simple test case and we can debug it.

Hi,

Thanks for the help. I was finally able to dig into it and generate a test case by modifying the bigdataset example. I've attached a screen shot of safari vs chrome (left, right). Click "zoom all" to replicate what I am describing.

The expected/chrome behavior is for thecontent to be centered on 12/5. But safari instead centers the content on the earliest start date of 11/19.

The issue seems to stem from how chrome and safari handle flexbox... perhaps bryntum is not reflowing as expected? I'm not sure.

	<div style="display: flex; width: 100%; position: relative;">
		<div style="display: flex">
				<div id="container" style="width: 100%">
				</div>
		</div>
	</div>

At any rate, switching the immediate parent of #container to display: block, the issue disappears, and safari acts identically to chrome...

[mats]

What version of Safari are you using?

[dennisli]

What version of Safari are you using?

Version 14.0.1 (15610.2.11.51.10, 15610)

[alex.l]

I can confirm that this is CSS problem in your custom added 2 div containers (+1 our one) with display: flex; style. It is browser independent problem, I scrolled it in Chrome and see that container is "jumps" after scheduler refresh.
Please, be aware that shared.css already applies some styling to div with id container. Also please take care of styling for your intermediate DIV container, as examples, use "flex: 1" to set its size.

All the best,
Alex

[dennisli]

I can confirm that this is CSS problem in your custom added 2 div containers (+1 our one) with display: flex; style. It is browser independent problem, I scrolled it in Chrome and see that container is "jumps" after scheduler refresh.
Please, be aware that shared.css already applies some styling to div with id container. Also please take care of styling for your intermediate DIV container, as examples, use "flex: 1" to set its size.

All the best,
Alex

Sorry, I'm not sure I understand -- are you saying that I should remove the shared.css?