Bug 25596 – Chromium build bustage caused by r43317 (making RefCountedBase::m_refCount private)

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[Darin Fisher (:fishd, Google)]

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...

[Darin Fisher (:fishd, Google)]

Created attachment 30063 [details]
v1 patch

[Dimitri Glazkov (Google)]

Comment on attachment 30063 [details]
v1 patch

Eek.

[Darin Fisher (:fishd, Google)]

Landed as:  http://trac.webkit.org/changeset/43322

[Darin Adler]

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.

[Darin Fisher (:fishd, Google)]

> 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!