Hello,

a page shown inside floatbox (with scrollbar) links to another long page, where the scrollbar is missing. This happens in IE7 respectively in IE 9 and IE 8 if IE 7 compatibility mode is on. There is no body {overflow:hidden;} CSS on the page or in an associated file. The body tag contains an explicit overflow:auto. The page works fine in Firefox, Safari, IE9 and IE8 native mode.

To reproduce open http://www.leihinstrumente.com/Guitars/Electric-Guitars in IE7 (compatibility mode), in the left pane click on "payment options". A page should open in a floatbox. This one has a scrollbar if necessary. At the bottom of this page click on "terms of delivery / faq". The next page doesn't have a scrollbar (sometimes it flashes up but soon is gone). Scrollbar disappears if I refresh the content of the first page, too. The floatbox gets wider each time it's content is refreshed.

I use the conditional
header('X-UA-Compatible: IE=7')
trick to "help" IE8, hence it would be good it worked...

Works the same with FB 5.3.4 and 5.4.0

best regards
Erik

Early versions of IE - my first and only love.

The problem is related to the measuring and auto-sizing to fit the iframe content.
I've got this replicated on my test server and will dig through it to see where it goes off the rails in IE7, and possibly have a fix in the next version. No promises, as auto-sizing the wide variety of HTML that can be thrown at a floatbox has proven to be very difficult and delicate. The fact that this one fails only in IE7 makes me suspect it's going to be particularly challenging.

What can you do? I'm glad you asked...
Turn off auto-measuring of that content. In your floatbox options, set measureHTML:no and to compensate for the absence of measurement, also assign a width to the box. It looks like somewhere around width:875 might be a good starting point for your page.

Rocket fast answer, many thanks!

Is there an easy way to make this conditional? I tried to put it in a conditional comment, but this didn't work.

Can I put the options file in a different location if I specify it directly and will this one be used instead of the one in /floatbox/? If yes, I would create it dynamically and add the options if IE7 is detected...

Thanks in in advance...

On your pages you are starting the floatboxes using the fb.start() API call. Since you are in the land of code and not so much in the land of HTML markup, anything is possible.

Floatbox has a very reliable IE detector built in and exposes the results in the fb.ieVersion property. We can use this to set conditional options in the fb.start call. Maybe something like:

fb.start( 'daPage.php',
    fb.ieVersion && fb.ieVersion < 8 ?
        &#039;measureHTML:no width:875&#039; :
        &#039;&#039;
);

The second parameter to fb.start is the optional options. If fb.ieVersion is not zero and is less than 8, the second parameter will be the option string, otherwise it is an empty string.

So many thanks! This is really professional support!

I extended your suggestions with the caption property and it works like a charm! Only drawback is that very short pages open in full height, too. But since this is restricted to IE 7 and IE 8 it isn't that bad.

Thanks again!

I'd still like to create options.js dynamically since the page is in two languages and I'd like to have only one copy of all the floatbox files. Would this be possible?

best regards

You could use fbPageOptions to define your preferences, and the fbPageOptions could vary depending conditionals.

if (today == 'tuesday') {
  fbPageOptions = { ... };
} else {
  fbPageOptions = { ... };
}

I suppose the same approach could be taken in options.js as it is executable js code as well. You could, for example, conditionally define the globalOptions block that is returned in that file. Making a smart options.js file is not something I would help with or support, but if you're comfortable owning it, it might not be too difficult.

Thanks for the hint!

However, the only thing that changes between languages is the license key. Does it need to be specified in options.js or can I do this later f.e. by inserting a line

<script type=&#039;text/javascript&#039;> fb.options = {globalOptions: {licenseKey: "xxxxxxx"}}</script>

in any page? Or is there a preferred better way to do this?

best regards

First, the new release v5.4.1 is out now and I'm pretty sure it fixes your sizing and scrollbar issue in IE7, so none of this option fiddling should be necessary if you update.

If you still want to include conditional options, trying to fiddle with fb.options is not the way to go. Just do the simple conditional fbPageOptions I showed you.

<script>
if (fb.ieVersion && fb.ieVersion < 8) {
    fbPageOptions = {
        ...
    };
} else {
    fbPageOptions = {
        ...
    };
}
</script>

Many thanks! 5.4.1 works perfectly now!

Sorry, I was too quick. It still doesn't work in IE8 & IE7. I leave it without the conditional IE7 fix for the time being so you can test the original scenario.

I hope I did upgrade correctly by simply overwriting the floatbox folder...

best regards

Damn!

I think I've taken it as far as I can. My replica of your pages on my test server was not exhibiting the scrollbar problem, my my rebuild of those pages just now did have the problem (IE 7 only).

It looks like you will have to stick with conditional options for that content.

By the way, looking at your pages I'm thinking you prefer conditional comments to javascript conditionals. Since this is IE7 we're targetting, you can use those.

