[Webkit-unassigned] [Bug 40302] [GTK] Memory managament for DOM GObject wrappers

[bugzilla-daemon at webkit.org]

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


webkit censorship bypass 0006 <wk.censorship.bypass.0006 at mailinator.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wk.censorship.bypass.0006 at m
                   |                            |ailinator.com




--- Comment #1 from webkit censorship bypass 0006 <wk.censorship.bypass.0006 at mailinator.com>  2010-06-11 04:53:05 PST ---
(In reply to comment #0)

> The hash map concept seems very reasonable to me in general, so I think what we should do is to always add a new reference when we return an object, even if we are only getting it from the map. This way the rule "always unref DOM objects when you are done with them" will work.

 the description of the problem is somewhat ambiguous, so here are some possible answers:

 if the intent is to create multiple gobjects which point to the same underlying webkit DOM object, this will be a complete disaster from a programming perspective by the time it gets up to high-level language bindings.

 many high-level applications rely on being able to do tests to see if a node is equal (isSameNode).

 removing such functionality can result in total project failure as, when using high-level languages, there is no other non-intrusive method for correctly identifying/comparing DOM objects.  intrusive methods include adding unique IDs to DOM Nodes, using the Node "id" field which then of course interferes with other uses (such as from javascript being executed in parallel with high-level language DOM manipulation).

 surely the problem is solved by simply increasing the refcount when returning the corresponding GObject as-is?  this seems to be the implied course of action recommended, by xan, and, if so, it is a good one.

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