[Webkit-unassigned] [Bug 89000] [CSS Regions] Fix the lifecycle for the flow objects and their renderers

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 11 15:54:41 PDT 2012


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





--- Comment #33 from Eric Seidel <eric at webkit.org>  2012-07-11 15:54:40 PST ---
(From update of attachment 151436)
View in context: https://bugs.webkit.org/attachment.cgi?id=151436&action=review

> Source/WebCore/dom/WebKitNamedFlowCollection.cpp:65
> +    NamedFlowSet::const_iterator end = m_namedFlows.end();
> +    for (NamedFlowSet::const_iterator it = m_namedFlows.begin(); it != end; ++it) {
> +        WebKitNamedFlow* namedFlow = *it;
> +        if (namedFlow->getFlowState() == WebKitNamedFlow::FlowStateCreated) {
> +            if (!index)
> +                return namedFlow;
> +            --index;
> +        }
> +    }

So this implementation has an odd quirk that if a flow is instantiated (NULL) and then later moved to (CREATED) it will push all the observable flows after it "down by one" in the index.  Basically, iterating this collection is no-where-near stable.  I guess that's generally true of live collections like this.  Seems like an odd spec/implementation choice.

Also seems like a behavior we could test.

> Source/WebCore/dom/WebKitNamedFlowCollection.cpp:77
> +WebKitNamedFlow* WebKitNamedFlowCollection::flowByName(const String& flowName)
> +{
> +    NamedFlowSet::iterator it = m_namedFlows.find<String, NamedFlowHashTranslator>(flowName);
> +    if (it == m_namedFlows.end() || (*it)->getFlowState() == WebKitNamedFlow::FlowStateNull)
> +        return 0;
> +
> +    return *it;
> +}

I assume it's spec'd that these flows are ordered and flows with duplicate names return the first?

> Source/WebCore/rendering/RenderNamedFlowThread.cpp:193
> +    if (canBeDestroyed()) {
> +        destroy();
> +        return;
> +    }

Is this some sort of ref-counting solution?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list