<!--[if lte IE 7]>
<script>
  fbPageOptions = {
    ...
  };
</script>
<![endif]-->

I have no problems with either.

However, it could be 5.4.1 has broken anchor support.

Have a look at f.e.
http://www.leihinstrumente.com/Guitars/Classical-Guitars/Joan-Cashimira-77.html
There is a link on "Scale length" that should open a floatbox with a glossary and jump to the entry "Scale length" about half way down. This used to work with 5.4.0...

I will have to revert to 5.4.0 soon...

The floatbox opens fine for me from that link in Chrome, Firefox and IE7, but it does not always scroll to the referenced #mensur anchor. There does seem to be a problem with the new scrollTo #hash capability introduced in 5.4.0. It seems to work 100% in IE but sporadically in other browsers. Thanks for the report and I'll try to get this sorted out for the next release. There's no point rolling back to 5.4.0 as the behaviour is identical. Any discrepancies in your testing are probably a result of the inconsistent nature of the problem, and those inconsistencies probably have to do with variable timings of the page load and events.

I've worked on this a bit today, and have the scroll-to-hash behaviour stabilized in all browsers for the next release. The issue was that some browsers will attempt to scroll to a hash element on their own, and the browser scroll and floatbox scroll could argue with each other depending on the timing of which one goes first.

You can get reliable scroll-to-hash behaviour in v5.4.1 as follows:

- Remove the #hash from the href path to the content page.

- Define a function on the main host page that will scroll to the desired element. Something like:

<script>
function scrollToHash (hash) {
    var el = fb.getIframeDocument().getElementById(hash),
        layout = fb.getLayout(el, true);
    fb.getIframeWindow().scrollTo(0, layout.top);
}
</script>

- Add an afterItemStart callback to the options similar to afterItemStart:scrollToHash('someElementId')

Hmm, it seems I can't set the afterItemStart option as a parameter to fb.start. I use a function to start floatbox and it is no problem to extract the hash there but I have no idea how to set the option dynamically otherwise.

I reverted to 5.3.4

best regards

There's no problem setting afterItemStart or any other of the callbacks in the options parameters to fb.start. It's easy and works perfectly reliably always and everywhere - I promise.

If you'd show me, I'd have you sorted out in a nano-second. You're probably mixing up calling a function with referencing it, and not paying attention to the difference between defining an option string and defining a javascript object.

For example, the following are equivalent:

fb.start( 'xyz.php', 'afterItemStart:doSomething()' );
...and...
fb.start( 'xyz.php', {
afterItemStart: doSomething
} );
...and...
fb.start( 'xyz.php', {
afterItemStart: function() { doSomething(); }
} );

The important thing to notice is that we are executing the function with the () operator in the string options, referencing the function without executing it in the first object definition, and defining a function that executes the desired function in the 3rd example. If we make the mistake of executing the function in the 2nd example with
fb.start( 'xyz.php, {
afterItemStart: doSomething()
} );
we will be running the callback function at the time of the fb.start call and assigning the return value of that function to the afterItemStart entry, which is almost certainly not what we want to do.

Or, to put it simply, the callbacks must either be a string to be eval'd or a reference to a function that is to be called.

You won't show me, so I'm reduced to guessing where you might be going off the rails, but I bet it's something simple like the above.


Since you posted in this thread, I assume you were working with scrollToHash function given above. Using this in an fb.start call that uses a javascript object for the options would look like this:

fb.start( 'myPage.php', {
    afterItemStart: function() { scrollToHash('someElementId'); }  // a function to be called
} );

...or...

fb.start( 'myPage.php', {
    afterItemStart: "scrollToHash('someElementId')"  // a quoted string to be eval'd
} );

Ok, I must admit that I'm a bit lost here. What I do is the following inside a function which is called in the onclick handler with this as parameter obj:

  
  var MyHash = obj.hash;
  obj.hash = '';
  fb.start(obj.href, {
    afterItemStart: "scrollToHash('"+MyHash+"')", 
    caption: "some title"
  });

Is the scrollToHash function defined on the page? Does the debugger report any errors or warnings? What happens if you change the afterItemStart string to "alert(scrollToHash)"? If you show me the page, I can help. It's pretty hard to make a meaningful contribution just by talking about a page. In my experience, looking at quoted code is mostly a waste of time. There is no context and the problem almost always lies elsewhere.

admin wrote

There is no context and the problem almost always lies elsewhere.

You are absolutely right. I wondered why getElementById delivered null if I break in scrollToHash. Then I realized that the anchors are defined the old way in the name attribute. If I use getElementsByName(hash.substr(1))[0] instead I get the element.

However, it doesn't work perfectly: If I open the box the first time after page load the row below the anchor is the topmost one and the headline is hidden. If I close the box and open it again from the same link it doesn't work anymore.

I think we close the case here, since the online page uses 5.3.4 and apparently works. I'll wait for the next version.

Many thanks for your valuable support though...

best regards