PDA

View Full Version : Smooth Navigational Menu v2.1 : Hover Mouse Problem



ozonenetwork
08-14-2013, 03:55 AM
1) Script Title: Smooth Navigational Menu v2.1

2) Script URL (on DD): http://www.dynamicdrive.com/dynamicindex1/ddsmoothmenu.htm

3) Describe problem: can not open menu using hover mouse (left click mouse worked) since version 29.xx on Chrome Browser , Demo Page not work too. What should i do?

Thanks for any answer.

jscheuer1
08-14-2013, 04:36 AM
If I do an "About Google Chrome" from its "Customize and control Google Chrome" menu I see:


Version 28.0.1500.95 m
Google Chrome is up to date.

And there's no problem such as you describe. So I'm assuming you have a beta or some other pre-release version there.

And/or you're on a touch capable device, in which case the script detects that and all Smooth Menus become click (touch) to activate on devices like those which generally do not support hover.

I have heard that, in the past Chrome was erroneously reporting it was touch capable on devices that were not. It's possible that, if you have a beta version on a non-touch device, this old bug has crept back in. If that's the case, once the official 29.x comes out for your device, that should be fixed.

If all else fails, we can detect Chrome and force it to work on hover. But that runs the risk of making the menu unusable on a true touch device like a phone or pad without a mouse if it's using Chrome. So I would prefer to let the Chrome people work out their own bug on this - if in fact that's the issue.

What OS and device are you using?

lagunaradman
08-29-2013, 08:58 PM
If I do an "About Google Chrome" from its "Customize and control Google Chrome" menu I see:



And there's no problem such as you describe. So I'm assuming you have a beta or some other pre-release version there.

And/or you're on a touch capable device, in which case the script detects that and all Smooth Menus become click (touch) to activate on devices like those which generally do not support hover.

I have heard that, in the past Chrome was erroneously reporting it was touch capable on devices that were not. It's possible that, if you have a beta version on a non-touch device, this old bug has crept back in. If that's the case, once the official 29.x comes out for your device, that should be fixed.

If all else fails, we can detect Chrome and force it to work on hover. But that runs the risk of making the menu unusable on a true touch device like a phone or pad without a mouse if it's using Chrome. So I would prefer to let the Chrome people work out their own bug on this - if in fact that's the issue.

What OS and device are you using?

I am also suddenly having problems with the Chrome desktop browser detecting as a touch device and not allowing hovers. I visit the site http://mesawater.org/ with the problem every couple of days as I am their Webmaster, so I'm pretty certain is was ok just a couple of days ago. I can also replicate the same issue with the demo of this plugin. I am using Chrome version 29.0.1547.62 m. Any ideas?

jscheuer1
08-29-2013, 11:17 PM
I see what you mean I now have:

Version 29.0.1547.62 m

And it's doing it for me too. I don't think it's that big of a deal. People will generally click on the item if they're interested, then they will see the drop down. This is actually how I envisioned this menu working in all browsers but Dynamic Drive wanted it to maintain the old hover method as the default.

My thinking is that if it works on hover, people will be tempted to link the triggers. If you do that, functionality and/or accessibility will be lost for touch devices. Fortunately the site you linked to in your post doesn't link the triggers, so (as long as the rest of the page is good for touch/mobile) will be both functional and accessible on touch/mobile devices. And Chrome on a desktop/laptop for the time being . . .

When I get a little more time though I will look into it. I used a very aggressive method of detecting touch in that script. Nevertheless, Chrome on a non-touch device shouldn't be reporting true for any of the tests. If the one it's reporting true on is one of the minor ones, I will issue an update with that one either removed, or qualified to not trigger touch capable status for Chrome.

lagunaradman
08-29-2013, 11:35 PM
I tend to agree with you, but I know my client will bring it up as an issue because FF, IE and Safari all still have the hover effect. But, I bet those three will soon follow Chrome's lead because of the domination of touch devices. Thanks very much for your reply and great work!

jscheuer1
08-29-2013, 11:43 PM
OK, on my Chrome it's giving a "false positive" on:


!!window.Touch

So, for now, using a text only editor like NotePad, you can open up the ddsmoothmenu.js file and remove:


|| !!window.Touch

from the detecttouch: property (line #57, get rid of the highlighted):


detecttouch: !!('ontouchstart' in window) || !!('ontouchstart' in document.documentElement) || !!window.ontouchstart || !!window.Touch || !!window.onmsgesturechange || (window.DocumentTouch && window.document instanceof window.DocumentTouch),


Save and use that version.

I'm not sure if this is a bug in the script, or a bug in Chrome. I see no reason why a desktop, laptop, or any device that's not touch capable should have a browser that reports true for that. But there's a good chance the 'experts' at Chrome may have a reason.

I've reported it via "report an issue" on the about page and in their forum. I may or may not hear back from them.

jscheuer1
09-05-2013, 01:05 PM
.

Update 9/26/2013 - You can read below for the history on this, but the official version now includes the workaround mentioned below, you can now download it from the demo page:

http://www.dynamicdrive.com/dynamicindex1/ddsmoothmenu.htm

or direct from here (right click and 'Save As'):

http://www.dynamicdrive.com/dynamicindex1/ddsmoothmenu.js



I reported this to the Chrome people and opened a thread on it in their forum. There appears to be a better workaround for now (change/addition highlighted around line #57 in the ddsmoothmenu.js file):


detecttouch: !!('ontouchstart' in window) || !!('ontouchstart' in document.documentElement) || !!window.ontouchstart || (!!window.Touch && !!window.Touch.length) || !!window.onmsgesturechange || (window.DocumentTouch && window.document instanceof window.DocumentTouch),


Use a text only editor like NotePad to make the change.

I'm not making an official change to the script until I find out whether or not the Chrome people see this as a problem and whether or not they are going to fix it. Or if a reasonable amount of time passes and it looks like they are not going to address it.

Update(9/16): No one at Chrome has responded about whether or not this is an error or serves a useful purpose, let alone whether it's going to be fixed or not. SO I've submitted a copy of the script to DD with the above fix. I will let you know when it's been adopted so you can download it from the demo page.

For now you can make the edit as above to your copy or download the update directly from here (right click and 'Save As'):

[attachment removed, demo page has update now]

The browser cache may need to be cleared and/or the page refreshed to see changes.

If you want more help, please open a new thread and include a link to the page on your site that contains the problematic code so we can check it out.