Thank you for sharing your code.
Hopefully it will help others who want to achieve the same thing (to hide navigation buttons in the combination of Large Screen Mode and Touch Input Mode).

That's correct. Instead of saying "in Small Screen Mode/Touch Input Mode" I should probably have said "in Small Screen Mode and Touch Input Mode (the combination used on an iPhone which you referred to)".

For other users reading this thread, more information about Screen and Input Modes can be found in the Gallery Tour.

I'm not sure if you are specifically referring to thumbnail or main image navigation buttons but the current configuration options which change the visibility of the navigation buttons are:
showImageNav (which affects the main image nav buttons in both Small and Large Screen Modes) HOVER/ALWAYS/NEVER
showSmallThumbNav (which shows or hides the thumbnail nav buttons in Small Screen Mode) - TRUE/FALSE

Unfortunately, there's no configuration option available which would allow you to change the visibility of the navigation buttons for a specific Input Mode.

If you wanted to try to hide navigation buttons when they would normally be visible (for example), then you could perhaps detect which Screen Mode is currently being used (via the Juicebox-Pro API getScreenMode() method) and then implement some custom CSS and JavaScript to override Juicebox-Pro's own handling of the nav button visibility.
This might be fraught with difficulty (there are often unforeseen knock-on problems with such modifications) and I would not recommend it but you are free to try it if you like.
Please note that there is no Juicebox-Pro API method to determine which Input Mode is currently being used. You'd need to write your own routine to detect whether a touch screen is in use (if you wanted to).

Thank you for posting your suggestion in the Feature Requests forum thread.
It will certainly be seen by the developers there.

It looks like your gallery's Splash Page image is being squashed by the following custom CSS code from line 154 of your 'style.css' page:

.content-box .item img{display: block;width: 100% !important;height: auto;-webkit-transition: all .5s ease; /* Safari and Chrome */-moz-transition: all .5s ease; /* Firefox */-ms-transition: all .5s ease; /* IE 9 */-o-transition: all .5s ease; /* Opera */transition: all .5s ease;}

... specifically the width: 100% !important; entry.
This custom CSS rule is being applied to all <img> tags within .content-box .item (which is where your gallery is) including those in your gallery.
Normally, Juicebox center-crops the Splash Page to fill the viewport but your custom CSS overrides this and forces the image to be displayed with 100% width no matter what size the Splash Page is.

First of all, try removing !important from width: 100% !important; to see if this helps. (This might be all that is required to solve your problem.)

You could also target your custom CSS to only those elements on your web page that require them using further CSS selectors.

Another possible solution might be to use the following CSS:

.jb-splash-holder img {
    width: auto !important;
}

