Incorrect detection of pointer events in hosted IE environment.

[helge]

The applications we build with SmartClient are frequently hosted in embedded IE browsers in newsroom control systems. After updating from SmartClient v11 to SmartClient v12.0p_2018-06-14, our software stopped working: Buttons can be clicked, but their respective handlers are not called. Visual hover effects and button depress effects behave as normal. Keyboard events behave as normal.

The cause for this seems to be that SmartClient assumes pointer events (onpointerdown, onpointerup, onpointermove, onpointercancel) are provided if window.PointerEvent exists. This assumption does not hold universally and not for embedded IE browsers. Another check on window.navigator.msPointerEnabled is needed.

Working from the SmartClient debug code bundled inside SmartGWT, I made a change to the isc.Browser.pointerEnabled property in /sc/client/browser/Browser.js (lines 1348-1354)

The original code:

//> @classAttr browser.pointerEnabled (boolean : varies : RW)
// Does the browser support pointer events as a means of capturing both touch and mouse
// interactions?  This simplifies event handling for capable browsers.
//<

isc.Browser.pointerEnabled = window.PointerEvent != null &&
        (isc.Browser.isIE || isc.Browser.isEdge) && !isc.Browser.isMobileIE;

After adding a check on msPointerEnabled:

//> @classAttr browser.pointerEnabled (boolean : varies : RW)
// Does the browser support pointer events as a means of capturing both touch and mouse
// interactions?  This simplifies event handling for capable browsers.
//<

isc.Browser.pointerEnabled = (window.PointerEvent != null && window.navigator.msPointerEnabled !== false) &&
        (isc.Browser.isIE || isc.Browser.isEdge) && !isc.Browser.isMobileIE;

After this change, our applications are working normally.

We would very much appreciate it if this issue could be addressed in some way. :)

[Isomorphic]

Can you provide us with some more information?

Is your system mouse or touch-driven? What is the version of your embedded IE? Does it have a version # similar to desktop IE? (For example IE11 reports 11.0.9600.19080 on Windows 7 x64)

You said that window.PointerEvent is defined (presumably an object) on your system and it looks like you're saying navigator.msPointerEnabled is explicitly false (rather than null or undefined). What values do the following two expressions have?

window.MSPointerEvent
navigator.pointerEnabled

[helge]

Hi!

The systems we have reproduced this on are mouse-driven Windows 10 (64bit), freshly updated.

In most cases it is exactly the desktop IE version: Since the hosted IE is both chosen and provided by Windows, it varies but is usually the default desktop IE 11 with some constraints turned on. The IE version in my reproduction case is 11.165.17134.0. In some cases it pretends to be IE7 via compatibility mode. In one usage scenario it is IE11 identifying itself as IE11 but claiming to run on Windows 8. All these hosted versions have the same symptoms, the same pointer event assumptions, and respond equally well to the code change.

It is correct that window.PointerEvent is defined with type object, and that navigator.msPointerEnabled is explicitly false and not some other "falsy" value. The two expressions you provided evaluate to the following in my two available test systems (user agent string added in case it is helpful):

In the hosted IE (via .NET using System.Windows.Forms.WebBrowser) running off my Windows 10 machine:

window.MSPointerEvent = [object]
navigator.pointerEnabled = undefined
navigator.userAgent = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)

In the hosted environment of a 3rd party application (OpenMedia) running on the same computer:

window.MSPointerEvent = [object MSPointerEvent]
navigator.pointerEnabled = false
navigator.userAgent = Mozilla/5.0 (Windows NT 6.2; WOW64; Trident/7.0; rv:11.0) like Gecko

[Blama]

Hi helge,

please also see this FAQ entry regarding IEs in "I'm some other IE mode". Perhaps the meta tag helps to work around the system settings.

Best regards
Blama

[Isomorphic]

We've made a change to SC/SGWT 12.0p and newer releases that should avoid pointer handling being engaged when not supported. It will be in the nightly builds dated 2019-08-18 and beyond.

[helge]

Blama Thank you for the information. I checked, and we already had the meta tag and the doctype tags in place, so unfortunately they did not improve this issue.

Isomorphic I have tested the change, and it fixes the issue for us. Thank you!