Our pure JavaScript Scheduler component


Post by daansatortec »

We're encountering a runtime error when the Bryntum Scheduler is initialized on certain devices.

Our error logging reveals the following runtime error:

undefined is not an object (evaluating 'handler.call')

The error is thrown in the createContextMenuWrapper function and seems to occur on an iOS 12.4 (iPAD) device (probably on others too).

This was reported when using the Bryntum Scheduler version 3.1.3.


Post by daansatortec »

The impact of this bug is that the scheduler is non-functional for such devices.


Post by alex.l »

Hi daansatortec,

Could you try to reproduce this problem in one of our examples from here https://www.bryntum.com/examples/scheduler
and let us know which one doesn't work for you?

Thank you,
Alex

All the best,
Alex


Post by daansatortec »

I don't own an iPad, so I cannot reproduce it myself. The error was caught in production on the device of one of the end users. However, since the code is executed for every scheduler instance it doesn't really matter which example you choose. They all experience the same issue.


Post by mats »

Can you please try to reproduce it using Chrome in touch emulation mode?


Post by daansatortec »

That doesn't work because the function is not executed due to the fact that it is wrapped in the following if statements:

if (BrowserHelper.isTouchDevice && !BrowserHelper.isAndroid) {
  if (eventName === 'contextmenu') {
    // ... EventHelper.createContextMenuWrapper(...) ...
  }
}

If I use touch emulation mode BrowserHelper.isAndroid evaluates to true, so it never executes the code.

I think this is a device+browser+OS specific issue. Since you guys wrote this special code, I suspect you will be able to reproduce it yourself.


Post by mats »

You can overwrite this for your testing purposes easily, using the UMD version just do:

bryntum.grid.BrowserHelper.isTouchDevice = true

Post by daansatortec »

I don't really see the point in that, but ok.

Just tested it on Chrome (Windows 10). No problems there. So, as I said before this seems to be a device/browser/os specific issue. I'll leave the rest of the testing up to you guys.


Post by mats »

Ok, any idea on the steps to reproduce? We can heavily recommend RootCause for your debugging efforts btw. How do you monitor production bugs currently? https://therootcause.io/


Post by daansatortec »

Steps to reproduce should be quite simple. Make sure you have the right device (I don't own any, so I can't check it myself). Hook it up to a debugger and then trigger a "contextmenu" event on the planboard (that is probably a longpress on an iPad, not really sure). I am pretty sure the developers will be able easily find a way to reproduce if they just take a took at the code, especially since this appears to be some custom handler for non-Android touch devices (i.e. it will mostly be targeting Apple products).


Post Reply