Fix for memory leak

Fix for memory leak


BUG=96368
TEST=

[sky, 2011-10-18 02:01:23]

http://codereview.chromium.org/8294008/diff/1/views/controls/native/native_vi...
File views/controls/native/native_view_host_gtk.cc (left):

http://codereview.chromium.org/8294008/diff/1/views/controls/native/native_vi...
views/controls/native/native_view_host_gtk.cc:115: gtk_widget_destroy(fixed_);
Why does this not work when ::DestroyFixed is going to do the same thing?

[Parag Radke, 2011-10-18 12:28:46]

*This memory is allocated using gtk_views_fixed_new(void) which is   internally
call g_object_new() to allocate memory.
*When we create a GTK widget using a gtk_object_new() function, it has one
reference which is marked as floating. When you add the widget to a container,
the container must also hold a reference to the widget. But instead of calling
g_object_ref() on the widget and increasing the reference count to 2, it "sinks"
the object's floating reference and turns it into a normal reference. You could
say that the container now "owns" the widget.
      Then when we destroy the container, it calls g_object_unref() on the
widget, and the reference count becomes zero, and the widget is destroyed. That
way we're not responsible for destroying it ourself anymore.
      But with normal GObjects (using g_object_new()) which usually don't go
into containers, there is no transfer of ownership. We have to unreference them
ourself when we done with them.

*inside DestroyFixed() we are calling gtk_container_remove() to remove widget
from window_contents_ it's kind of manual unref because window_content doesn't
own the widget.


On 2011/10/18 02:01:23, sky wrote:
>
http://codereview.chromium.org/8294008/diff/1/views/controls/native/native_vi...
> File views/controls/native/native_view_host_gtk.cc (left):
> 
>
http://codereview.chromium.org/8294008/diff/1/views/controls/native/native_vi...
> views/controls/native/native_view_host_gtk.cc:115: gtk_widget_destroy(fixed_);
> Why does this not work when ::DestroyFixed is going to do the same thing?

[sky, 2011-10-18 16:12:14]

LGTM

[Parag Radke, 2011-10-20 10:57:17]

Please commit this patch.

On 2011/10/18 16:12:14, sky wrote:
> LGTM

[commit-bot: I haz the power, 2011-10-20 11:00:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/nrqv63@motorola.com/8294008/1

[commit-bot: I haz the power, 2011-10-20 11:00:08]

Can't apply patch for file AUTHORS.
While running patch -p1 --forward --force;
patching file AUTHORS
Hunk #1 FAILED at 131.
1 out of 1 hunk FAILED -- saving rejects to file AUTHORS.rej

[Timur Iskhodzhanov, 2011-10-20 11:00:19]

I set the CQ flag for you

[Parag Radke, 2011-10-20 12:15:42]

On 2011/10/20 11:00:19, Timur Iskhodzhanov wrote:
> I set the CQ flag for you

I accidentally lost the branch from which i uploaded this patch, so if it's
possible i request you to land it manually or if you want i can resubmit it
again from different repo. i am really sorry for your inconvenience.

[Timur Iskhodzhanov, 2011-10-20 12:22:44]

Sure, np:
http://codereview.chromium.org/8353034/

[Parag Radke, 2011-10-20 12:37:31]

On 2011/10/20 12:22:44, Timur Iskhodzhanov wrote:
> Sure, np:
> http://codereview.chromium.org/8353034/

Thank you :)