Problem with WebDialog and Javascript

I think you can see everything you’d need here:

view-source: (paste into Chrome to see page source)

As you know TIG I’m not much of a developer so most of that is greek to me! :slight_smile:

That page’s code is immense.
Perhaps @thomthom can drill into it and see some weirdness…

I think around line 46ish is the javascript bit for my payment portal… I have a feeling that’s the issue (it’s gopaywall)

Hmm I thought it could be an issue with using http instead of https. It might be that http will in the future be blocked.

But you also showed that worked. So that makes me wonder if its your server doing some kind of redirection.

I would inspect the http traffic from your machine and see what requests and responses are being sent. On Windows I would recommend Fiddle, but not sure what one can use on mac.

I don’t have Catalina myself. Holding back because I keep hearing about so many issues.

Maybe @nickgully can help? We should have some Catalina machines in the office.

You might have to inspect your server config. But at first, check the HTTP traffic.

I’m not sure, since I don’t have Catalina, but maybe webkit under Catalina tries to force redirect to HTTPS. If your server tehn redirects HTTPS to HTTP you got yourself a loop. This would be done at server config, not HTML/JS.

There is a redirection that happens I believe by Javascript if you’re not logged in.

I remember Fiddler, I found this:

Once I get my Catalina VM up I’ll give that a shot.

the problem with WebDialog on any mac is it uses ‘WebCore’ which is a feature deprived ‘base’ of the running Safari version…

Apple often moves functionality between WebCore and Safari and never releases the details…

even in an older osX version…
If I open your dialog in SU and ‘Inspect Element’ I do get this error…

TypeError: null is not an object (evaluating 'document.getElementById('ifrm').contentWindow')

if I open in a HtmlDialog

dlg ={"Show"}
dlg.set_url ""

I get no errors…


If I understand what you’re saying:

The webdialog method uses Safari (or some stripped down version of it) because that’s the standard, non-removable browser that comes with MacOs (if I was using HTML dialog I’d be using Chromium right?)

What I’m not clear on here is what the error you’re showing means… Maybe you can bring it down to a 5th grade level so I can understand? :slight_smile:


Almost, CEF used by SU is a stripped down version of Chromium…

It’s failing to create the iFrame needed for gopaywall and possibly due to it using a Safari ‘workaround’ that something else broke…

I think the issue is with SquareSpace and you would need them to chase it down…

or switch to HtmlDialog as that eliminates any Safari workarounds…


Yeah, that “safari workaround.php” is a little suspicious… I think I now know who to bug… There’s not a way to view the contents of that PHP file is there?

That looks like it should work.

(Just realized Fiddler for mac and linux is now available:

Post back what you observer and I’ll see if I can provide any assistance.

Ok, so the folks that I use for the payment portal have fixed the issue from their side. I’m still waiting for them on exactly what they did, but they did fix it. I feel like the issue was in their javascript that I have to run to make the paywall work…

But if it happened only on Catalina… I wonder if WebKit acts differently under that version. Which threw the script off?


Google recently [October] lost a High Court class action in the UK and can now be sued for their ‘safari-workaround’ which can be used to steal user data…

in the lower courts, the infringement was ‘upheld’, but the rights to class action denied on technical grounds, and Google were let off the hook…

I suspect they have now either withdrawn or revised it [ for the European market, at least ] and all third party usage is affected by those changes…


I run Catalina all the time on my own machine (Mojave on my work machine). Several in QA have external Catalina drives, or other ways to test Catalina issues.

I wonder though if the issue is to do with SketchUp 2019.3. If you do the same tests and only change to 2019.1, does it work?

A significant change in 2019.3 is that signing in opens your default web browser, and you manually return to SketchUp. SketchUp does pick up on the fact that you’re now signed in, but I wonder if a webview would also detect that.

With SU2019.3 and the macOS signing compliance we have to explicitly allow HTTP connections as Apple’s default really wanted to block them. But I don’t know how older SU versions would behave under Catalina… SU2019.3 was in large part a Cataline release.

If this isn’t a problem with HtmlDialogs i would recommend switching to it. Using old deprecated stuff is messy. Also i think very, very few people still use 2016.

I wonder if there’s any data out there that shows the popular releases of SketchUp. I have a guess that there are a lot of older copies still in active use out there…

I think 2017 is still going strong given how it was the last free version for non-commercial use but I don’t bother much about anything older than that. I don’t take any statistics from my own extensions but based on the info I’ve gotten from other people it’s not a problem.

Same here - as I’m making new extensions or updating I’m quickly dropping support for anything older than SU2017.