1 (edited by matthewswift 2014-04-07 21:33:20)

Topic: missing config.xml error viewing locally

Juicebox Pro and Juicebox Builder 1.3.3, on Win7 Pro and second machine with Win8 Pro, IE 11, I cannot preview a gallery that I have created with the builder.  The error is that config.xml is missing, but that file is really there in the default location.  I build a test gallery, just two images, all default settings, then load index.html into IE.  At first I get a page with the two images, a plain html page, and at the bottom IE says in a popup bar:  "Internet Explorer restricted this webpage from running scripts or ActiveX controls." then a button "allow blocked content."  Press the button, then I get grey screen with "Juicebox Error: Config XML file not found."  I tried placing the local folder on the windows desktop, on a Network drive, same result.  Simple path, no weird characters.   If I upload the very same directory to a web server, it works fine from IE and Chrome.  Here's one example: http://tridentgallery.com/testjbox2/ and zipped is http://tridentgallery.com/testjbox2.zip

I expect that some "security" setting in IE needs to be changed, but if so, this is a bug for a misleading error message (config XML is indeed there where it's supposed to be).  IE "security" settings are "medium-high" for internet, "medium-low" for "local intranet" which are both default settings.  "Protected mode" checked in internet, not in intranet.

Re: missing config.xml error viewing locally

Certain browsers (IE11, Chrome and Opera) have security restrictions which prevent the loading of XML files (like the one used by Juicebox to store the configuration options and image data) locally (on your own computer). Unfortunately, there is nothing that can be done to circumvent this behavior.
Please note that this happens only when trying to load galleries locally (from your own hard drive) and does not happen once galleries have been uploaded to a web server.

We already have Juicebox FAQs for Chrome and Opera and will add one for IE11 in the next site update. (It was previously possible to preview galleries locally in IE10 but not now in IE11.)

In the next version of Juicebox, the message displayed when trying to view a gallery locally in IE11 will be changed from "Juicebox Error: Config XML file not found." to "Juicebox can not display locally in this browser." with a link to the corresponding new FAQ.

If you would like to view your gallery on your own computer before uploading it to your website, please preview it using either Firefox or Safari.

Re: missing config.xml error viewing locally

Thanks -- the error message was very clear in Chrome, with a link to further information that explained the background.  Would be great to have the landing page give an up to date list of browsers/versions that do/don't work for local preview.  One can hope that a mechanism of explicit approval of "trusted" local XML will be future browser feature. 

Also insofar as it's straightforward to explain, it would be very nice (save people time!) to provide an explanation whether the problematic restrictions in those browsers tied to URI scheme -- file:// versus http:// for example -- or intranet versus internet, or?  I wonder if there is a local preview setup that would work with Chrome/IE (because one needs to test appearances of a site with these browsers) that is simpler to set up than a staging-test server on the internet.

Re: missing config.xml error viewing locally

Thanks -- the error message was very clear in Chrome, with a link to further information that explained the background.

We plan to introduce a similar message (and link) for IE11 in the next version of Juicebox.

Would be great to have the landing page give an up to date list of browsers/versions that do/don't work for local preview.

We will merge the FAQs into one and list all major browsers which prevent the loading of XML files locally (IE11, Chrome and Opera) in the next site update.

One can hope that a mechanism of explicit approval of "trusted" local XML will be future browser feature.

That would certainly be ideal.

it would be very nice (save people time!) to provide an explanation whether the problematic restrictions in those browsers tied to URI scheme -- file:// versus http:// for example -- or intranet versus internet, or?

The problem (with Chrome and Opera at least) is specifically with the file:// protocol.