Webkit in 64bits adds 100MB

I’m using HtmlViewer in a Windows 64 bits application and regarding that I’m having some issues using Native renderer I tried WebKit, but I noticed it is adding more than 100MB to the application files (libcef.dll is 69MB).

After creating a compressed installer (InnoSetup) it means more than 40MB to the setup file.

Is there any lighter alternative for Windows?

While using native renderer I’m getting different issues and don’t want to make registry changes and similar; WebKit is working fine. I will only use HtmlViewer for OAuth2.0

Thanks.

You could use native rendered as alternative.

Thanks but as mentioned above Native renderer is not working.

I have now send it with WebKit for beta testing and a Windows 7 user told me he is getting an error:

cefsubproc.exe stopped working

No other message or error. Any help will be appreciated.

That’s the subprocess to render.
If it crashes, maybe Chromium has a bug.

Yes, regarding what I have been able to read in some CEF forums this seems a bug and probably solved at newer CEF versions, is there any way to embed a recent version in Xojo?

you can fill a feature request in Feedback app.

No, there is no wat. You’re stuck with the version that Xojo devs glued with Xojo.

Alternatively you could create a web app. Those could run in any browser you like.

Not a solution in this case. The HTML Viewer is used for authenticating via oAuth, and is not the whole app.

webkit is about 12 mb larger in 64 bit than under 32 bit
and its about 97 mb in 32 bit
about 107 in 64 bit

Personally I wouldn’t use an in built browser for OAUTH logins. I would call ShowURL to let the users default browser open at the address for login. This allows the user to utilise their in browser login method, be it keychain, browser based password manager, separate password manager or keyboard which isn’t the case when using an in built browser. There is also more trust from the user if they are using their own browser and not your embedded in your app. It might not look as nice, but your users will like it more. But that is just my opinion when I see this happen “out in the wild” :slight_smile:

Julian, this sounds good.

Can you guide me on how to retrieve the token from users browser ?

You create a listener in your app, e.g. on port 30000 (so not to clash with anything, put some detection in this so it automatically moves to the next free port just in case). You then tell the OAUTH service to OK your credentials and supply 127.0.0.1:30000 as the callback url. When the OAUTH is complete their browser will redirect to 127.0.0.1:30000 and your application will answer the request. In that request, they will send the token on the URL which you now have. You can then output a nice “Thank you, please close this window” html on your 127.0.0.1:30000 response or redirect it to yoursite.com/complete to improve the user experience with a nice thank you page.

Julian,

thanks so much, it seems a great solution.

Will work on this, may be I’ll come back for more help if you don’t mind :wink:

I have it working now with a Tcpsocket and opening user’s browser but, as usual, operating system (Mac) requests each time user permission for my application to accept incoming calls.

I understand this is how it should be but I fear that users may find this more intrusive than showing the login option in an application window (htmlviewer). Don’t ask users for disabling firewall :wink:

Regarding that login is only needed one time (until user revokes the authorization or a problem) what option would you prefer?

Not having a long mac background I don’t know. At a guess, you can probably add a firewall rule for your app during install so it doesn’t pop up. You might want to ask about this in a new topic on the mac section as the question might not be found here in the windows area.

You could also social engineer it in a way to alleviate user concern. Only open the socket when you have shown a message that is telling the user that you are about to link their account and you will need access to make this happen. Then call your Socket.Listen and up comes the message for the user to OK. When the socket is listening (you can check for this) then make the call to ShowURL.

[quote=362142:@Alejandro Fresno Meyer]Thanks but as mentioned above Native renderer is not working.
[/quote]

Not working how? The IE 11 engine is not perfect, but pretty good. What browser engine are you using?

You have to set some registry keys to get the IE11 engine: http://blog.xojo.com/2016/01/04/use-newer-version-of-internet-explorer-with-webbrowser-and-htmlviewer/

If you don’t, it defaults to IE7 which is terrible.

Me neither, considering Google’s oAuth doesn’t allow it anymore (since april 20 2017)
See:

If you have @Christian Schmitz plugins, you could use CURL to call the oAuth. I’ve done that before in a desktop app.

[quote=362322:@Michael Diehr]Not working how? The IE 11 engine is not perfect, but pretty good. What browser engine are you using?

You have to set some registry keys to get the IE11 engine: http://blog.xojo.com/2016/01/04/use-newer-version-of-internet-explorer-with-webbrowser-and-htmlviewer/

If you don’t, it defaults to IE7 which is terrible.[/quote]
I don’t like changing users registry, and without it doesn’t works correctly in Windows 10 64bits HiDpi, raises a NilObjectException which I couldn’t debug, once a bypass is created it displays content very small; in Windows 7 it doesn’t shows correct page.

And regarding Google’s notification it seems I have to go the browser way.

Thanks for all your help.

It’s good to not mess with system-level registry keys, I agree, but this one is a minor change (in HKCU) and the change only applies to your one app. So it’s not much different than saving your application preferences using the registry, which is pretty much standard procedure on windows.