debugging a CEF browser instance

[Bernard Devlin via use-livecode]

After a very long time away from Livecode, I'm trying to get back into it.

On 8.1.4 in the Windows IDE I have a browser instance where a standalone
web page with some Javascript code is not working.  The same page works if
I load it into Chrome.

So, I thought there might be a way to display the console of the browser
instance, but I can't find a "chrome://..." command to do that. The most
information I can get back from the browser instance is this:

"C:/Program Files (x86)/RunRev/LiveCode Business 8.1.4/LiveCode Business"
--browser-subprocess-path="C:\Program Files (x86)\RunRev\LiveCode Business
8.1.4\Externals\CEF\libbrowser-cefprocess.exe" --no-sandbox --lang=en-US
--log-file="C:\Program Files (x86)\RunRev\LiveCode Business
8.1.4\debug.log" --log-severity=disable --locales-dir-path="C:\Program
Files (x86)\RunRev\LiveCode Business 8.1.4\Externals\CEF\locales"

So, I created a .cmd file where I launched the livecode .exe, passing in
different values for

--log-severity=disable

but no alternative parameters in the .cmd file appear to be taken up (i.e.
it looks like these CEF browser parameters might be hard-coded into the LC
exe).

I'm thinking there must be a way to debug CEF browser instances, but a
search through the mail list didn't turn up anything that appeared relevant.

Any suggestions?

Regards
Bernard
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Bernard Devlin via use-livecode]

I tried with 9.0 dp7.

Still no luck. The webpage opens and works with both Chrome and Firefox.
But not with the browser widget in either LC 8 or LC 9.  I even tried with
LC8.1.4 on OS X and it fails there too.

I'm surprised no-one else has run into the need to access the debug log,
browser console or browser developer tools.

Regards
Bernard

On Tue, Jul 4, 2017 at 11:33 AM, Bernard Devlin  wrote:

> After a very long time away from Livecode, I'm trying to get back into it.
>
> On 8.1.4 in the Windows IDE I have a browser instance where a standalone
> web page with some Javascript code is not working.  The same page works if
> I load it into Chrome.
>
> So, I thought there might be a way to display the console of the browser
> instance, but I can't find a "chrome://..." command to do that. The most
> information I can get back from the browser instance is this:
>
> "C:/Program Files (x86)/RunRev/LiveCode Business 8.1.4/LiveCode Business"
> --browser-subprocess-path="C:\Program Files (x86)\RunRev\LiveCode
> Business 8.1.4\Externals\CEF\libbrowser-cefprocess.exe" --no-sandbox
> --lang=en-US --log-file="C:\Program Files (x86)\RunRev\LiveCode Business
> 8.1.4\debug.log" --log-severity=disable --locales-dir-path="C:\Program
> Files (x86)\RunRev\LiveCode Business 8.1.4\Externals\CEF\locales"
>
> So, I created a .cmd file where I launched the livecode .exe, passing in
> different values for
>
> --log-severity=disable
>
> but no alternative parameters in the .cmd file appear to be taken up (i.e.
> it looks like these CEF browser parameters might be hard-coded into the LC
> exe).
>
> I'm thinking there must be a way to debug CEF browser instances, but a
> search through the mail list didn't turn up anything that appeared relevant.
>
> Any suggestions?
>
> Regards
> Bernard
>
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Jonathan Lynch via use-livecode]

Hi Bernard,

I work with JS in the browser widget quite a bit.

I have just gotten used to testing JS commands very carefully, step by step, 
because it does not really provide any debugging information.

It would be nice to have that.

Sent from my iPhone

> On Jul 5, 2017, at 7:34 AM, Bernard Devlin via use-livecode 
>  wrote:
> 
> I tried with 9.0 dp7.
> 
> Still no luck. The webpage opens and works with both Chrome and Firefox.
> But not with the browser widget in either LC 8 or LC 9.  I even tried with
> LC8.1.4 on OS X and it fails there too.
> 
> I'm surprised no-one else has run into the need to access the debug log,
> browser console or browser developer tools.
> 
> Regards
> Bernard
> 
>> On Tue, Jul 4, 2017 at 11:33 AM, Bernard Devlin  wrote:
>> 
>> After a very long time away from Livecode, I'm trying to get back into it.
>> 
>> On 8.1.4 in the Windows IDE I have a browser instance where a standalone
>> web page with some Javascript code is not working.  The same page works if
>> I load it into Chrome.
>> 
>> So, I thought there might be a way to display the console of the browser
>> instance, but I can't find a "chrome://..." command to do that. The most
>> information I can get back from the browser instance is this:
>> 
>> "C:/Program Files (x86)/RunRev/LiveCode Business 8.1.4/LiveCode Business"
>> --browser-subprocess-path="C:\Program Files (x86)\RunRev\LiveCode
>> Business 8.1.4\Externals\CEF\libbrowser-cefprocess.exe" --no-sandbox
>> --lang=en-US --log-file="C:\Program Files (x86)\RunRev\LiveCode Business
>> 8.1.4\debug.log" --log-severity=disable --locales-dir-path="C:\Program
>> Files (x86)\RunRev\LiveCode Business 8.1.4\Externals\CEF\locales"
>> 
>> So, I created a .cmd file where I launched the livecode .exe, passing in
>> different values for
>> 
>> --log-severity=disable
>> 
>> but no alternative parameters in the .cmd file appear to be taken up (i.e.
>> it looks like these CEF browser parameters might be hard-coded into the LC
>> exe).
>> 
>> I'm thinking there must be a way to debug CEF browser instances, but a
>> search through the mail list didn't turn up anything that appeared relevant.
>> 
>> Any suggestions?
>> 
>> Regards
>> Bernard
>> 
>> 
>> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Bernard Devlin via use-livecode]

