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) + '%';
Comment | File | Size | Author |
---|
Comments
Comment #1
mehrpadin CreditAttribution: mehrpadin commentedHey there,
Thanks for reporting :) I'll try to reproduce.
Comment #2
joepinion CreditAttribution: joepinion commentedAny 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.
Comment #3
markgifford CreditAttribution: markgifford commentedI 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.
Comment #4
joepinion CreditAttribution: joepinion commentedMark: 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!
Comment #5
adam-delaney CreditAttribution: adam-delaney commentedI 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.
Comment #6
markgifford CreditAttribution: markgifford commentedadam-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.]
Comment #7
jerry CreditAttribution: jerry commentedI 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.
Comment #8
Morn CreditAttribution: Morn commentedSame with Google Chrome V.49 and the 2.0 library. #5 resolves the problem
Comment #9
Rudi Teschner CreditAttribution: Rudi Teschner commentedI'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.
Comment #10
bneil CreditAttribution: bneil at The University of Iowa commentedI created the PR for the Superfish JavaScript library at https://github.com/mehrpadin/Superfish-for-Drupal/pull/18
Comment #11
LOBsTerr CreditAttribution: LOBsTerr at European Commission and European Union Institutions, Agencies and Bodies commented