• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Browser issue Inbox, Alerts menu don't activate on hover on Chrome & IE11

thedude

Well-known member
#1
Windows 10
Chrome 46.0.2490.80 m
IE 11.0.10240.16431
Firefox 41.0.2

Logging in to xenforo.com/community and hovering over the Inbox, Alerts and the SplitCtrl arrow will only bring up their menus on Firefox, out of the browsers I listed above.

Chrome and IE require clicking the items (Inbox, Alerts, SplitCtrl arrows) to bring up their respective menus.
 

Chris D

XenForo developer
Staff member
#3
Also cannot reproduce that here, similar set up. Works in IE11 and Edge for me too.

Do you have a touch screen?
 

Chris D

XenForo developer
Staff member
#5
With it being a cross browser thing, it may well be detecting you (for some reason) as a touch device.

When it happens, if you Inspect an element on the page (in Chrome) and scroll all the way to the top, the <html> element? What classes does the <html> element have? Does it have the "Touch" class?
 

thedude

Well-known member
#6
With it being a cross browser thing, it may well be detecting you (for some reason) as a touch device.

When it happens, if you Inspect an element on the page (in Chrome) and scroll all the way to the top, the <html> element? What classes does the <html> element have? Does it have the "Touch" class?
Now Chrome and IE are fine. Only change that happened is I hibernated then turned it back on later, so who knows. Might be related to the absolutely terrible touchpad (and its equally awful helper software) on this laptop.

Thanks for following up on this
 

Chris D

XenForo developer
Staff member
#7
I seem to recall we may have had reports about touch pads presenting themselves as touch screens, and triggering our detection before.
I don't think there's actually much we can do about it. I would have to check but I think it all comes down to a specific event being fired before the mouse is moved.
 

Mike

XenForo developer
Staff member
#8
If we detect certain events that indicate a touch device is present, we adjust some behaviors to account for this. The problem is, there isn't really a foolproof way to do this, so there have been a couple cases in the past where browsers have reported touch capabilities when they weren't, though these have generally been fixed by the browsers. Equally, it's very difficult to truly know what input method is being used (at least without doing some crazy things that we wouldn't want to do), so we basically need to rely on these not always perfect tests.

If a browser starts reporting touch elements, it's usually coming from the OS itself and may indirectly be coming from the hardware (like a touchpad). Unfortunately, we can't do anything because if the OS thinks there's a touch input, the browser will expose the touch APIs and then we'll adapt. Maybe this will change in XF's future.