Add it to your web page after your 'style.css' file is loaded (maybe at the end of your gallery's 'jbcore/classic/theme.css' file) so that it is used in preference to your own custom CSS for the Splash Page image.

The only problem I can think of at the moment is that your PNG image will not be scaled when navButtonIconSize is used.

However, if navButtonIconSize is used, then the navigation button background (the semi-transparent grey circle) will be scaled and, if it is large enough, it will become visible behind your PNG image.
To counteract this, you can make the navigation button background completely transparent by setting navButtonBackColor="rgba(0,0,0,0)" (in JuiceboxBuilder-Pro's 'Customize -> Color' section).

Otherwise, as long as your PNG image looks OK in both Small Screen Mode and Large Screen Mode, I do not see any other obvious problems or pitfalls.

One possible solution would be to use the Open Image button on the Button Bar.
The Open Image button will open the image's linkURL (in a tab specified by the corresponding linkTarget).
(If an image does not have a linkURL entry, then the Open Image button will use the imageURL instead.)

Therefore, you could add linkURL entries to your gallery pointing towards the files that
The linkURL entries can be relative (to the page containing the gallery's embedding code) or absolute (in the form 'http://www.example.com/images/image0001.tiff').

If using JuiceboxBuilder-Pro to create or edit your galleries, you can add linkURL entries on the 'Images' tab. (Just click a thumbnail to reveal the input fields.)

If you like, you could change the Open Image button's icon (following the Using Custom Icons support section in the Theming Guide) and change its rollover tooltip text using the languageList configuration option. (Please see the International Gallery Text support section for details.)

Alternatively, you could just set up links in your image captions to link to your custom files.
You can add links to captions using HTML formatting (specifically the <a> tag) as noted in this FAQ:
How do I add HTML formatting to image captions and titles?

If using the caption suggestion above, you could even use the download attribute in your caption link (supported by Chrome, Edge, Firefox and Opera) to instruct the browser to download your custom file instead of navigating to it.
A caption link (entered via JuiceboxBuilder-Pro's 'Images' tab) might look something like this:

Google's PageSpeed Insights tool can certainly be very helpful but it is also useful to remember that the results are just Google's ideal recommendations (without any knowledge of the content of the page or if any of their recommendations can even be implemented).

With regard to the 'render-blocking JavaScript and CSS' message, the results note:

That is correct but, knowing the content of your web page (the only content above-the-fold is your Juicebox gallery), it is absolutely necessary to wait for the 'juicebox.js' and 'theme.css' files to load before the gallery can be displayed and is visible.

The 'Prioritize visible content' message notes:

That, again, is true. Additional resources (the gallery's 'config.xml' file and the JavaScript, CSS, image and font files in the 'jbcore' folder) are required due to the design and required structure of Juicebox. However, there is nothing that can be done to incorporate all these resources directly into the gallery's HTML embedding page and the message is really nothing to worry about.

Knowing the way that Juicebox works (requiring the 'juicebox.js' and 'theme.css' files to be fully loaded before the gallery can be displayed and also requiring an external XML file and the 'jbcore' folder) the two warnings above can be put into context. They are not truly problems but necessities for the gallery to be displayed and function correctly.

Try entering other popular websites (such as 'http://google.com' or 'http://amazon.com') into Google's own PageSpeed Insights tool and you'll see that the results are often similar to those reported for your own Juicebox gallery web page.

When using any library or package which requires a number of external resource files (such as Juicebox and its 'jbcore' folder), you'll find that the PageSpeed Insights tool gives similar results.

You could certainly set HTTP cache headers within an .htaccess file if you like. Try a web search with terms such as 'http cache header htaccess' to find out more information.
However, such a decision (to force browser caching or not) is really up to the individual user (and not directly Juicebox dependent).

Incidentally, all these messages refer to the Speed section. The User Experience section for your Juicebox gallery page gives a score of 100/100 with the message "Congratulations! No issues found.".

I hope this helps to clarify things.

Out of interest, I've just loaded a Juicebox-Pro v1.4.1 gallery into an iframe and the Expand Button seems to be disabled in this version (just like in v1.5.0).

The Expand Button is disabled by design when the gallery is loaded into an iframe to avoid a lot of potential problems.

There are several things to consider such as the values of useFullscreenExpand and expandInNewPage and the browsers and devices being used to display the gallery. (Please see the Expand Gallery Behavior for some more information. Expanding a gallery can be quite complicated!)

Also, not all users will be using up-to-date browsers which support the Fullscreen API (perhaps in corporate environments).
Juicebox supports IE 7 and later so we need to be sure that our user base will not encounter any unexpected or unusual behavior in older browsers. IE 7 is certainly a bit long in the tooth now but the Fullscreen API was first supported by IE in version 11 and there seems to be more than a few people still using IE 8, IE 9 and IE 10 (over 10% of the total browser market share).

I would normally recommend that you use the current version of Juicebox-Pro but if you find that Juicebox-Pro v1.4.1 works for you and you are not affected by any bugs which have since been fixed in subsequent versions, then you are certainly free to continue using v1.4.1.

I'm not sure how relevant this is to Juicebox but I appreciate you taking the time to point this out and I have notified the developers of your post above. Thank you.

It is true that metadata is not retained when JuiceboxBuilder resizes images but the loss of metadata is happening within a desktop application on the user's computer (rather than via the upload functionality of an online service) and then the files are being uploaded to the user's own web space. (We do not host any user galleries or sites at all.) I guess it's not for me to say how similar (or different) the two scenarios are.

Incidentally, I've just uploaded a test image (with EXIF and IPTC data) to a Showkase v1.6.1 site's Library and the image's metadata was retained after Showkase had resized the image. It looks like issue affects only JuiceboxBuilder.

As I mentioned earlier, it's not that JuiceboxBuilder is intentionally going out of its way to strip metadata from images, it's just that when an image is resized, the metadata would have to be read and stored somewhere before resizing and then written back to the new image after resizing. I do not know if the Adobe AIR API (which JuiceboxBuilder uses) has any methods available that could be used to make this possible. (I expect there would need to be different metadata read and write functions for different file types.)

I realise that, from a user's perspective, the issue is simply that metadata is not retained and the reason why this happens is not important but giving a little background information may at least help in understanding the problem.

Adobe seem to have been slow in implementing this in Muse (see this forum thread) and I do not know if AIR applications are still lagging behind. However, I'm sure the developers will investigate further.

Thanks, again.

It seems strange that this error message would appear in only certain browsers (but not others).
I would expect such a problem to affect all browsers (or none).

Try clearing your Safari browser's cache before reloading your gallery's web page to see if this helps.
Also, if you have any extensions installed in your Safari browser, try temporarily disabling them to see if this makes a difference.

If you continue to experience difficulties, please post the URL to your gallery's web page so that I can take a look at the problem for myself and hopefully help further.

In the meantime, maybe this FAQ will help:
When I view my gallery I see the message 'Config file not found'. How do I fix this?

When you upload images via the WordPress media window, the images in your WP-Juicebox gallery should initially be in the order in which they finished uploading.

To sort images after a gallery has been created:
(1) 'Edit' the post containing the gallery
(2) Click the 'Add Media' button
(3) Select the 'Insert Media -> Media LIbrary' section (selected by default)
(4) Choose 'Uploaded to this post' from the drop-down menu
(5) Drag and drop the images into your chosen order
(6) Close the 'Add Media' window

You may need to clear your browser's cache after reloading the gallery.

If the images initially look like they are in the right order in the media window but do not appear in this order in your WP-Juicebox gallery, just drag and drop a thumbnail into a new position and then drag it back. That should be all that is required to change the order from the 'finished uploading' order to the visible 'menu' order.

You're welcome!

Thank you.