Thanks Steven.  I've come to the conclusion that this is indeed bug in Safari/MacOS.  Hopefully Apple will do the right thing. :)

Steven,

I've just started using slideshows on load and I'm having this exact problem.  I'm running MacOS 10.10 and Safari 8.

I'm not seeing the problem with Chrome on this same Mac, but am having the same issue on another Mac running 10.10.  However, I'm not seeing it with yet another running 10.9.

Can you confirm if possible, that this is NOT a Juicebox issue?

Using W3C validation service throws up a LOT of errors with my code ... most of which seem to be in Juicebox's embed code.  I don't really understand what I'm looking at here, so any help you can offer will be most welcome.

(This site is still in test phase, so may be changing but the galleries are now pretty much set ... http://www.grantsymon.com/test/e/start.html)

More control of font handling and placement/position for caption/titles/numbers etc.

The standard font positions are quite intrusive into the image area, which whilst it may suit some galleries, it doesn't suit them all.

Thanks Steven.

What I would like to do may not be possible, but perhaps you could help me further.

As mentioned I have 2 sub-domains for my mobile site (French and English). Both serve the same JuiceBox galleries via an iFrame (so I don't have to produce them twice).  Both sub-domains have a language choice page as the index page, which seems logical to me (though obviously not essential)

I'd like the back button to go back to the first level of the domain that's being used to view the galleries ... however ... my galleries are not embedded, they're in an iFrame.

Absolute paths obviously don't work.  The default 'back one level' does work, but only if people visit the index, or menu pages first (so not if someone sends them a direct link to a specific gallery).

Is there a way to have the back button go to a relative URL, which would be, for example : /e/   
and which would work for both sub-domains (mobilef.grantsymon.com + mobile.grantsymon.com)?

I have been thinking about building a new responsive site to cater to desktop/mobile, in order to simplify things and using embedding instead of iFrames, so if this would resolve the issue ... even though I've not managed to get embedding working from remote directories ... then I'd be happy to go this route).

Hi Steven,

thanks for the reply.  I'm currently learning a lot about building websites and will probably soon be re-working the Desktop site to remove the iFrame and ancient code.

However ...

I should have been more precise.  There is a re-direct on the Desktop site, so I'm guessing you didn't see the mobile site?

It is not in in an iFrame, it just runs straight, un-embedded, Juicebox.  There's a Home Page, but once you click a link, it's pure Juicebox.

mobile.grantsymon.com

If you open the site in a Desktop browser, you'll see that the gallery is not res-sizing when you re-size the window.  The button-bar buttons are not working either and the initial image isn't loading.  There's clearly something wrong, but I'm not sure what is the best way to fix it.  Is image size an issue?

Ahh ... okay Steven.  I'm using a MacBook Pro with an external monitor attached.

Don't you think you should be looking at the monitor dimensions instead of the device?  I could have an 11" portable with a 30" monitor.

(It makes no difference setting screenMode="LARGE")

Steven,

can you tell me at what point the largest images 'kick in'?  I'm looking at a gallery on a 1920x1200 monitor.  In full-screen mode the Large images kick-in, but when viewed normally, it's the 1024x768 images that are used.

Also ... my website puts JBx in an resizable iFrame, I'm guessing it's the size of the frame that will determine the source image size?

Also on Thumbnails ...

Why do we have to have these pages of thumbnails?  Can't they just 'slide'.

(I know they can, because I posted a demo from some javascript geeks site the last time I requested this).

Microsoft have never really cared much about colour.  I believe that you may still have to turn colour management on in IE??

Anyway ... you won't have these issues if you play the game the MS way.  They 'expect' all images to be in sRGB.  This is a fairly standard 'conventional monitor' space, in 2.2 gamma.  If you convert all your images to sRGB prior to uploading, then you won't get any nasty surprises, on any monitor, on any Mac/PC or in any browser.

Sure, some of your images which look fantastic in AdobeRGB (or other wide gamut spaces) will not look so good in sRGB (think ... photos of carrots, or oranges) and yes, the tiny number of people surfing the net, who have a wide-gamut monitor will not enjoy your images as much ... but the others who use non-colour management aware browsers or OS's, will not get the fluorescent greens and other horrors.