Hi again. I'd be grateful if you could look at a problem I've discovered which I think is related to floatbox. It only relates to touch screens, both iOS and Android.

floatbox is used extensively on a site I manage to show more details of product pix, in the form of popups. An example page where the problem manifests is:
http://www.triairemena.com/estuc2_1.html

The problem relates to the vertical navigation menu column. At default page size there is no problem and navigation is normal. But if you pinch the screen to enlarge the page then the left-hand menu starts to misbehave - touching a menu item, eg: "Estuches, expositores" > "Estuches" either causes the adjacent image popup to activate or brings up a different flyout menu item or causes nothing at all to happen.

If I eliminate all reference to floatbox (important: including the link to the floatbox.js script itself) then navigation returns to normal regardless of page enlargement. Note that if I remove the floatbox class from the image popup links but leave the link to floatbox.js at the foot of the code, the problem persists.

On other pages where there are no popups or reference to floatbox, navigation is normal.

Please let me know if you think the problem lies in floatbox or if there's an error in my coding.

Thanks, Peter H.

Hi,

First thing, try using an unmodified floatbox.css file. I noticed that you have deleted some lines from floatbox.css, added a few from custom.css and split the css files out from the script folder without adjusting the relative paths within the css file.

Please use Floatbox in the recommended fashion of leaving the floatbox folder intact, including sub-folders, and loading unmodified floatbox files from that folder. It should not be necessary to modify the floatbox files and I can't provide support for a non-standard and modified install.

But I'm not yet convinced that Floatbox is involved in the problem. When I replicate your page on my test server and try it from Android, the flyout menu behaves identically (and not very well) on zoomed Android with the Floatbox files included and without them.

Hi, thanks for your response and for the tipoff about the paths to the images - a careless blunder on my part.

I've tried as you suggest restoring your original floatbox.css, unmodified, but I still find the same behaviour on the iPad (iPad 3, iOS 5.1.1). I don't have have an Android device available at the moment.
( I've placed a link to custom.css, only on the page:
http://www.triairemena.com/estuc2_1.html )
I haven't changed the floatbox.js file at all and in the options.js I've added a few of the controls as described in your instructions doc.

Unfortunately, restoring your original css files and fixing the image paths makes no difference to the problem pages. On pages that contain the link to floatbox.js there are still problems with the navigation via the left-hand vertical menu when the page is enlarged. At default 100% size it's OK.

Dunno if it's a helpful clue but I've noticed that on fb pages there's a flash of flyout menu when you finger-zoom. Doesn't happen on pages with no ref to fb.

Thanks, Peter

Sorry, but I think I have to leave you to your own resources on this one. I can't help.

When I replicate the page on my test server I get no difference in menu behaviour when floatbox.js is present and when it is not. I also don't see anything like a 'flash of flyout menu' that you report. Without the ability to reproduce the problem, there is no way for me to dissect and debug it.

I can't think of anything in the Floatbox code that might interfere with the menus. Touch events from the main page are monitored and info from those events are captured, but the events are not modified or interfered with.

I recommend you approach this from a menu perspective rather than a Floatbox perspective. Trace what's happening when you touch the menus or zoom the page and modify their behaviour so that they do what you want.

Hi, thanks for looking again at the problem. I can understand that it's impossible for you to see what's happening if you can't reproduce the behaviour I described. But are you saying that you don't see the problem only on your test server? Do you see what I'm on about at the server where the pages reside?

Quote

Trace what's happening when you touch the menus or zoom the page and modify their behaviour so that they do what you want.

The menu in question that's affected is a normal css flyout, not dependent on script (except in IE6) and based on Son of Suckerfish. There's never been anything unusual about the way it performs and it does what it's supposed to do, so I don't really know how to take up your suggestion.

If my pages with floatbox are the only ones afflicted I'm inclined to think that the source of the problem lies with fb's interaction with the rest of my code. It may well be that I've installed fb incorrectly in some way.

In case it's useful, I've uploaded an identical page but without any fb included.
A typical problem page (as described in earlier posts):
http://www.triairemena.com/estuc2_1.html
and the same page without any reference to fb is:
http://www.triairemena.com/estuc2_1-nofb.html

Peter H.

Please understand that I can't help much on this problem, even though I get it that you are experiencing the problem only when you include floatbox.js on the page.

I really think you should be debugging the menu behaviour as it is the menu that is misbehaving. But here's some other ideas that you might want to pursue.

There's some weirdness in the way floatbox is deployed on that page. Start by stripping everything back to basics. This means not hacking floatbox.css, not splitting the package files up into different folders, not chopping sections out of options.js, etc. It also means being more organized in the use of the 'floatbox' and 'nofloatbox' classes. (Please note that the 'floatbox' class will inherit down from a containing element, but the 'nofloatbox'class will not.)

Please do this:
Download the clean, fresh and latest package from http://floatboxjs.com/download.
Place the floatbox folder on your server leaving the folder intact and don't edit or move things around.
Remove all floatbox markup from your page (the 'floatbox' and 'nofloatbox' class assignments).
Move the floatbox.js include up to the <head>.
Basically, we're setting up floatbox in the standard way as described in the quick-start section of the instructions.

Also remove the addthis widget code from the page. I see that code throwing an error on page load and there's a small chance this might be involved in your problem.

If all is well with the menu on this cleaned up page, start adding in the desired floatbox markup (hopefully in a more structured and organized fashion) and test as you make changes. I suppose you could then start hacking out pieces of the floatbox files and scattering the files into different folders, but I would strongly question the benefits of burning up a bunch of time doing so. I doubt this activity could survive a quick cost/benefit/risk analysis.

This is a wordy way of saying, start with the simplest, cleanest page and install you can get and get your menus working well there. Then incrementally make changes, testing as you go.

Hi. Apologies for not acknowledging your reply sooner - deadlines and the holidays filled all my mental space. I appreciate your detailed and considered reply.

Anyway, I finally had time to try a clean reconstruct of a typical problem page as you suggested and as described in your 'quickstart' guide, and no mucking around with your default files. But unfortunately the issue persists, always if the page is zoomed but sometimes even at 100% size.

The test page is at www.triairemena.com/test-fb.html
You can tell that the page is picking up the unmodified fb styles, 'cos the modal popups are in the default style and not the changed styles that are used on other pages. Also I deleted the Addthis code.

It seems to me that the main navigation menu on the site and the floatbox script simply just can't get along together on iOS. All other navigation links on the pages work fine.

The problem reappears as soon as I paste in the link to the floatbox javascript, even if there is no other mention of floatbox, in any form, anywhere on the page.

I guess I'll have to either devise a new main menu or try a different popup script for the images. I'm reluctant to do the latter 'cos I like the flexibility of floatbox and the possibilities it offers.

The main vertical nav menu has to be pure css/html with no script dependency otherwise the site is almost completely crippled for visitors with javascript disabled, even though that's a tiny percentage. That menu is based on Son of Suckerfish, so p'raps I'll look around for an alternative to that. I know this isn't really the place - but if anyone reading this has a suggestion for a css flyout menu . . .

I've probably taken this is far as I can as well.

You haven't succeeded in testing with the floatbox markup removed from the elements. There are 2 elements with the "floatbox" class on them and 32 elements with the "nofloatbox" class. But I would be very surprised if fiddling with those changed your fly-out menu behaviour. As an aside, I don't know what you are trying to accomplish with all the "nofloatbox" classes. They won't do anything. It's just bloat adding those.


I'm pretty sure that your problem results from your menus being badly broken. The list items that host the fly-out submenus contain not just the sub-menus, but <a> links as well, with an href of "#". When the menu item is touched, the fly-out menu comes out in response to the css, but the link is taken as well (because that's what links do) and the base page navigates to "#". This navigation doesn't occur on non-touch devices because we don't click those menu items - we just hover. You're seeing this problem on zoomed touch devices only because you are clicking those links and the page is scrolled at the time you do so. Scroll your test page in a desktop browser and click the base menu item and you will see the same behaviour.

As mentioned before, I've replicated your page and menu on my test server and it behaves identically, and poorly, with and without the floatbox files present. I tested that again just now. Those menus are broken on touch devices due to the simultaneous navigation and sub-menu opening. I can't help any further in fixing those menus, but I'm confident that that's where your problem lies.

I don't think you are getting different behaviour with and without floatbox present. I'm not in my tests. If you really think that you are, I'd be interested in seeing a parallel test page put up beside test-fb.html - maybe call it test-nofb.html - with the only difference being the absence of floatbox.js and floatbox.css. If you can then point to a specific menu behaviour that's different on the two pages I can then start looking again at whether Floatbox might be interfering.

Quote

