OSX Feet and Inches Input in Plugin Webdialogs somehow broken?



We recently had a report of an OSX user who was having trouble entering feet & inches input into one of our plugin’s dialogs.

When we investigated further, we discovered that the dialog was sometimes changing the ’ (feet) symbol into a curly apostrophe. Since the feet symbol was being changed, the desired length input could not be parsed by our plugin.

For example, if we would enter 3’ 4 as input (note the space), it would be converted to something like 3(curly apostrophe) 4 which would fail to be properly recognized as valid input.

However, if we would enter 3’4 (no space), it would work fine (no forced character conversion).

This makes it impossible to enter complex fractional input such as 3’4 1/2 since spaces are required prior to the fraction.

My questions are these:

  • Has anyone else noticed this behavior when entering this type of input into a plugin dialog?
  • Is this NEW behavior that might be caused by a recent OSX update? I have a very hard time believing that this behavior has always existed and I am only finding out about it now.

The solution we have found is to open OSX Keyboard Settings and make sure that smart quotes is disabled:

My hunch is that Apple recently pushed an update that caused this setting to be enabled by default. That would explain why I am only discovering this now. For the record, we are currently running OSX 10.11.6 and Safari 11.1.2

@thomthom @DanRathbun


I think just read here yesterday a post where @Anssi mentioned this bug. (But it may have been an old post as I was searching around on the issue of textures scaling inside Dynamic Components.)

EDIT: Oh, I found it and NO it is about a different issue.

@Barry or @slbaumgartner Ever run into this ?


smart quotes has always be a problem in the Dynamic Component Attribute dialog,


Good typography has its place when you do type setting or write articles, but it is unfortunate that apparently macOS enables this by default for any type of text input.

As a user you can disable “smart quotes” in system preferences (only globally?) as Mike’s link says.

But as a developer, you do not have control about your users’ system preferences, and probably every single user encounters your extension as broken and needs support for applying this workaround. Have you tried whether the embedded Safari (or Chromium in newer SketchUp versions) implements the HTML5 autocorrect property and whether this also prevents smart quotes?


That’s news to me.

Have you seen this yourself? Have you had many reports? Or is it limited to that user?

What you could do is to replace the quotes before parsing it. I assume you are using String.to_l?
The question is, is the quote-replacement likely to be different from locale to locale?
Presumably the safest way to handle this is to read system settings for what the replacement characters are, then perform your own substitution. Short of that you could try some sane defaults - if possible

I had a similar issue with some users of my own extensions. Some were having problems activating they license key. After banging my head against the wall for a while I realised the common denominator was Outlook. It replaced the hypen dash - with unicode EN dash. Which are near identical visually - probably only a pixel in difference at “normal” body text size.
In that case it was easier to deal with that. The hypens were just there to make it easier to read the key, but of no value for the key itself. so I stripped away all non-valid characters and reformatted the key before passing on to the rest of the system.


I wonder… do VCB input for native SketchUp tool also have problems with this?


Also - do you know if this happen in UI::WebDialog or UI::HtmlDialog? Or both? This could be a browser behaviour. (In which case I’d be surprised if behaviour changed in UI::HtmlDialog all of a sudden. Though maybe it picks up system settings.)
UI::WebDialog uses the system browser engine - so I’d not be the least surprised that behaviour might change suddenly.


I think so. Not a Mac user myself but I’m quite sure I’ve seen it posted hereb on the forum.

Would be great if the SU core length parsing could be patched to treat curly braces as normal braces, to fix the issue once and for all, both in VCB and plugins.


The default might have changed a few versions ago, I’m not certain. But OS X 10.11.6 is two versions back and hasn’t seen any updates in quite a while (current is 10.13.6 and 10.14, aka macOS Mojave is in beta). I don’t think that explains your not noticing the issue before now.

Edit: unlike Windows, macOS does not slip minor updates into a version without changing the minor version number. If 10.11 was updated since yours, there would be a 10.11.7. So far as I know there is no such.


If smart quotes are on, yes the native tools also fail to parse certain inputs correctly.


Made me look as I couldn’t remember. Turns out it is on. It’s not causing problems with the VCB. I’ll have to check plugins.

I’m on 10.11.6 too.


I haven’t tested HtmlDialog on OSX yet, only WebDialog.

As I said, when changing the system setting, it fixed the problem. I just can’t understand why we never would have noticed this issue until now unless something changed recently either in the system browser engine or with an OSX update.

We’ve only had one report of this so far and when we tested, we were shocked that we were able to duplicate the issue without changing any settings on our Mac. As you know, I have developed and tested on Mac for over 10 years and have never seen this issue until now.

My theory is that one of two things happened:

  • The system browser recently started using the smart quotes setting for some reason
  • The system browser always used the smart-quotes setting but, for some reason, my smart-quotes setting became enabled only recently

Either of these potential causes could have been triggered by an OSX update in my opinion, but I have no proof.


I just checked my own mac mini, running 10.11.6. And it was also checked. I’ve also never toggled this system setting. (Wasn’t even aware of it)

But no idea if its the system setting default having been changed, or the browser engine…


How does the VCB for extensions and native tools behave?


Doesn’t appear to affect the VCB. Nor Ruby Console Input. So I looks like this is an opt in behaviour by the browser engine.

I have always worked in Windows, and in Metric - which is why I’ve never seen it. I also don’t have any extensions that take webdialog input as units. I’m guessing the combo of Mac+Imperial Units+WebDialog input is so rare that few users have ran into it.