Re: SVG in Firebug, large memory leak?

On Dec 18, 10:18 am, Boris Zbarsky <[email protected]> wrote:
> On 12/18/09 9:04 AM, Steven Roussey wrote:
>
> > Since it is an inline style, it should just be changing the SVG
> > element's style attribute.
>
> And storing the old value somewhere, right?  Or something?  And
> rebuilding the entire HTML view using domplate in the process?

Yes on the storing the old value somewhere. I have tried to keep my
code changes and bug fixes contained to the html panel, though I have
been changing the layout panel recently. And there are a few things in
the CSS panel I'd like to change, so I will hopefully know the answer
to that question when I look at that code.

It does not rebuild the entire HTML view AFAIK. It invalidates a node
(and its children), and since we are at the leaf level, I don't think
it is much. Notice how I said I think. I haven't had a need to look
into it very deeply thus far.

> My current suspicion, and one I've been meaning to investigate for a
> bit, is that domplate leaks somehow.  Does performing the same style
> change that Firebug is doing here directly through script cause the same
> memory issue?  Does disabling the domplate mutation observers cause the
> issue to go away?
>
> -Boris

I guess I can add some temp UI to turn the observers on and off and
test that theory, mabye as an extension to firebug. Can't just comment
them out of the code though.

I'm guessing that domplate was written a looong time ago. I don't know
how careful the author was in handling dom references, for example. In
domplate or everywhere.

I started a project to use a more modern js lib for a firebug UI
(skipping xul altogether) and run it in jetpack (or another browser,
which would let me use another cpu core) and communicate back to the
firebug core. The communication gateway, crossfire, is new and jetpack
is new, and my code is new, and all that newness means bugs and I
loose my patience for the side project. Next year...

-steve--