SU 2017 Install Breaks WebDialog in SU 2016?



Has anyone else encountered this problem? I installed SU 2017 and it broke webdialogs in a custom plugin (in-house only) running in SU2016. To fix the problem, I had to uninstall SU2017 and SU2016 and then re-install SU2016.

When I say “broke” - the webdialogs were not loading properly, and even elements that were loading properly were not getting all of the appropriate attributes they were supposed to get (like “name” or “id”) so my action callbacks did not work as they relied on these attributes.

DC Callback function error

You’ll need to update their extensions from the Extension Warehouse. There is no need to uninstall SU2017 to make the web dialogs work in earlier versions.


This is an extension that I wrote myself. After I installed SU2017, the webdialogs stopped working in the extension in SU2016.

Edit - this extension has been working (with continued improvements since… I don’t remember the first version of SU it worked on, but pre 2013.


sorry for the mis-understanding. With SketchUp 2017, the webdialogs were changed to use Chromium instead of Ie or Safari. This was spelled out in the release notes. I expect you’ll need to edit the extension to fix that.


yes, I will need to fix a bunch of things for SU2017, but installing SU2017 broke my extension in SU2016. Usually I continue working with the previous version of Sketchup until I have my extension working properly in the new version. But installing 2017 caused some change in the webdialogs in 2016, and I won’t be able to have both versions of sketchup installed on the same computer without chasing bugs in 2016 (which has otherwise been working great all year).


This is very strange! Each version of SketchUp installs separately from the others, which is why you can have multiple versions installed and running at the same time. So far as I know, they don’t share code. It seems like the only way one version could affect another is if they ill-advisedly share some registry setting (e.g. it is known that the last-run version may usurp the “open with” setting for .skp files). I hope Trimble will take a close look to make sure they didn’t somehow glitch something that SU 2016 needs.

Unless, of course, the overlap is through your extension (e.g. by saving settings in some shared space of your own)…


Thanks @slbaumgartner! Do you know if the official SU people watch this forum, or is there some other way to report this bug? I’m dying to get my hands on some of the other SU 2017 improvements (persistent ids and observer improvements).

I don’t have any shared settings, so pretty sure this is something coming from the SU 2017 install. I actually had to uninstall and reinstall SU 2016 before things started working again, so there must be a shared repository that (thankfully) got deleted with the SU2016 uninstall.


Yes, the Trimble staff watch this forum pretty closely. Your topic title and categories should get their attention. However, right now having just worked feverishly to release the new version they are likely taking a breather and may be slower than usual to respond.


@slbaumgartner - thanks


If I were to hazard a guess I’d say the HTML in your dialog is not well formed or is incorrect. are you using a proper DOCTYPE tag? Are you using meta tags to select the rendering version of I.E. to the latest? For example: <meta http-equiv="X-UA-Compatible" content="IE=Edge" />

I’m no expert in the area, it’s just a guess as I said.


Jim, why would that cause installing 2017 to affect the behavior of 2016? Perhaps 2017 sets an IE flag in the registry that changes the handling of the html?


Yes for some reason I am thinking 2017 is updating some setting which webdialogs use to determine which rendering or compatibility mode to use. I can’t find the source at the moment. @kirill200777?


I reinstalled SU2017 in order to test some things…

@jim_foltz - changing my meta tag to:

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

makes the dialog sort of work, but not really. The table that I was using to display things got all messed up, but functionality is sort of back.


That would support Jim’s theory that SU 2017 is setting an IE flag in the registry differently than SU 2016, affecting what html compatibility is supported by default. With all the versions of IE in the wild, figuring out the right meta to make a page work across all of them can be enough to drive you to drink!


@slbaumgartner - yep, trying to figure out how to replace my tables with<div> right now. Painful.


Try the combination in this post:


@jim_foltz - that makes it look and act differently, but problem still not solved.

I think that some variation on the meta tag might help me… For now, I have to get back to work on other things. I’ll update if I find a solution and I really appreciate all the helpful comments here. Please post any more suggestions you may have!


In a WebDialog John McClenahan and I recently worked on, we found the following meta got us to portability across at least several versions of SU and IE

<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">

I see those are among the ones Jim also recommended.



I have spoken about this repeatedly here in the forums (and elsewhere in private,) for several years.

On the PC (under MS Windows,) the SketchUp installer (or any application installer for that matter,) can set a FEATURE_BROWSER_EMULATION version attribute in the registry for a particular executable name.

The SketchUp installer has thrice (that I know of) set this attribute globally for “sketchup.exe”. (If the executable names were differenced for each version, say “sketchup17.exe” then we wouldn’t have this nor the “competing double-click problem.”)

Most recently the SketchUp 2017 installer has upped the version number to 0x2AF8 (11000), which is the setting for IE 11.

  • They did this because most 3rd party web services were all dropping support for older IE versions, and providing features that only work with the latest HTML5 capable browsers.

With the SketchUp 2015 release, that no longer supported XP (which was limited to MSIE 8 maximum,) the browser emulation version was raised to 0x270F (9999) which was for MSIE 9.

  • Recently, Google Maps began displaying a version warning for MSIE below version 10,… that users needed to update their browsers. SketchUp users began seeing this in the native Add Location feature dialog.

Prior to SketchUp 2015 the version was likely set at MSIE 8, 0x22B8 (8888).

The emulation setting may also have been changed sometime in the SketchUp 7 cycle as that major version dropped support for Windows 2000 (which I think initially may have come with MSIE 6. Can’t remember exactly.) But the Feature Control attributes were not always available that far back, (in terms of IE versions.) I think they may have been added for IE8.


Thanks for confirming (again) Dan. I just finished uninstalling and re-installing versions 2016 and 2017 in order to take a registry snap-shot after each and found that same registry key which is responsible for setting the default compatibility of Web Browser Controls i.e WebDialogs.

SketchUp 16 it is:

Windows Internet Explorer 9. Webpages are displayed in IE9 Standards mode, regardless of the declared !DOCTYPE directive. Failing to declare a !DOCTYPE directive causes the page to load in Quirks.

In 2017:

E11. Webpages containing standards-based !DOCTYPE directives are displayed in IE11 edge mode. Default value for IE11.

I’m not sure if this is @super_girl’s problem, but I had a suspicion.

Here are a couple Microsoft links on the topic: