More and more people are using small tablets to view web pages so I just purchased my first tablet to get a better idea of the end user experience. I purchased a Google Nexus 7. Although I have been designing web pages for years, this is my first tablet and my first Android device so my experience in this area is very limited.

The Floatbox window opens properly but when I tap the next or previous buttons within the floatbox window, no action is taken. If I hold down the buttons then I can open the photo in a new tab (but that defeats the purpose of Floatbox). Is this functionality supported by Floatbox?

Here is a sample link http://www.racquetball-league.com/photos.php

Additional information - I am using the built-in Chrome App version 18.0.1025123.

This appears to be a bug with Chrome on Android.

I test all features of Floatbox regularly on multiple browsers on a tablet that's currently running Android 4.0.3. On this platform, the built-in Android browser, Opera Mobile, Dolphin, Skyfire and Firefox are all working fine (except Firefox has sizing and positioning problems on a zoomed screen). I just added Chrome to the suite of browsers on my tablet and indeed, as you report, it's refusing to navigate between gallery items. The close button doesn't want to work either, but touching on the translucent overlay does succeed in closing the floatbox. Very odd.

The fact that all the other browsers are working fine on Android, and that Chrome is working fine on other operating systems, means I'm probably going to have to submit a bug report to the Chrome browser team. This doesn't look like something that is fixable from the Floatbox code.

Additional information - Version 4.2 of Floatbox seems to work fine with the Google Nexus 7 tablet. Click the link below:

http://www.schuckman.com/test_floatbox/photos.php

This is just an FYI in case you are interested.

Very interesting. Thanks for taking the time to assemble and report the example. Heavy rain here today, so a good day to pull out the debugger...

I don't like necroing threads, but I'm experiencing the exact same thing on a different platform. That the exact same problem is occurring in regular Chrome (v23 on Windows 7) with browser zoom set to above 100%.

To replicate, open Chrome, press Ctrl and "+" a few times, and then the "next", "prev", "close" buttons and the "esc" key no longer do anything. Pressing Ctrl and "-" closes the image. It only shows this behavior sporadically - refresh and try again if you can't replicate it the first time.

The page with v4.2 works perfectly fine for me.

I noticed it since I have a 1920x1080 15-inch laptop display, and my default browser zoom is 150%. Would be great to see it fixed.

I can't replicate this problem. After zooming Chrome v23 on Windows 7, all navigation controls and keystrokes work just fine.

Please make sure you are using the latest floatbox release (5.6.1) and if you continue to have problems, link me in to a page where I can see the problematic behaviour.

I'm using latest, freshly-downloaded 5.6.1.
I threw together a test page here - http://vladkvit.github.com/floatbox_test.html .
Steps to reproduce: Set default browser zoom to 150%, open up the page, click the first image, click "next", click "Close". "Close" does not work on my machine.

Source is public on github - https://github.com/vladkvit/vladkvit.github.com/blob/master/floatbox_test.html . You can fork it for testing.

In Google Chrome, version 23.0.1271.97 m, running on Windows 7 Home Premium SP1, I open the "customize and control" menu from the top right corner of the browser, set zoom to 150%, open the floatbox_test.html page in a new tab, confirm that zoom is still at 150%, click the first thumb to open the floatbox, click the 'next' button to navigate to the second image, click the 'close' button to close that image, and it does close. Everything behaves normally without a problem.

Repeating the same test from Chrome 18.0.1025469 running on Android 4.1.1, but pinch-zooming the page up instead of setting the zoom menu, everything works fine. Navigation to the next item is as expected and touching the close button closes the floatbox.

I do not know why you are getting strange behaviour on your machine, but it does not appear to be a general Floatbox problem.

Incidently, the Chrome/Android issue discussed when this thread was opened last July was fixed in Floatbox version 5.4.0, released on September 15.

Seems quite strange.
My machine is W7 x64 pro SP1. Tested in incognito (made sure that there were no extensions) + zoom - I can reproduce the behavior.
Just tested it on another 2 machines. On a Windows Server 2012 + Chrome 23, I can reproduce the behavior as well.
On a friend's machine, W7 home premium sp1 + Chrome v23, no extensions, I don't use the machine at all - can reproduce.

Another very curious thing is that everything works fine with 175% zoom (and not 150%).

I'm going to try and bring up a fresh VM and see if I can reproduce there. If I can, I can send it over.

My chrome version is 23.0.1271.97 m, same as on the friend's machine and the server.

Got another friend to test. He can't reproduce; he's on W7, chrome v23. Quite strange.

It looks like one of those problems that is influenced by the angle you hold your head at and how many coffee cups are on the desk. Today I can replicate the failure, but not at 150% zoom. Only at 110% and 125%. I've got a local example on my test server to work with and will see if I can find a workaround to what is clearly an obscure Chrome browser bug.

Found and fixed the problem (for the next FB release).

Here's the details for the curious.

With a zoomed page, browsers need to scale pixel values when translating between the document and the screen as there is no longer a 1-to-1 pixel relationship. Under certain zoom and size conditions, Chrome will round the scaled pixels assigned via css width in one direction and round the pixel values reported by offsetWidth in the other direction.

When a floatbox containing an image is closed, the image state is checked to see if it is currently in an 'inframe-resized' state, and if so, first shrinks it down to normal size before closing the box. The 1px rounding discrepancy between assigning width and measuring width causes Floatbox to continuously loop trying to shrink the image down before closing the box.

As of the next version, there must be a 5px difference between the image and the containing div before it will be considered as inframe-resized.

Note that this problem has nothing to do with the Chrome-on-Android problem that started this thread. In that one, Chrome was simply not firing click events on touches on the floatbox controls. That one was fixed by adding explicit touch handlers to the code in addition to the existing click handlers.

Thank you! I'll be waiting for 5.6.2.

In retrospect, I should have just started a thread instead and linked to this one.