I'm using Superfish on a D7 site and have enabled the sfautomaticwidth.js plugin (fetched automatically via the superfish.make file). The main menu it's used with is a horizontal menu under the header region. On Safari/IE/Firefox resizing the browser window works as it should, with all li menu elements spaced out perfectly. On Chrome however, resizing always pushed the last element onto a second line. Digging into why this happens, there seems to be a difference between browsers in to how many decimal places the % widths are assigned to the elements. For example in Firefox my first element is 7.39857%. In Chrome it's 7.398571428571429%.

I added up all the menu elements' widths in Chrome and the total % width came to 100.08403361344538%, and this was why the final menu item was being pushed onto the second row. I made a quick alteration to the js outlined below, and it seems to work fine. Anyway it took us a while to find out why this was happening so I thought I'd better document it here in case anyone else runs into this.

Not perfect but a quick fix: change line 46 of sfautomaticwidth.js

autoWidth = (((child[0].clientWidth * 100) / menuWidth) + difference) + '%';

to

autoWidth = (((child[0].clientWidth * 99.8) / menuWidth) + difference) + '%';
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mehrpadin’s picture

Hey there,

Thanks for reporting :) I'll try to reproduce.

joepinion’s picture

Any update on this? I use superfish for our Drupal 7 site:
http://www.ashland.edu
http://www.ashland.edu/student-affairs

etc.

Autowidth works fine every time on default zoom, but when zooming in/out it has problems... Chrome has more problems than Firefox (I'm on OS X btw) but even Firefox is having the problem on our homepage when zoombed out two levels.

The change proposed by markgifford seems like it would work for me.

markgifford’s picture

I totally forgot about this. The manual change I made has been working fine on production sites so far.

Hmm I wonder if the problem is down to 32-bit v 64-bit? When an application needs to carry out all sorts of calculations involving lots of decimal places (floating point calcs), 64-bit is going to be far more accurate than 32-bit. I just checked and my Safari and Firefox are 64-bit compiled; they're accurate. My Google Chrome is 32-bit compiled and it's the one that's had problems.

I also have Google Chromium 64-bit installed on this same machine so if I find some time I might grab a copy of my site, change that 99.8 back to 100 and see if it's looking more like 32-bit v 64-bit problem rather than a Chrome v other browsers problem.

joepinion’s picture

Mark: Thanks for the reply, yes, your change seems like it will work for me too. btw I am on a 64-bit Intel Core i7 but I don't know how the individual browsers are compiled.

I am going to go ahead and make your proposed change today, so the examples I linked to in my post above won't work as examples any more. Thanks for the reply!

adam-delaney’s picture

I can confirm that this is an issue. The issue appears to be isolated to windows users, using both Firefox and Chrome browsers. I have implemented markgifford quick fix and that appears to have resolved my issue. Here is a patch to run against the sfautomaticwidth.js file if anyone is interested.

markgifford’s picture

adam-delaney: the sfautomaticwidth.js file isn't actually part of the module as distributed by d.o. so it can't be patched; it's part of a separate external library called Superfish-for-Drupal hosted on Github. You might want to create a pull request over there to merge your changes into the library.

[Sorry about that. I probably should have created the pull request myself way back when we found the issue.]

jerry’s picture

I noticed the same issue with Chrome on OS X a while back. However, I'm now also seeing it with Safari 7.1. The same fix appears to work, except that I've had to drop the adjusted percentage from 99.8 to 99.6 to be fully effective for the latter case.

Morn’s picture

Same with Google Chrome V.49 and the 2.0 library. #5 resolves the problem

Rudi Teschner’s picture

I've had the same issue. #5 along with css to set li:last-child a {border-right: none} and the issue is a matter of the past.

bneil’s picture

I created the PR for the Superfish JavaScript library at https://github.com/mehrpadin/Superfish-for-Drupal/pull/18

LOBsTerr’s picture

Status: Active » Closed (outdated)