Fwd: milkbox 3.0.x issue in FireFox at zoomlevels != 100% + fix -- really a mootools issue with non-integer CSS values reported by browser.

[Ger Hobbelt]

See bottom.

Bottom line:

FireFox is perfectly capable of reporting floating point widths, such as 'border-left-size: 0.9999916px' and mootools will treat that one as 0 (zero) in getComputedSize() et al: .toInt()-ing CSS pixel values will give you some nasty surprises, at least, thanks to unpredictable rounddown losses, so simple calculus transforms into calculus with error margins. ... Fun!

(In my experience, only Mech. Engineers remain sometimes able to cope with this 'error expression' sort of thing beyond graduation; IT folks simply go <core dumped; insert boot disk> at the mere mention.  >;-)  )

Fix for now:

don't try to precisely (pixel-perfect) dimension and/or position your <div>s and whatnot, but consider the amount of rounddown error accumulation along the way and compensate for the worst-case scenario by taking off a couple of pixels at judicious spots. Be a crafty bugger.

If mootools would be made to produce these non-integer values as reported by the browser, e.g. by migrating a bundle of .toInt()s to .toFloat()s, then a much-less-than-1px 'error correction term' in user code will suffice, but until then you'll have to analyze the internals and track the error term / accumulation yourself: 1px won't always be enough.

(And in case you expect jQuery and others are smarter than this, then I'm sure I can sell you this amazing deal in Greek bonds too...)

Posting/forwarding this here, because I think it's a mootools issue and:

- somebody else might be saved a toupee purchase thanks to a lucky google hit here,

- I'd like to hear whether this is:

  - known issue, bloody tough to fix and really you can't fix it completely (once you enter the floating point arena, there's always the error expression in any math-turned-computation to consider, if only theoretically ;-) ).

  - Jeez Louise, why on earth did your user jiggle that bloody CTRL+scrollwheel?!

  - me being blind and dumb once again

Cheers!

Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   g...@hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------

---------- Forwarded message ----------
From: Ger Hobbelt <g...@hobbelt.com>
Date: Fri, Feb 10, 2012 at 2:50 AM
Subject: milkbox 3.0.x issue in FireFox at zoomlevels != 100% + fix -- really a mootools issue with non-integer CSS values reported by browser.
To: Luca Reghellin - Milkbox <mil...@reghellin.com>


FYI. Ran into this one this evening while working on someone's site. FF rendered milkbox wrong while Chrome did fine; turned out the zoomlevel was the cause (in this case, the user / test machine had a FF zoomlevel of /nearly/ 100% but not exactly that. ... Let's just say that it was an interesting test of my stamina. :-) )

See https://github.com/GerHobbelt/milkbox/commit/a43076b1be5623666d56be9a7b1393bfa7599348, particularly the comment block in there (the links listed in there provide further info).

Way to reproduce:

- start FF, open a page, either view a milkbox item with a caption already, or do this later.

- Use CTRL+mousewheel to zoom in/out a couple of times; see the caption disappear at various zoomlevels, particularly at zoomlevels < 100%.

This is due to the following: when you inspect element in FF/FireBug, you'll note that the left-border of the controls section will show a FLOATING POINT number such as 0.916px instead of 1px.

Milkbox uses mootools to getComputedSize(), etc. and in there, 0.916 and such numbers are, thanks to .toInt(), converted to 0 (zero), which means that the caption div width will be calculated such that it's essentially 1..2 px too wide (these rounddown errors accumulate in there!), resulting in that div ending up BELOW the float:right controls div, and overflow:hidden, etc. make the caption 'disappear' that way.

The problem is really with mootools core/more which doesn't cope with non-integer sizes (widths, etc.) delivered by the browser (everything is .toInt() instead of .toFloat() in there, for starters!), but fixing it at mootools level is a serious undertaking, so I 'hacked' a workaround into milkbox itself -- it's basically a situation-specific 'compensation' error correction assuming-close-to-worst-case, thus tolerating a cluster of unpredictable round-down (floor) numeric value losses while widths are calculated / derived.

[Olmo Maldonado]

You've got a way with words! 

I believe that this isn't the first time we've heard that rounding errors cause well.. errors -- at least unexpected designs/results. 

Best step in the right direction is to report this issue at Github: http://github.com/mootools/mootools-core/issues and mention the rounding error in a jsfiddle.

We'll go from there.

[Olmo Maldonado]

You've got a way with words! 

I believe that this isn't the first time we've heard that rounding errors cause well.. errors -- at least unexpected designs/results. 

Best step in the right direction is to report this issue at Github: http://github.com/mootools/mootools-core/issues and mention the rounding error in a jsfiddle.

We'll go from there.

On Thu, Feb 9, 2012 at 8:38 PM, Ger Hobbelt <g...@hobbelt.com> wrote:

[Ger Hobbelt]

On Fri, Feb 10, 2012 at 4:36 AM, Olmo Maldonado <olmo.ma...@gmail.com> wrote:

You've got a way with words! 

Thanks. :-)  Some days I just get hit by a lucky ray like that.

 

I believe that this isn't the first time we've heard that rounding errors cause well.. errors -- at least unexpected designs/results. 

Best step in the right direction is to report this issue at Github: http://github.com/mootools/mootools-core/issues and mention the rounding error in a jsfiddle.

We'll go from there.

Roger Wilco. The issue showed up through methods defined in Mootools More (getComputedSize()), so I'll report it for both. I expect to produce a test case later today (Monday) or Tuesday.

When inspiration strikes and time allows, I'll see if I can produce a clone/branch with some 'floating point dimension support' fixes - I know where I'ld fix it in there; trouble is that rigorous correction of the issue touches quite a few spots (lots of case-relevant .toInt() in Core + More).

[Olmo Maldonado]

right.. btw, it'll prob. go against 1.5 branch