chromiumembedded
Make default popup styling configurable for views and native parent
Is your feature request related to a problem? Please describe.
- Run
cefclient --use-native --use-default-popup - Select Tests > Popup Window
- Get a fully styled Chrome window
Change step 1 to --use-views --use-default-popup and you instead get a minimally styled window.
It would be nice if default popup styling behavior was configurable independently of views vs native parent.
Related forum thread: https://magpcss.org/ceforum/viewtopic.php?f=6&t=20295&p=57516
It would be nice if default popup styling behavior was configurable independently of views vs native parent.
@magreenblatt , do you have any feel for how would you characterize the changes required for this, on a scale of trivial to incredibly involved? I'm trying to plan our upcoming releases and if this is not terrible I'd entertain taking a swing at it. That way I could keep our native window and chrome style with no decorations since my other choices are either going back to alloy style or rewriting our (moderately involved) native window code in views.
It would be nice if default popup styling behavior was configurable independently of views vs native parent.
@magreenblatt , do you have any feel for how would you characterize the changes required for this, on a scale of trivial to incredibly involved? I'm trying to plan our upcoming releases and if this is not terrible I'd entertain taking a swing at it. That way I could keep our native window and chrome style with no decorations since my other choices are either going back to alloy style or rewriting our (moderately involved) native window code in views.
Sorry to badger: any input on this, @magreenblatt ?
@bjdupuis Sorry for the delay in responding. You would need to modify the logic in ShouldCreateViewsHostedPopup to return true. Note that this may trigger problematic assumptions elsewhere in the code as well. I'm also not sure what the best way to configure this would be, as OnBeforePopup already has too many parameters. Maybe it's time to convert those parameters to a struct.
I'm also not sure what the best way to configure this would be
I guess we could start by configuring it globally (in CefSettings) instead of per-browser.
I've added a parameter in the CefSettings and have added logic in ShouldCreateViewsHostedPopup() as discussed. It seems to work as desired when I swap back to Chrome style in our native window-using app and have the popup created as a "default" popup from OnBeforePopup() returning false: I get a working popup with no decorations that has a window.opener when appropriate (which, for my purposes, is when an alloy-style popup would have a window.opener).
Are there any regression tests that could validate that there aren't "problematic assumptions" that result from this that I haven't accounted for?
Further, given the change to CefSettings I get to play in the new API versioning stuff. What's the best practice for code that, I assume, won't be accepted back into the mainline for a while to generate my own "official" distributions for our consumption? Do I use the #if CEF_API_ADDED(CEF_EXPERIMENTAL) on the code and set the -D api_version=999999 environmental variable on the build machine?
I've added a parameter in the CefSettings and have added logic in ShouldCreateViewsHostedPopup() as discussed.
Please share your changes as a PR.
Do I use the #if CEF_API_ADDED(CEF_EXPERIMENTAL) on the code and set the -D api_version=999999 environmental variable on the build machine?
You can use #if CEF_API_ADDED(CEF_NEXT) in the PR. CEF_EXPERIMENTAL is the default value when you don't explicitly configure an API version on the client side.
Okay. I haven't submitted a PR back to CEF proper. Do we target master?
RE: CEF_NEXT... the API versioning doc says the following:
Any API changes in pull requests should follow the Implementation guidelines laid out below and use the CEF_EXPERIMENTAL placeholder value in C/C++ header files.
API changes may become Stable (be assigned a version) if explicitly approved by the CEF admin. API approved for Stable can use the CEF_NEXT placeholder value instead of CEF_EXPERIMENTAL in pull requests. This value will be converted to a specific/new CEF API version by the CEF admin prior to upstream merge (see example here).
Does this just mean that you (as a CEF admin) are (conditionally) approving this API change for stable?
Do we target master?
Yes.
Does this just mean that you (as a CEF admin) are (conditionally) approving this API change for stable?
Correct (stable here means some future version, after the PR merge).