Getting `no executable front-end (browser) '/Applications/Google'`

[Dan Kilman]

Running on macOS there seems to be some whitespace handling issue.
I see that server.c does include a reference to the correct path:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome
But I guess somewhere down the line the spaces break things.
I tried setting CHROME_BIN env var, but it doesn't seem like it did anything

[Per Bothner]

I see that the chrome_command function adds extra quotes for the is_WindowsSubsystemForLinux() case. Perhaps we should try something similar:

#if __APPLE__
    // FIXME - better to open -a "Google Chrome" OR open -b com.google.Chrome
#define CHROME_MAC "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
    if (access(CHROME_MAC, X_OK) == 0)
        return "'" CHROME_MAC "'"
#endif

Let me know if this works. If not, I'll boot up my Mac and try myself.

We probably should also add quotes around the result of getenv("CHROME_BIN") - and find_in_path. Some re-design may be needed here ...

[Dan Kilman]

This seems to have worked

diff --git a/lws-term/server.c b/lws-term/server.c
index 415df5a..c9594b6 100644
--- a/lws-term/server.c
+++ b/lws-term/server.c
@@ -497,10 +497,11 @@ chrome_command(bool app_mode)
     if (cbin != NULL)
         return cbin;
 #if __APPLE__
+#define CHROME_EXE "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
     // FIXME - better to open -a "Google Chrome" OR open -b com.google.Chrome
     char *chromeMac = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome";
     if (access(chromeMac, X_OK) == 0)
-        return chromeMac;
+        return "'" CHROME_EXE "'";
 #endif
     cbin = ""; // cache as "not found"
     return NULL;

Another issue that came right after is that it seems that if Chrome is already running, it only brings it to focus.
For DomTerm to load properly, I had to quit chrome altogether.

[Per Bothner]

I made some changes to how /usr/bin/open is used which seems to make things better.

But note issue #83.

[Dan Kilman]

I can confirm that it works as expected now although, there is still the issue of having to close chrome entirely for it to work.
But I guess consider the issue linked here, it's probably best to avoid chrome in the first place as long as this bug exists

[Per Bothner]

A possible (experimental) alternative is using Webview. Add --with-webview to the configure command, and specify --webview when starting up domterm.

I don't think it's quite usable yet - but it doesn't have the problem noted in issue #83. Known annoyances is that it doesn't do menus in the proper Mac way (that may take a while to fix); copy/paste don't work as they should (I'm looking into a solution); the File/Quit menu item doesn't work; the default font causes problems with the mc program (on Mac - on Linux it seems ok).

Let me know if this approach is worth pursuing.

[Dan Kilman]

Considering the many different things that require fixing I think the more pragmatic choice for me would be to simply load DomTerm in Firefox. Perhaps future versions of Chromium will fix this

[Per Bothner]

I checked in a workaround/fix for issue #83. That should make Qt and Electron much more usable.