Thanks Jonathan for confirming that there is no debug mechanism for the
browser widget.

But what my examples shows is that one cannot rely on the browser widget to
present a working web page, even one that works in multiple standard
browsers (including Chrome).  This is not a web page of my construction,
but is one that is in use by other people.  So it's not that it's my
javascript that is failing, and therefore I can't carefully test each line
of javascript without taking their website apart and building it back up to
find the error.

LC needs to have some way of allowing at least the developer to see why a
page is not working within the widget.  The debuglog option of the CEF
browser widget shows
a) that the debuglog is being written to a system folder (and therefore
unlikely to be writeable)
b) that the browser widget has logging disabled anyway
c) that these options are hard-coded into the LC startup process

Anyone got suggestions about how this should be put forward as an
enhancement request/bug report?  It seems that a CEF executable ought to be
launchable with a supplied remote-debugging port. But that also does not
work with the libbrowser-cefprocess.exe which comes with Livecode.
http://magpcss.org/ceforum/viewtopic.php?f=6&t=11952#p22106

Regards
Bernard



On Wed, Jul 5, 2017 at 12:40 PM, Jonathan Lynch via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Bernard,
>
> I work with JS in the browser widget quite a bit.
>
> I have just gotten used to testing JS commands very carefully, step by
> step, because it does not really provide any debugging information.
>
> It would be nice to have that.
>
> Sent from my iPhone
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Bernard Devlin via use-livecode]

Replying to myself, for anyone else who thinks it ought to be possible to
debug a browser widget.

Ability to debug has been deliberately turned off.
https://github.com/livecode/livecode/commit/ccfab94499425b6245f98b3328ebd043876f9be7
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Jonathan Lynch via use-livecode]

Why?

Sent from my iPhone

> On Jul 6, 2017, at 1:45 AM, Bernard Devlin via use-livecode 
>  wrote:
> 
> Replying to myself, for anyone else who thinks it ought to be possible to
> debug a browser widget.
> 
> Ability to debug has been deliberately turned off.
> https://github.com/livecode/livecode/commit/ccfab94499425b6245f98b3328ebd043876f9be7
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Mark Waddingham via use-livecode]

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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Jonathan Lynch via use-livecode]

I am just using CEF on windows, in the browser widget. I have zero knowledge of 
Linux and so I am a bit hesitant to attempt that. My app leans heavily on the 
browser widget, so I guess Linux is not yet an option.

Is Linux a big market for casual users?

Anyway, I just think it would be nice to see which JS errors we are producing. 
Shrugs - I have done okay with just testing line-by-line as I go.

Sent from my iPhone

> On Jul 6, 2017, at 3:28 AM, Mark Waddingham via use-livecode 
>  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 ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Bernard Devlin via use-livecode]

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@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.
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[hh via use-livecode]

Hi all,

a few remarks, may be marginal.

Some of the problems with the CEF browsers arise from the fact that
the "same origin policy" changed. Some of the latest versions of the
main browsers make the access easier.

Also, when using webGL, this differs between browsers and the browser
widget in that a graphics card counts as "black-listed" (sometimes the
user agent is checked for that).

For the browser widget to work in linux (more) correctly see
http://forums.livecode.com/viewtopic.php?p=153351#p153351

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Bernard Devlin via use-livecode]

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@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 ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Mark Waddingham via use-livecode]

Hi Bernard,

On 2017-07-07 14:02, Bernard Devlin via use-livecode wrote:

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.


Mac does not use CEF - it uses the system WebView (which is Safari).

The fact it doesn't work in either Mac's WebView of CEF may suggest that 
the webpage
is doing something which is 'not allowed' by default - they are both 
WebKit based
browsers, so it makes sense that if that is the case it would not work 
in either.


