debugging a CEF browser instance

[Bernard Devlin]

Hi Mark,

I've now found an app which has embedded the CEF browser within it.  This
embedded CEF browser has no trouble loading the page in question.

This makes it very clear that the problem relates to the way that LC is
embedding the CEF browser. This is also confirmed by the fact the page will
not load in LC browser widget on OS X.  Is there any way of debugging the
browser that is embedded in OS X? If not I'll have to put this project on
hold without any way to debug any browser instance.

Regards
Bernard

On Thu, Jul 6, 2017 at 8:28 AM, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> On 2017-07-06 08:39, Jonathan Lynch via use-livecode wrote:
>
>> Why?
>>
>
> In general there is a cost to logging - particularly CEF's which is very
> verbose. On Windows you might not notice (as stdout/stderr output is
> generally dumped to the equivalent of /dev/null), but on Linux if you
> happen to be working from the command-line and running UI stuff using the
> browser widget from there then you'll find your terminal flooded with CEF
> logging (and I mean flooded!).
>
> I don't think anyone has asked specifically about having it configurable
> before now - although I noticed it would be useful last month (
> http://quality.livecode.com/show_bug.cgi?id=19862) whilst attempting to
> figure out why the browser widget only works on *some* linux installs
> (seems to be somewhat independent of distribution - the workarounds some
> people have found with regards the locale don't seem to work anymore).
>
> Unfortunately, we aren't any closer to solving the linux problem... After
> at least three of us spending more hours than I'd care to comment on trying
> to figure out what is happening there, we're working through a couple of
> tasks so that we can more easily update CEF to the latest version.
>
> In particular, making it so that we can build our 'prebuilts' (currently
> ICU, OpenSSL and Curl) on vulcan (doing it manually is arduous and
> intensely error prone). We can then move the building of the CEF library
> component to a prebuilt and automate its generation based on a version tag
> (we can thank Spotify for taking over the management of binary releases of
> CEF - http://opensource.spotify.com/cefbuilds/index.html - as they've
> made it much much easier).
>
> So we're currently involved in a (small) yak-shave in this regard...
> Although one which will also mean we can solve a couple of other issues -
> the size of ICU data (has anyone noticed that the 9 engines are somewhat
> bigger than 8? That's down in good part to the ICU data), and also the
> several minute increase per platform in build time due to the Skia update.
> I also hope that this means that over time we can eliminate the thirdparty
> submodule entirely - which would be one less point of friction in our
> source base.
>
> Incidentally, Bernard and Jonathon - I take it you are using the browser
> widget on Windows? (The reason I ask that is because CEF is only used on
> Windows and Linux - Mac/Android and iOS all use the built-in browser - all
> three are WebKit derived, like CEF).
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>