Likelyhood of new storage handler code for CEF acceptance?

[mitchc]

I love CEF and CefSharp and use them for various personal projects. With the new chrome runtime and styling some new features are certainly possible.

The ability to use extensions to a greater degree I thought was interesting and I was thinking of trying to add a storage API handler. The main idea being able to hook the extension storage.local / storage.sync api calls from CEF to override Chromes default handling of plugin storage data. Think a resource handler but for storage.

Assuming I succeed in adding such hooks for my own needs I do generally like to contribute back where I can. I haven't worked with CEF from a contributing developer POV and I don't know what is or is not normally accepted, I have seen some PR that are around for years as well so it may be that CEF can be hesitant to take up new features (which makes sense given the scope of the surface area of the project already and of course the lack of enough developer resources around most open source). This might also be too niche to be worthwhile for CEF to consider.

Given my inexperience with CEF contributing it would probably take me double the time to get the code into a potentially acceptable PR form, which I don't mind doing, but if it is unlikely such a thing would be accepted I would rather just have my own private patches that I apply to CEF / CefSharp to accomplish my needs without trying to introduce a whole new handler that is up to cef standards.

There are not a whole lot of contributing guidelines that I found. There is https://bitbucket.org/chromiumembedded/ ... ingWithGit which covers mostly git and proper generic basics I found some old forum posts as well but nothing overly detailed.

I could hack together some solution using injected JS on every page and dev tools but properly being able to hook the API would seem far better.

As to why, I often on many request contexts and separate cache paths in one instance but may have extensions that should just behave the same across everything. Even separate applications I might want to share essentially extension settings without having to constantly duplicate things. Of course the obvious solution is probably to be 'signed in' and use the existing sync protocol but from a privacy POV being signed into a browser that is then syncing data is not quite up my alley.

[magreenblatt]

It’s hard to say whether such a change would be accepted without fully understanding the use case and scope of code changes involved. Generally speaking, something utilizing existing Chromium APIs is more likely to accepted than something requiring Chromium changes. If you plan to implement it for yourself in any case, you might start with that (a prototype) and then revisit this thread to share your findings and conclusions.

If you’re simply seeking a “Google sync” replacement you might consider existing projects like https://www.xbrowsersync.org/ which run as Chrome extensions.