Dear Admin,

after upgrading from 5.72 it seems that i'm having troubles with the automatic execution of options.js.

what did i do during upgrade:
- i renamed the old floatbx dir to floatbox.572
- i created a new floatbox dir and copied all the files from the archive into it except configurator.html and the doc directory
- i placed my parameters from old options.js into the new one as follows:

globalOptions: {
  // Paste your license key between the quotes below, or enter it in the configurator form.
  // (Separate multiple license keys with spaces or commas.)
  licenseKey: "ExfZEBCcExvo xxxxxxxxxxxx",
  showStartGif: false,
  autoFit: false,
  fadeTime: 0,
  mobileNewWindow: false,
  itemNumberPos: "br",
  infoLinkPos: "br",
  caption2Pos: "bl",
  captionPos: "tl",
  shadowSize: 8,
  shadowType: "halo",
  contentRoundCorners: "none",
  boxCornerRadius: 4,
  showOuterClose: true,
  showClose: false,
  centerNav: true,
  autoFitSpace: 20,
  boxColor: "#f0f0f0",
  overlayOpacity: 0,
  panelPadding: 0,
  padding: 0,
  innerBorder: 0,
  outerBorder: 0,
  contentBackgroundColor: "#f0f0f0",
  strongTextColor: "#ffcccc",
  textColor: "#ffcccc",
  resizeDuration: 0,
  doAnimations: false
},

to prevent a caching issue, i've changed the includes:

 <link type="text/css" rel="stylesheet" href="/floatbox/floatbox.css?v=601" />
 <script type="text/javascript" src="/floatbox/floatbox.js?v=601"></script>

when i set the options

  showStartGif: false,
  autoFit: false,

while doing a fb.start() it works, but not when only in options.js

please help how to debug it.

thanks and best regards,
wolfgang

The showStartGif and autoFit options work fine for me when I place them into the globalOptions section of options.js of my test instance.

Because I can't reproduce the issue, I'll need to see your pages online somewhere to determine why the failure is occurring in that context.

dear admin,
thanks for your reply.
while preparing a test page for you, the problem stopped, so it seems to be a cache issue, even with this 'v=xxx' trick.
thanks for your prompt reply and your good work with floatboxjs
best regards from austria,
wolfgang

dear admin,

even when the options.js seems to work now, the new 6.0 feature

showStartGif: false

doesn't work for me.

you can try it at
http://www.lab.mynaru.com

scroll to the footer and click there on 'terms' - i've implemented a 5 second delay in the content getting loaded by floatbox, so you see the spinning gif at your click position for 5 seconds even with the above option set.

Cache management for the dynamically loaded Floatbox bits (such as options.js) can be a bit tricky.

Options.js is loaded with a querystring of "?v=x.y.z" on it, where x.y.z is the Floatbox version number. This is not related to or dependent upon any querystring you might add to the loading of floatbox.js.

No doubt in your case the options.js?v=6.0.1 file was loaded into cache prior to being modified with the showStartGif and autoFit settings, and subsequently fetched from cache.

It's a better idea to manage cache issues by changing the folder path instad of the querystring. For example, I always load the Floatbox files from a /floatbox_xyz/ folder instead of a plain /floatbox/ folder. Currently I'm loading from /floatbox_601/. If I modify options.js and want to make sure repeat visitors pick up the changes, I would need to change the folder to something like /floatbox_601a/, and change the include lines for floatbox.js and floatbox.css to match. If I just change only the querystring used on the include lines, the options path will remain /floatbox/options.js?v=6.0.1 and so will match the cache.

Unrelated to cache management, note that you can append your options.js file to floatbox.js and so load one file instead of two. This capability is for folks who want to squeeze every millisecond of load optimization they can out of their pages.

Re: showStartGif.

It's a subtle difference, but what you are seeing on the terms link on your test page isn't the startGif - it's the slowLoadGif. The startGif is the same spinning graphic but shown in the middle of a floatbox that is expanding up when opening or down when closing. showStartGif:false turns off that spinner during opening and closing animation.

When content takes longer than 777 milliseconds to load from the network, the spinning gif is shown to give the user feedback that something is happening -- kind of like the ubiquitous Windows hourglass. This behaviour is unaffected by the showStartGif option.

thanks for your detailed and quick replies.

is it possible to disable the behavior for

slowLoadGif

because inside the plattform my code deals itself for loadinfo with the powerfull afterItemStart and does it's own loader animation immediately.

in previous verison i've just hacked the floatbox css, but i thought it would go easier now because of your previous reply:
http://floatboxjs.com/forum/topic.php?id=1737

I'm not sure that makes a lot of sense. afterItemStart fires after the item starts (obviously), which means after it has been fetched from the network and presented in a fully opened floatbox. It can't be used to provide activity feedback to the user during the network fetch of the content.

You can still hide the slow-load spinner by modifying floatbox.css or by overwriting <colorTheme>/loader.gif with a blank.gif copy. I can't think of any circumstances where it's a good idea to do this, unless you have your own "loading..." display hooked into the initial click action.

The best solution is to optimize the loading times of the floatbox content so that it comes in quickly and consideration of what happens during a loading delay never come into play.

i've replaced the loader.gif with blank.gif and also again the css hack with change in floatbox.css:
#fbx.fbx .fbLoader{display:none}

now i don't get the spinner again as before, but still a grey box placed after those 777msec where the last click occured. this box stays till the floatbox loaded successfully.

for your understanding the whole plattform is dealing with wait time while loading by itself for different kind of acctions and content.
that means, if there some event occurs, where the user has to wait till it loads complete, there is a shade overlayed and a css anim. this gets disabled when the load is complete or if it fails after a longer timeout, the site gets redirected.

for floatbox i'm initiating it before calling a fb.start() and the afterItemStart confirms then the successfull load and disables the shade than again.

i've adapted the before described term call that you can see the behaviour of our internal 'loaderinfo' and how the slowLoadGif box disturbs (in this example the slowLoadGif only covers the footer line at click position - but on other places it's much more disturbing.

pleace give me a hint how to set it's size to zero px or display:none.

Just for you, I'll look into having the showStartGif setting also apply to the slow-load indicator in the next Floatbox release. Then I'll sit back and wait for the complaints about the changed behaviour.

Or perhaps add yet another Floatbox option (it'll be the 170th option) to specifically disable showing the slow-load thingy. There's nothing in 6.0.1 (or previous releases) for doing that.

Thank you very much, that would make my life much easier