12 May

Why does my iPad display constantly freeze when using Sidecar with my MacBook Pro?

I’m still asking this question and not finding any answers.

Someone said to disable Touch ID on the iPad. That didn’t help.

Someone said to be sure you’re using a USB connection, not a wireless connection. That didn’t help either.

Here’s my current theory, which I am still testing, and I’ll update this if I get anywhere closer to confirming it.

I think it may be because I was supplementing my WiFi Internet connection with a wired Ethernet connection, via an Ethernet-to-USB-C adapter. Most of the time when I’m sitting at my desk — which is also almost the only time I’m ever using Sidecar — I have the Ethernet plugged in. I have “gigabit” (in theory) fiber Internet, so the wired connection makes the difference between averaging about 150 Mbps over WiFi alone vs. about 600 Mbps over WiFi + Ethernet.

I’m not exactly sure how the Mac handles having both WiFi and Ethernet connected simultaneously… I’m from the old school where you had one or the other. But it seems to work. However, I think it may also be contributing to Sidecar crapping out randomly and often (usually it won’t work for more than about 5-10 minutes before the iPad screen freezes).

So far in about a half hour of testing deliberately having the Ethernet unplugged and paying attention to it, Sidecar has managed not to stop working, but it’s too soon yet to know for sure if this is the fix.

I’d rather keep my fast Ethernet connection, of course, but my WiFi connection is plenty fast for everything besides massive file transfers, which I don’t really do that often. So if this is the tradeoff I need to make in order to keep Sidecar working, I’ll do it.

Update (June 7, 2022): Nope, this seems to be a moving target. The solution I outlined above worked for a while, but now, still running the latest OS updates (macOS 12.4 and iPadOS 15.5 respectively), I am still once again seeing Sidecar freeze every 5-10 minutes, even though I am doing everything I can possibly think of to fix the issue: the devices are connected over USB, I have Touch ID disabled, auto-lock is set to “never,” my Mac is unplugged from Ethernet. None of it matters… Sidecar just keeps freezing. I don’t understand why Apple can’t seem to fix (or even acknowledge) this problem.

TinyMCE and the relative URLs SNAFU

My CMS, cms34, uses a few third-party tools for certain complex features. One of the most useful is TinyMCE, a JavaScript/DOM-based drop-in WYSIWYG text editor. If that doesn’t mean anything to you, you probably want to stop here, but in case you’re a glutton for punishment, it is, in short, a way to produce HTML-formatted text with a word processor-like interface. Think Microsoft Word in a web browser, with the results being formatted for display on a web page. Slick.

Anyway, there’s been one nagging problem: When users paste in URLs for links, TinyMCE converts any on-site links into “relative URLs” — it strips out the domain name. This is not necessarily bad; in fact, for the most part I would want it to do that. But for some reason the nature of my CakePHP-based CMS seems to confound TinyMCE’s ability to properly determine the relative URL. And what’s worse, the CMS includes an enewsletter editor which has to have absolute URLs, but TinyMCE was converting them to relative URLs even if the user pasted in an absolute URL.

A little research led me to a handy explanation in the TinyMCE Wiki. Basically, if you want your URLs to always be absolute, make sure your TinyMCE configuration includes the following:

relative_urls : false,
remove_script_host : false,
document_base_url : “http://www.site.com/path1/”

Of course, you’ll want to change the value of document_base_url to be the actual base URL of your website. As it happens, my CMS has a global JavaScript file that creates a variable called baseUrl that I can use anywhere in JavaScript to substitute for the full base URL of the website. So, in my case, I set the value for document_base_url equal to baseUrl.

And, voilà, it seems to work!