UPDATE: I’ve belatedly realize that although I quote the bug, I probably make it sound like this bug relates to all dynamic CSS, which is not the case. In general it’s probably pretty rare to find random CSS code on the web that will trip the bug. That said, if you are using Apple’s excellent Dashcode tool to create your HTML/CSS/JS, it’s actually pretty hard NOT to trip the bug.
Recently I was using a WebKit to serve up some static content in my Snow Leopard only, garbage collected app, when I ran into a crash with a call stack winding through WebKit and ending in an errant CFRelease.
The crash manifested whenever I tried to change CSS properties from JavaScript called back from my Objective-C code (via the WebKit WebScriptObject interface). Pretty quickly, I realized that I could also get the crash to happen from JavaScript code changing CSS properties in a vanilla JavaScript timer callback, or pretty much any JavaScript code post page load / initial page render for that matter.
A good bit of WebKit source spelunking later revealed this little gem:
http://trac.webkit.org/changeset/50918
Thankfully, there is more than just the opaque reference to rdar://problem/7390716 (wonder what that bug is) and we get a reference to:
https://bugs.webkit.org/show_bug.cgi?id=31429
Which bottom lines to this little beauty:
“Crash when a CSS transition is run on a CSS transform in a GC supported or GC required build.”
Sweet. I am alone in thinking that this means there is pretty much no way to use WebKit in a garbage collected (or even garbage collection supported for that matter) Mac application?
Oh, well, score one for open source; custom local build of WebKit.framework here I come!
[...] is the original post: Snow Leopard + WebKit + GC + CSS? Nope. « Cocoa Convert Share and [...]
This bug is specific to CSS transforms/transitions. If your code doesn’t use any CSS transitions (it probably doesn’t) then this bug won’t affect you.
Your page must be using WebKit-specific CSS properties like “-webkit-transform:” and “-webkit-transition-duration:” to trigger the bug.
Ah yes, good point Rob!
While I quote the text of the bug in my post, I didn’t specifically call out that it’s not all WebKit + GC + CSS code that evidences the bug. My code though, does use CSS transitions and transforms (hence me triggering the bug).
What might be interesting to other folks is how my (HTML/JS) code came to be using CSS transforms and transitions in the first place.
I didn’t run into the WebKit bug by hand crafting some tricky CSS.
All I did was to create a very simple web page using Apple’s excellent Dashcode tool (a few push buttons, a label and an activity indicator). All it takes to trigger the bug is to dynamically change the text of a Dashcode label or button or to hide or show the activity indicator.
I would agree that the lions share of folks out there embedding WebKit are more than likely be serving up more vanilla HTML/CSS content that does not utilize CSS transforms and transitions, and therefore won’t run into the bug.
In hindsight a more accurate title for the post would have been: “Snow Leopard + WebKit + GC + Dashcode? Nope.” :)
Best Regards,
Jeremy
Hey, that’s my bug! I submitted that this past summer right after Safari 4.0.4 shipped and wiped out Kiwi’s transform CSS (http://kiwi-app.net).
After having coded for quite a while in GC it wasn’t like I was going to go back — so the transforms had to go.
The good news is that it’s fixed in the nightlies. And when those ship you could potentially use some conditionals to show transforms only when they’ll work.
However, it definitely is a bow-shot warning against using GC — it is not always the code-path that gets the most testing.
Isaiah
Nice blog…did you forget the password? It’s gotten a little stale. ;-)