Update
I've created a Patreon page at https://www.patreon.com/amaitland
All details are outlined there, work is underway!
--
See cefsharp/CefSharp#1203 for the bug tracking this issue
Current implementation relies on process-per-tab command line flag to limit the number of browser process per ChromiumWebBrowser instance to one, this worked well up until version 58 where the flag no longer works. Chromium will likely re-add support, there is no timeframe on the open tickets as yet, see https://bugs.chromium.org/p/chromium/issues/detail?id=719961 and https://bugs.chromium.org/p/chromium/issues/detail?id=717459
A handler in the main process for notification of sub-process creation and termination, and to receive IPC messages originating from the sub-process.
CEF will likely add a handler that can be used for resolving this issue and maintain the exact same functionality as exists today without having to use process-per-tab command line see https://bitbucket.org/chromiumembedded/cef/issues/2279/expose-custom-sub-process-handlers
As both options have no set timeframe we can rewrite our currently implementation to work slightly differently, bound objects will need to be registered slightly later, so won't be avaliable immediatly after the V8Context has been created. To get around this an event can be added to notify subscribers (in javascript) when object binding has been finished.
Great to hear you have a potential javascript fix.
As to funding:
I talked a bit on gitter and with @perlun privately about this. He indicated for now he didn't think it was the right time for him to take such a role. It sounded like you were taking a step back but if you potentially are returning it may be more viable.
I was recommending try to get a recurring funding source established. Recurring contributions are generally far more sustainable than specific release targeting. Paying someone (you or someone else) to do the ongoing maintenance which is certainly somewhat tedious seemed like the best option as it can be hard to get people to do that work for free on a long term basis. In addition with recurring funding a larger volume of small amounts (say $100 a year or what have you) could do so.
As it is unclear how many people might support such a funding method I was suggesting a kickstarter. The kickstartarter would serve two purposes: 1) Raise funding to cover the setup or the organization/ billing system and the first year run costs. 2) Generate an initial membership base (Kickstarter rewards could be as basic as a discounted first year membership at $80 or something).
This would ensure critical mass (so people don't have to put up money before making sure others would do so) and minimize the amount of work that would have to be done to see if it is viable.
Membership could result in access to early builds.
Another useful item might be better automate build support. Right now its a PITA and takes quite some time to manually compile builds. Some of us may require compiling our own binaries (for say mp3 support or other codecs). It would be beneficial if there was (for example) a Docker container to automate building from start to the nuget package result.
More incentives could be created (for example places like uservoice allow users to vote up features/bugs desired, members maybe get more votes to cast). I am not sure thats really the best, as it isn't really about creating a huge benefit for members as much as just supporting a project.
Granted this is a larger task than just funding one build but it might help to make the entire project more sustainable in the long run. This also requires trying to establish what the funding requirement would be to make the project sustainable on an annual basis without knowing exactly what that work would entail.
Either way as long as contributing does not require a paypal account I am happy to contribute. The project is fantastic and I appreciate all the work everyone puts into it.