debugging a CEF browser instance

Bernard Devlin bdrunrev at gmail.com
Thu Jul 6 07:59:20 EDT 2017


Hi Mark,

I had no doubt that the debug log was disabled because enabling it by
default would be expected to cause some significant slowdown. However,
since this is a configurable option, I would have hoped that (at the very
least) it could be turned on for situations such as the situation in which
I'm in (a page that works in all other browsers I've tried but that doesn't
work in either Livecode 8.1.4 on Windows or OS X - with no visible errors
there is no hint as to why it is not working).  The page is not mine and
therefore it's not like there is only a trivial amount of javascript for me
to test line by line (it was easier for me to discover why LC's CEF browser
doesn't allow debugging than it would be to find out why the web page does
not work).

That the page does not work in LC on BOTH OS X or Windows, suggests that it
is something discrepant with the way the browser widget works in LC (and
not just some limitation in the CEF widget).  The page not working on two
different implementations of the browser widget in LC suggests there may be
a wider set of problems developers will encounter (i.e. there may be many
more cases where LC's browser will not work the way that other browsers
work).  Without debugging information, I don't see how such discrepancies
will ever be fixed.

Hopefully it will be quicker and cleaner to enable logging (at least in the
CEF browser) by setting an environment variable or checking for a command
line parameter.  I believe that the verbosity of CEF's logging can be
configured. That logging level might also be worth setting at startup (in
case the amount of logging is so excessive that the IDE is unresponsive).

That the CEF logging on Linux is flooding the terminal window should also
be fixable.
https://stackoverflow.com/questions/11844208/linux-terminal-that-is-currently-running-and-logging-to-stdout-how-do-you-silen

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.
>



More information about the use-livecode mailing list