Memory leak

[YacovGold]

Saving all windows \ Browsers will not let the GC to free the memory associate with them.
Should be something like UnRegister

private static List<Browser> _allWindows = new List<Browser>();

private static void Register(Browser browser)
{
    _allWindows.Add(browser);
    if (browser.WindowHandle == null)
    {
        browser.WindowHandle = Guid.NewGuid().ToString().Substring(0, 8);
    }
}

[kevingy]

There is a Close(). Does this not do what you would expect Unregister() to do?

public void Close()
{
    _history = null;
    _allWindows.Remove(this);
}

I agree that the names should have parity. If there is a Register, there should be an Unregister. If there is a Close, there should be an Open. The naming of one of these methods is bad.

[YacovGold]

Yes it does...
At Sunday if no one will do it - I will fork and add obsolete attribute and make UnRegister function function and make the class disposable

[kevingy]

Out of curiosity, why disposable? Do you see unmanaged resources that need additional clean-up in the Browser class?

[YacovGold]

The register is called in the ctor - How the programmer will know so the resources will be there until he calls 'Close'?
Do you have any alternative option to give the programmer the clue so he need to free resources?

The primary use of the dispose is for unmanged code, but this is also a good case...
Source

The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.

Anyway, what is the purpose of the registration?

[axefrog]

I actually already have a fix for this issue that does not require you to
manually unregistered browsers. I have the flu right now but when I'm up to
it I'll submit a fix.

On Friday, October 3, 2014, YacovGold notifications@github.com wrote:

The register is called in the ctor - How the programmer will know so the
resources will be there until he calls 'Close'?
Do you have any alternative option to give the programmer the clue so he
need to free resources?

The primary use of the dispose is for unmanged code, but this is also a
good case...
Source
http://msdn.microsoft.com/en-us/library/system.idisposable%28v=vs.110%29.aspx

The primary use of this interface is to release unmanaged resources.
The garbage collector automatically releases the memory allocated to a
managed object when that object is no longer used. However, it is not
possible to predict when garbage collection will occur. Furthermore, the
garbage collector has no knowledge of unmanaged resources such as window
handles, or open files and streams.

Anyway, what is the purpose of the registration?

—
Reply to this email directly or view it on GitHub
#108 (comment)
.

Google: axefrog@gmail.com
Skype: axefrog
Twitter: @NathanRidley
Website: http://axefrog.com / http://nathanridley.com
*Phone: *+61 (0) 475 072789

[YacovGold]

@axefrog To make it disposable or to wait for you solution?

[kevingy]

Please wait for AxeFrog. Thanks!

[YacovGold]

@kevingy How can I send to you a private message?

[axefrog]

Hey, haven't forgotten about this. The whole concept of windows and authentication token management have been separated into a context object. When creating a new BrowserWindow class, you can specify an existing context object or let it create its own. The context object provides all of the functionality that was previously in static properties for window management. When spawning child windows and so forth, the context object is automatically shared with the child. In this way, you can have multiple isolated browsing contexts that are unaware of each other, and each one is still fully aware of all of the windows that were created in that context. A bunch of unit tests are currently broken at the moment though so I need to fix those before submitting the updated code.

[kevingy]

GitHub removed private messaging some time ago for a variety of reasons, not the least of which was to promote transparency. If your private message concerns this issue, I would prefer it to be public. Otherwise, I can be reached via kevingy@yahoo.com

[mikaelliljedahl]

#121 (comment)