I don't know what you are trying to accomplish with all the "nofloatbox" classes

I inserted those at the end of the day in desperation to see if it made a difference. It doesn't.

The menu items with flyout submenus need those '#' for the benefit of IE6 (which won't give the right hover response on items which are not links). But in any case removing those # and/or making those items non-links (ie, simple 'li' items) makes no difference to the issue.

Quote

As mentioned before, I've replicated your page and menu on my test server and it behaves identically, and poorly

In what way poorly?

Quote

Those menus are broken on touch devices due to the simultaneous navigation and sub-menu opening.

The menus are not broken on touch devices. There are lots of pages on the site where Floatbox is not present and the navigation works perfectly on iOS, eg: the index page, www.triairemena.com or: http://www.triairemena.com/etiq1_1.html
The only system I've not been able to test properly is Android.

Quote

I'd be interested in seeing a parallel test page put up beside test-fb.html - maybe call it test-nofb.html - with the only difference being the absence of floatbox.js and floatbox.css

OK, done that. You should be able to see the issue at:
http://www.triairemena.com/test-fb.html
and not at:
http://www.triairemena.com/test-nofb.html

If you need inoperative links in your menu entries for the benefit of IE6, you may want to consider adding onclick="return false" to those links so that the links aren't taken when clicked or touched.

I thought I described the "poor" behaviour quite thoroughly. The sub-menu flys out and simultaneously the page scrolls to the top due to the "#" link being taken. The resultant scrolling on the page messes up the use of the menus. Because the menu items need to be touched on touch devices to open the sub-menus, and because this touch gesture invokes unwanted navigation, the menus are broken on touch devices.

I see you have removed those links from the menus in this version of the test page. It is behaving much better now, the "brokenness" is gone, and testing can be done.

Here's the results of my testing.

Chrome on Android:
-- nofb.html
---- sub-menu opens correctly in the right place
---- sub-menu closes on document touch
-- fb.html
---- sub-menu opens correctly in the right place
---- sub-menu closes on document touch

Safari on iOS
-- nofb.html
---- sub-menu opens correctly in the right place
---- sub-menu does not close on document touch
-- fb.html
---- sub-menu sometimes opens correctly in the right place, sometimes jumps before settling in the right place. It looks like maybe the wrong sub-menu opens very briefly and then the right one does.
---- sub-menu closes on document touch

Everything appears well behaved on Android. Safari on iOS is messed up (but you knew that already ). It seems to be internal buggy iOS behaviour with the document behaving differently when event listeners are attached to it and when they are not. I tested by clipping out Floatbox's event listeners and the nofb behaviour occurred without the listeners in place. There's nothing I can do in Floatbox to change this iOS misbehaviour. The listeners do nothing but listen and capture to memory the event type that occurs and the coordinates they occur at. I've reviewed the code thoroughly to ensure that a coding mistake is not modifying or interfering with the event in any way. It is not. This is confirmed by its consistent behaviour on all other platforms.

My conclusion is that the incompatibility lies between the son-of-suckerfish fly-out menus and the different behaviour of iOS documents depending on whether they have listeners attached or not. I think you will need to rework those menus so they are compatible with such iOS documents, find another menu system that is, or don't use Floatbox or any other library or code that adds listeners to the document. I'm afraid there's nothing that can be done by Floatbox to resolve this iOS vs. Suckerfish problem, and I have to stop sinking hours into drilling down into this now.

As an aside, when I was building the menu system for this site I found it impossible to get css-only menus to work happily with touch devices. It was necessary to add explicit javascript menu-helper code for touch events.

Thanks a bunch for such a comprehensive reply - above and beyond what most support services offer.

At least I see the way forward now. The stats for the site show between 5 to 10% visits on iOS so I need to find a solution

Quote

As an aside, when I was building the menu system for this site I found it impossible to get css-only menus to work happily with touch devices. It was necessary to add explicit javascript menu-helper code for touch events

.

I can believe that - I was researching the matter a bit today on the web using an iPad and most of the demos I found don't function fully

Thanks again for the time you've invested, Peter

By the way, just to complete the info I provided about my tests, here's the minimal little test event handler that when added to the page causes those pesky fly-out menus to misbehave:

document.addEventListener('touchstart', contact);
function contact (e) {
    return;
}

As you can see, the listener does nothing at all and this is clearly an internal Mobile Safari bug where the mere presence of the event listener changes the way the document behaves and interacts with the menu's css.