Web-bugs: gs.statcounter.com - doesn't show percentages for browser overlay in Firefox with touch enabled

[karlcow]

URL: http://gs.statcounter.com/
Browser / Version: Firefox 52.0
Operating System: Mac OS X 10.12
Problem type: Something else - I'll add details below

Steps to Reproduce
1) Navigate to: http://gs.statcounter.com/
2) Over the mouse on one of the dots on lines.

Expected Behavior: Show the percentage for this browser

Actual Behavior: Doesn't show anything.

_From webcompat.com with ❤️_

[karlcow]

The dots are defined by:

<circle style="stroke: rgb(192, 192, 192); stroke-opacity: 0.000001; fill-opacity: 0.000001; fill: rgb(192, 192, 192);" cx="478" cy="74" r="15" stroke="#c0c0c0" stroke-opacity="0.000001" stroke-width="1" fill-opacity="0.000001" fill="#c0c0c0"></circle>

what it looks like on Opera/Blink

Switching to needsdiagnosis

[somedaysummer]

Works for Firefox 49.0.1, and Firefox Developer Edition 51 on Windows.

Possible SVG issue on Mac OSX versions only? Do not have Mac OSX so cannot confirm.

[tsl143]

Works perfectly fine on Ubuntu/Firefox(49).
May be issue is only with Mac OSX

[karlcow]

thanks @tsl143

With Firefox 49.0.1 and Nightly 52.0a1 (2016-10-04) (64-bit) on MacOSX I get this.

11:56:05.073 TypeError: src is null[Learn More]  global-3851aca9d2.js:3769:11
    .connect http://statcounter.com/js/packed/global-3851aca9d2.js:3769:11
    once_only< http://statcounter.com/js/packed/global-3851aca9d2.js:8442:1
    .signal http://statcounter.com/js/packed/global-3851aca9d2.js:3919:1
    <anonymous> http://gs.statcounter.com/:280:3

hmm weird.

http://statcounter.com/js/packed/global-3851aca9d2.js

[wisniewskit]

I just tried in OSX Firefox 52 nightly, and can't replicate the bug -- the percentages appear on-hover just fine. @karlcow, can you still see the bug? It may have been a bug on nightly that was fixed recently.

Also, that "src is null" exception is an unrelated bug in their script. The same exception is thrown for every browser I've tried viewing the page on. The line triggering it is:

signal(window, "onDOMload");

This is a dead ringer for code they wanted to run only after the page's DOM is loaded, but they're not calling it from the DOMContentLoaded event, so it's called prematurely and bombs. It's presumably meant as a fall-back for older browsers that don't handle DOMContentLoaded, but if that's the case they should probably be handling the failure more gracefully.

[karlcow]

working for me too.
But understood the source of the issue. I had probably activated by mistake the touch event on desktop. and then it was not working anymore on hover.

[cpeterso]

I can still reproduce this StatCounter tooltip problem in Firefox 62.

Mouse hovering over or clicking a data point shows a tooltip in Chrome and Edge (but not Firefox) on my Windows 10 touchscreen laptop and in Firefox on my (non-touchscreen) MacBook Pro.

Touching the data point shows a tooltip in Firefox, Chrome, and Edge on my Windows 10 touchscreen laptop. So something about Firefox on a touchscreen laptop confuses StatCounter into not supporting mouse hovering or clicking.

[karlcow]

@cpeterso @wisniewskit

when touch events are activated we can't get the tooltip.

[wisniewskit]

@karlcow, @cpeterso, ah, with dom.w3c_touch_events.enabled set to 1, I do see the problem.

It also seems that FusionCharts have been aware of issues like this, but I don't know if they have fixed anything since that report. Perhaps StatCounter is using an old version (3.6.0 is what their source cites), or perhaps FusionCharts is still buggy with respect to touch events.

FusionCharts is detecting touch support with:

D.documentElement.ontouchstart

This sets a hasTouch variable to true, which propagates down to various code including the bit we're interested in (accessed here with the alias F):

c.el.trackTooltip = function (a) {
  var b = !!this.__tiptracking;
  if (void 0 === a || (a = !!a) === b) return this;
  a ? F ? this.touchstart(u.onelement)  : (this.mouseover(u.onelement), this.mousemove(u.onredraw), this.mouseout(u.onhide))  : F ? this.untouchstart(u.onelement)  : (this.unmouseover(u.onelement), this.unmousemove(u.onredraw), this.unmouseout(u.onhide));
this.__tiptracking = a;
  return this
};

That is, they are only listening for either touchstart or mouseover, rather than both. So of course, if touch events are on, they will ignore the moveover events entirely.

I also see them looking at document.createTouch elsewhere:

ea = c.supportsTouch = 'createTouch' in ka,

This is only supported by Firefox, to my knowledge, and only when touch events are on.

This is the type of behavior I've seen some pages do to try to deal with the emulated mouse events that browsers can fire for touch events. But there are better ways to deal with this, which allow for mouse and touch events to be handled.

Either way, this looks to me like site error. That is, FusionCharts is purposely acting as though mouse and touchscreen events are mutually exclusive, which they are not.

[karlcow]

@fusioncharts is on GitHub
with 5 persons as potential contacts https://github.com/orgs/fusioncharts/people

I wonder if it's the line @wisniewskit is talking about

https://github.com/fusioncharts/redraphael/blob/4d4a7587c648356f6ebaa32a0e82e3d1ea2ac820/source/raphael.core.js#L150-L155

An issue could be opened on https://github.com/fusioncharts/redraphael/issues

[wisniewskit]

@karlcow, yes, that looks similar, but I didn't see a supportsOnlyTouch method in the script on StatCounter's page, which is a good sign that they're on an older version. (I also don't see a trackTooltip method in their Github repositories, so it's entirely possible that this is already fixed on FusionChart's end, and StatCounter just has to update their version).

[adamopenweb]

I wonder if @adotg or @jimut can help us understand if this has been fixed in FusionCharts?

[adotg]

@ayanonly1 @kingshukbasak can you please look into it and confirm the issue with the latest build?

[ayanonly1]

As explained by @wisniewskit , in our older versions, it has some issues due to relying on either mouse events or touch events. But in our latest versions, entire input interactions has be modified to accommodate touch, mouse and pointer events together.
It is working fine in latest samples in Firefox 62 in Mac and Windows 10 touch device with dom.w3c_touch_events.enabled set to 1 as well. So it needs to be updated to the latest versions for this.
Please let me know if the issues still occur.
@adamopenweb @adotg @karlcow FYI.

[softvision-oana-arbuzov]

The issue has been fixed.

Tested with:
Browser / Version: Firefox Nightly 69.0a1 (2019-06-19)
Operating System: MacOS 10.14.4, Windows 10 Pro

[cpeterso]

I think smaug fixed this bug in Firefox 67 with https://bugzilla.mozilla.org/show_bug.cgi?id=1412485.