No pages display after the first of a component on Chrome 11

[heydenberk]

I can verify that this does not happen on the latest release version of Chrome 9, but the problem persists in Chrome 11 dev. While 11 is a dev version, it's very possible these changes will roll down to the release version soon. Tested with booki.sh today.

[solyoung]

Confirmed. Chrome 10 beta, too.

[joseph]

Thanks for alerting me to this, guys. This is a problem that first manifested in Webkit Nightlies late last year — I raised a bug in January; hadn't realised it was still unaddressed. At that stage it wasn't manifesting in Chrome betas. The bug is here:

https://bugs.webkit.org/show_bug.cgi?id=52987

This is the simplest test-case I've come up with:

http://pockets.inventivelabs.com.au/webkit-out-of-bounds/reduced.html

You'll also find a test for this bug in tests/bugs/webkit-out-of-bounds

I hope, but I'm not wildly confident, that a fix will go in before the next Chrome public release.

Sol, you mentioned in an email that it was affecting Honeycomb too, which surprises me. I haven't seen it in the emulator yet.

I haven't found a workaround for this yet. Any experimentation would be welcome. Even just detecting the problem appears to be a significant hurdle.

[jakobholmelund]

This is a very big problem indeed. It is now also in Chrome 10.0.648 really ruins my day.. Will be searching for fix today !! not nice to only support firefox ;)

ok.. I found a solution. It will take alot of rewriting, and im now konsidering doing it in a fork, since it may not be everybody who want's this. Right now monocle uses the body tag to handle columnisation. My fix will instead use the div id="body" to handle this. I found that a div with overflow:scroll doesn't seem to have the problems that the body tag has.

div#body{

height:200px;
-webkit-column-width: 200px;
overflow:scroll;

}

and then you can hide the scrollbars with

::-webkit-scrollbar {

width: 0px;
height: 0px;

}

Dunno if the hiding is nessesary

I have made a small test-cas to illustrate it.. Its not hosted, and actually cant be run on the filesystem since webkits security wont allow..

http://org-images.appspot.com/i/blob?id=agpvcmctaW1hZ2VzchALEghCbG9iRmlsZRjhxQgM

[jakobholmelund]

Well i've tossed some ideas around and have come to the conclussion that i should add a "column"-wrapper to every iframe and the style that. I'm on weekend from now on. But i would very much like to hear what you think joseph, this might not be a bad idea to implement, and maybe it is a peace of cake for you ? If it is i'm not spending 8 hours on monday going through the code :P i've tried different stuff today, to see if this could be implemented in an obvious and simple way, but i dont think it can..

[joseph]

Thanks madfarmer, I've pushed a workaround based on your initial suggestion: e3f23b2ec28b6819a2caf655f43a007c91b56260

I'd appreciate assistance from anyone affected by this bug as to whether:

a) the workaround works for you b) the method of identifying affected browsers in src/compat.js (columnOverflowPaintBug) can be improved

[joseph]

Oh, also, Dave Hyatt found and fixed the bug in WebKit overnight. Hopefully it'll roll into Chrome betas in the next few weeks.

[jakobholmelund]

Can we close this issue :) ?

[joseph]

Oh yes, good idea.