What is the webpage which is not working? If you file a bug report with 
the details
we can look into it - that might be slightly quicker than getting 
debugging/logging

configurable in (at least) the CEF browser.

Warmest Regards,

Mark

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Bernard Devlin via use-livecode]

Hi Mark,

I suspect this is the problem. Is there a list of things which the LC
embedded browser forbids? Is there an explanation of the rationale for the
embedded browser to behave differently from a default browser?

This should be noted in the Dictionary, perhaps in the top entry
of: com.livecode.widget.browser.  Those who try Livecode for the first time
and discover that the browser widget "doesn't work reliably" (which is how
it appeared to me) may simply give up on Livecode.  Indeed, it might be
better if a warning appears when a page attempts to do something that has
been restricted (assuming the browser widget throws an exception when such
things happen).

Regards
Bernard

On Fri, Jul 7, 2017 at 1:25 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> The fact it doesn't work in either Mac's WebView of CEF may suggest that
> the webpage
> is doing something which is 'not allowed' by default
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Mark Waddingham via use-livecode]

Hi Bernard,

There's no list, no. The widget is a reasonably thin wrapper around either CEF 
or (on Mac, iOS and Android) the system provided WebView.

Without actually seeing cases to investigate which do not work as expected it 
is hard to advise what the problem might be (although 'cross origin requests' 
is one possibility).

Certainly as we discover such issues documenting them in the dictionary would 
be useful.

As mentioned before if you could file a bug report so we can look into it, that 
would be most helpful.

Warmest Regards,

Mark.

Sent from my iPhone

> On 8 Jul 2017, at 09:59, Bernard Devlin via use-livecode 
>  wrote:
> 
> Hi Mark,
> 
> I suspect this is the problem. Is there a list of things which the LC
> embedded browser forbids? Is there an explanation of the rationale for the
> embedded browser to behave differently from a default browser?
> 
> This should be noted in the Dictionary, perhaps in the top entry
> of: com.livecode.widget.browser.  Those who try Livecode for the first time
> and discover that the browser widget "doesn't work reliably" (which is how
> it appeared to me) may simply give up on Livecode.  Indeed, it might be
> better if a warning appears when a page attempts to do something that has
> been restricted (assuming the browser widget throws an exception when such
> things happen).
> 
> Regards
> Bernard
> 
> On Fri, Jul 7, 2017 at 1:25 PM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> 
>> 
>> The fact it doesn't work in either Mac's WebView of CEF may suggest that
>> the webpage
>> is doing something which is 'not allowed' by default
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: debugging a CEF browser instance

[Matthias Rebbe via use-livecode]

Bernard,

in case you are filing a bug report could you please post the bug id here?
I would like to add a comment with some websites urls i have problems with when 
using the widget /CEF browser.


Regards,
Matthias

Matthias Rebbe
+49 5741 31
‌matthiasrebbe.eu ‌

> Am 08.07.2017 um 14:59 schrieb Mark Waddingham via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> Hi Bernard,
> 
> There's no list, no. The widget is a reasonably thin wrapper around either 
> CEF or (on Mac, iOS and Android) the system provided WebView.
> 
> Without actually seeing cases to investigate which do not work as expected it 
> is hard to advise what the problem might be (although 'cross origin requests' 
> is one possibility).
> 
> Certainly as we discover such issues documenting them in the dictionary would 
> be useful.
> 
> As mentioned before if you could file a bug report so we can look into it, 
> that would be most helpful.
> 
> Warmest Regards,
> 
> Mark.
> 
> Sent from my iPhone
> 
>> On 8 Jul 2017, at 09:59, Bernard Devlin via use-livecode 
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>> Hi Mark,
>> 
>> I suspect this is the problem. Is there a list of things which the LC
>> embedded browser forbids? Is there an explanation of the rationale for the
>> embedded browser to behave differently from a default browser?
>> 
>> This should be noted in the Dictionary, perhaps in the top entry
>> of: com.livecode.widget.browser.  Those who try Livecode for the first time
>> and discover that the browser widget "doesn't work reliably" (which is how
>> it appeared to me) may simply give up on Livecode.  Indeed, it might be
>> better if a warning appears when a page attempts to do something that has
>> been restricted (assuming the browser widget throws an exception when such
>> things happen).
>> 
>> Regards
>> Bernard
>> 
>> On Fri, Jul 7, 2017 at 1:25 PM, Mark Waddingham via use-livecode <
>> use-livecode@lists.runrev.com > wrote:
>> 
>>> 
>>> 
>>> The fact it doesn't work in either Mac's WebView of CEF may suggest that
>>> the webpage
>>> is doing something which is 'not allowed' by default
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com 
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com 
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode