I observe very often, that a legacy version of a container would be loaded since a long time period. Due to this, I see wrong data structures in my analytics account. Are there any possibilities to push the newest version?
Related
I'm considering moving a project from cef (CefSharp) to WebView2 WPF. My preliminary tests shows that WebView2 API have the interface I need for this port. I am afraid that I can miss something that can prevent me from switching to WebView2 and I'll figure this out at later stage of this transition. If anyone went through this process, please share if I need to be aware of something that can be a roadblock for this transition. Are there important APIs from cef that are missing in WebView2?
This issue in WebView2's Github answers your question in part. And I would like to add my take.
A summary:
WebView2 doesn't have an API for simulating user input, it's unsuitable for automation.
WebView2 can't render offscreen. No running in the console, as a service, on a server.
WebView2 runs in a separate process; CefSharp runs in the application's process.
WebView2 has a sandbox; CefSharp doesn't.
This answer is based on my personal experience and is not an exhaustive comparison.
Process Model
The Chromium process model has the main process and many auxiliary processes. It is, of course, a bald simplification, but it will do.
Both CefSharp and WebView2 follow this process model with one very significant difference. CefSharp starts Chromium in the application's process, and WebView2 starts it as a separate process.
The in-process model is common to all CEF-based browsers. Pros: the browser starts faster. Cons:
If CEF crashes, it takes the application down with it.
If there's a vulnerability in CEF or Chromium, it can also expose the application's memory.
The out-of-process model is popular among proprietary browsers. Not only WebView2 works this way, but also DotNetBrowser and EO.WebBrowser. Pros:
It's safer.
It doesn't bite off the application's RAM.
Cons:
It starts longer.
It may be slower because of inter-process communication.
Occasionally, there are issues with the focus and drag-and-drop because the browser window belongs to another process. Not applicable for the offscreen rendering, though.
CefSharp process model. WebView2 process model.
A score for WebView2.
Offscreen Rendering
There are two approaches to the rendering of embedded web content. One is to shake off the bells and whistles from an actual Chromium window and embed it into the application. We call this "windowed" or "heavyweight" mode. Another approach is to render web content in memory and draw it on an arbitrary surface. It's called "offscreen rendering."
WebView2 supports only windowed rendering. This mode has two significant drawbacks: it requires a window to function, and the browser always stays on top (aka the airspace issue).
CefSharp also has offscreen rendering. It allows the application to run in the console, overlay web content with other controls, render web content in Unity3D, etc.
A score for CefSharp.
Automation
The bread and butter of automation is simulating user input. CefSharp has an API for dispatching "real" mouse and keyboard events to the browser. The browser handles these events as user gestures, and JavaScript can't tell between them and real human input. Look at the SendMouse* and SendKey* methods in IBrowserHost.
There's no such API in WebView2, only workarounds based on Win API.
A score for CefSharp.
Sandbox
By default, all Chromium processes are sandboxed. It makes them more secure. The Chromium team explains the sandbox in great detail here.
WebView2 and other out-of-process libraries are sandboxed as well.
CefSharp doesn't support sandboxing and, it seems, never will (#697).
A score for WebView2.
See also
CefSharp supports only primary AppDomain.
CefSharp doesn't support commercial codes by default.
In addition to the other answer I'll add some additional points
License
CefSharp is open source, 3-BSD licensed. You can customise the code, fix bugs, submit pull requests, etc.
WebView2 is not currently open source. You need to wait for Microsoft to fix bugs. Currently WebView2 team releases updates every four weeks. Even if a bug is fixed quickly you can be waiting weeks before it's released.
Privacy
WebView2: Data collection privacy notice (at time of writing)
The software may collect information about you and your end users’ use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. There are also some features in the software that may enable you to collect data from users of your applications. If you use these features to enable data collection in your applications, you must comply with applicable law, including providing appropriate notices to users of your applications. You can learn more about data collection and use in the help documentation and the privacy statement at https://aka.ms/privacy. Your use of the software operates as your consent to these practices.
Microsoft has yet to disclose exactly what is captured. Users must opt-out of data collection.
A number of users have raised concerns regarding the data telemetry. There are a number of discussions regarding the privacy concerns here and here.
Distribution Model
Both CefSharp and WebView2 require a specialised version of Chromium to be installed/copied on your computer.
Fixed Version: A fixed version of Chromium is bundled with your application. You control which version.
Evergreen: Chromium is is installed then automatically updated via windows update. On some OS's it will be pre-installed. Currently limited/no control over if the runtime is updated.
CefSharp
WebView2
Fixed
[x]
[x]
Evergreen
[x]
Chromium is rapidly changing, there's a new major version every four weeks at time of writing. Each major release adds/removes features. Security policies are changed.
What worked flawlessly on a previous version of Chromium may no longer be allowed for security reasons. Deprecated features are frequently removed.
For complex applications it's important/imperative to tested against the specific version of Chromium your application uses. This applies to all Chromium based browser.
Evergreen WebView2 Runtime automatically updated via Windows Update sounds perfect? Get the latest version without having to do everything.
What happens when a bug makes it into a Stable Release? Did you test your application against the dev/beta channels to flag upcoming issues? No? You could be inundated with user complaints their application now crashes.
A quick look though the WebView2Feedback Issue Tracker and you can see examples of this happening.
M108 release was particularly problematic with many users reporting issues.
The following are just some examples
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3029
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3068
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3062
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3032
For those using an Evergreen model you must test your application on every dev/beta release to ensure your application works as expected.
WPF
CefSharp provides two WPF implementations, the first CefSharp.Wpf renders every frame to a bitmap, this allows for a native WPF experience. You can apply transforms, layer elements over the top, etc. There are no airspace issues. There are a few downsides the main being performance is lower (there are a few things you can do to squeeze some extra frames).
The second is CefSharp.Wpf.HwndHost, it's a HwndHost based implementation, it's like embedding the WinForms version in WPF with binding support, you get much better performance, no transforms, cannot layer over the top. Airspace issues apply.
WebView2 currently only provides a HwndHost implementation, airspace issues apply. There is talk of providing a more native WPF implementation
Every time I launch Qt MaintenanceTool to update or change components it takes minutes to fetch metadata, and may stuck from time to time depending on network and need to start again. What it is, and why does it take so long to fetch, and is there any way to skip this process because I may have run it just a few minutes ago?
I also use visual studio and the update process is easier and can always pick up where I left, is there any workaround for Qt? Thanks!
It is slow because it injects thousands of HTTP GET requests to download small metadata files (package information), thus chances for stuck. while it may be noticed with Windows installer due to large number of package repositories considering different versions of MinGW, Android ...etc. its less sever on Mac or Linux, there are ongoing discussions and lists following the issue, chained down this bug report Retrieving meta information from remote repository is too slow and happens too often it was suggested to improve performance but I am not aware that Qt took the suggested improvement (use a single HTTP/1.1 connection, or only a few of them, with Keep-Alive enabled, to do all the metadata GET requests, instead of opening a fresh socket for each GET) in this recent discussion Development To improve UX of the online installer.
Is there any way to load retired version (3.28 or 3.29) of Google maps APIs (free/paid options) ?
My Qt4 application uses QWebKit to load web content. Which is atleast few years old. Newest APIs versions are causing problems in my application. Since the last few days I am not able to load any API version older than 3.30.
If I specify 3.29 google gives me 3.31 or latest stable if I don't specify any version.
Even if I fix my current issues with latest versions, future updates in Maps API will cause more issues. I want to make sure I can load a specific version that will work with my application all the time.
Please reply, if you are aware of any methods.
Am I correct in observing that Corda 1.0 is using Kotlin plugin 1.1.4? Just out of interest I tried to use 1.1.51 and ran into defaultWhiteList loading issues...although I'm not entirely sure why tbh...suspect classpath loading issues on the ServiceLoader.load in DefaultKryonCustomizer?? Anyway, when I revert to 1.1.1 (am still on M13) all is well again.
Just wanted to gain some understanding around why an inadvertent upgrade of the Kotlin plugin to 1.1.51 would cause issues with the serialisation default whitelist loading?
Thanks
A somewhat non-answer, but I'll try anyway: As we see the kotlin language mature and as Corda uses quite a wide feature set of what's available in kotlin, it doesn't surprise me that sometimes the frequently published newer versions of Kotlin don't work with older versions of Corda - especially if they make some internal changes to objects then I'm not surprised we see kryo serialisation issues. We publish the recommended / supported version of kotlin in the constants.properties file which, for release 1, is as you've correctly pointed out, 1.1.4 (which can be confirmed here: https://github.com/corda/corda/blob/e564edaa572a011869d692b05518113632363216/constants.properties ).
It does look as if we have updated this for the forthcoming v2 release to 1.1.50 if that helps. It may be a little late in the day to bump this to 1.1.51 though (a fair amount of testing and QA has already been performed).
A few years back I have been using Titanium Desktop to make an app for Mac. Having been satisfied I came back recently to it for another project, but apparently Titanium Desktop is now TideSDK.
Looking at the reference it seems that a lot of stuff has disappeared, I was mostly expecting more elements in UI, like ScrollView, ImageView and such.
Did they simply vanish from this new release or is it just not fully documented ?
First of all I need to make clear that TideSDK is not Titanium Desktop. While it began on legacy code, more than 1 million lines changes of code have been committed and the SDK has been in existence for almost a year now. You will find a different namespace but API compatibility.
The code base is quite different and has been undergoing major restructuring and improvements. That said, for the end user, it is just as friendly to use. We don't like to go back to discuss the past since we have contributed a body of code that allows developers to run TideSDK on today's modern operating systems. This was only the result of substantial efforts and the continued development of TideSDK by its contributors. If you experience any issues, please file them with on our issue tracker on github.