Chromium build bustage caused by r43317 (making RefCountedBase::m_refCount private) See http://trac.webkit.org/changeset/43317 Our AccessibilityObjectWrapper still needs the old semantics of RefCounted (when it was zero initialized). We haven't fixed that yet because we are waiting to get our WebKit layer side into svn.webkit.org. That side uses COM style reference counting, which leads to needing the object to be initialized with a ref count of 0. This is all super annoyingly ugly, and I really want it to be fixed. But, I want the WebKit API to be upstreamed more than that, and so I am putting off this :-( Ugly workaround patch coming up...
Created attachment 30063 [details] v1 patch
Comment on attachment 30063 [details] v1 patch Eek.
Landed as: http://trac.webkit.org/changeset/43322
Another way to fix this would be to not use RefCounted until you can match its normal semantics. RefPtr works fine as long as there are ref and deref functions; they don't have to come from the RefCounted class template.
> Another way to fix this would be to not use RefCounted until you can match its > normal semantics. RefPtr works fine as long as there are ref and deref > functions; they don't have to come from the RefCounted class template. That's a very good suggestion!