LiveCode Builder is a language for extending LiveCode's capabilities, creating new object types as Widgets, and libraries that access lower-level APIs in OSes, applications, and DLLs.
So I brought this up before, and I brought it up with the plug-in developer (who said it's not his bug). When I load this plug-in via JavaScript in a Browser Widget in LC9dp11 it works as long as I run LC in 32bit mode, if I try to load it in 64bit mode it crashes the WebKitPluginHost.app that resides inside the WebKitLegacy.framework that is inside the WebKit.framework. I can't find the info but my guess is this WebKitLegacy.framework is for legacy as in 32bit? I also see references to Carbon (aka OLD) things in the crashlog. Could it be that the WebKit view generated by the BrowserWidget is linking to some 32 bit stuffs in a FrameWork and then trying to load 64 bit stuff too and ...bam..it gets all out of whack?
I'm having similar problems as this guy here: http://forums.livecode.com/viewtopic.php?f=9&t=19299
I have JavaScripts that work when loaded from local directory in any of the 3 big browsers (completely from disk/no internet) but when I load them in a browser widget they break, even if I merge (browserfiy) all linked scripts into one html.
Maybe there's a problem somewhere in the code for MCBrowserFactoryGet or related? Preferences set a certain way when creating the WKWebView?
Last edited by PaulDaMacMan on Sun Feb 11, 2018 5:13 am, edited 3 times in total.
Probably the bottom line is this: I shouldn't be relying on a WebPlug-In for anything, since Web Plug-ins seem to be in a perpetual state of being in various stages of being "phased out", smh. and many uses are moving to HTML5.
Still, I'm thinking I might be trying out building a helper app that passes the JavaScripts to a WebKit WebScriptObject and seeing if it behaves and loads the 64-bit plugin without crashing there (versus LC BrowserWidget). I'm in the processes of trying to learn AppleScriptObjC (I know, late to the party...and it seems the AppleScript party is being abandonned by it's host) / Cocoa-Scripting in an effort to understand Objective-C and general OOP better so I can wrap it in LiveCode builder and forget most of it later.
Basically, what I'm really kind of after is using LC as a front end for JavaScript libraries, which works great in a lot of circumstances. But if you're on macOS the web view that the Browser Widget creates is (now) WebKit (versus older Mac versions that used Chrome CEF, or CEF on Linux/Win), the result is not having to bundle a huge CEF Framework in your standalone mac.app, it would be nice to be able to choose which framework to use, embedding the 80mb+ CEF framework or just use the 0mb framework that shipped with the OS (Safari/WebKit), and/or be able to take advantage of the the flags while initiating it, to enabling certain features like access to local files. What I'm thinking is LiveCode could act as a kind of GUI kit for the $h1tT...er... thousands of Node.js modules that are out there.
I reverted this one test back to LiveCode 7.1.4 and used revBrowserOpenCEF (the Chrome Framework that is no longer available in newer Mac builds of LC) and IT WORKS! I suspect that other Node.js-like things might work this way as well. It would be really nice to have a choice of Web Engines (WebKit or CEF). In most situations the WebKit view is perfectly adequate and I wouldn't want to embed the 75mb CEF Framework into a standalone if I didn't have to, but for this kind of "server side" JavaScript fiddling it seems it can make all the difference in wether something works or not.
BTW, the Atom code/text editor I've been using for LCB, was built with ChromeCEF, Node.js modules, and the Electron JS runtime. It sure would be nice to leverage all of those Node.js modules with a great UI front end / script like LiveCode!
Just to attempt a clarification, and in case someone comes to this thread looking for info on actually using Node.js from LiveCode (which is perfectly doable via shell() or open process, then piping in commands to stdin), what I'm talking about here is slightly different. What I'm getting at is using JavaScripts designed to run in a runtime like Node.js (or similar "server-side" JS runtime, like ElectronJS) but using LiveCode's BrowserWidget (on a Mac that currently means a WKWebview based on Apple's Safari) as the runtime engine, without the need to for a Node installation on the machine running the app.