SU 2017 Install Breaks WebDialog in SU 2016?

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.

CORRECT.

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:

[1] Controlling WebBrowser Control Compatibility | Microsoft Learn

[2] Internet Feature Controls (B..C) (Internet Explorer) | Microsoft Learn

You must have a <!DOCTYPE html> tag as the first line of the document, in order for the <meta> compatibility tag to work.

Add, that, then try different versions beginning with 7 and go up from there.

If you never see the layout return to normal, it may also be that your dialog was always rendering in quirks mode.

Hi Jim, as I can see Dan has already provided detailed explanations about the reason, which causes problems with web-dialogs in previous SU versions after installation of SU2017. I also can confirm that specifying of some “legacy document mode” in an HTML part of a web-dialog was suggested by some SU team engineers as “a recommended (safe) practice” for extension developers recently (in order to ensure rendering mode regardless of SU updates). Alternatively it is possible to edit HTML part to make it work in IE11 (may take more effort than adding of meta tag obviously).
I also have to mention that WebDialog class became deprecated since SU2017 according to new API documentation and it is recommended to use HtmlDialog class now instead. HtmlDialog class uses Chromium instead of IE (Safari) to display dialogs so it is another way to make sure that dialogs appearance will be independent from IE updates.

@super_girl I believe the following tag should make web-dialogs work in SU2016 the same way as they used to before SU2017 installation: <meta http-equiv=“X-UA-Compatible” content=“IE=10”/>

In order to be clear I have to mention that recommendation to use HtmlDialog is relevant for SU2017 only obviously. So you may decide to switch from WebDialog to HtmlDialog while making an extension compatible with SU2017.
There is also another minor change introduced in SU2017, which extension developer should be aware of. In SU2017 a flag for the embedded web control is turned on to be “high-dpi aware”. This change affects old web-dialogs in SU2017 on win when overall zoom scaling specified in screen resolution settings differs from 100%.

@DanRathbun - thanks for commenting and confirming my suspicion. I do have a DOCTYPE tag. I’ll keep playing with meta tags until I figure it all out. It’s possible it’s rendering in quirks mode. It’s tough to trouble shoot as the base html file is just a skeleton, and then all the content is filled in depending on what the user is doing.

@jim_foltz - also thanks for confirming. Do you know of any way to change the registry back and forth between the SU 2016 and SU 2017 version? I’d like to be able to trouble-shoot this and still be able to return to a working version in SU 2016 without having to uninstall and reinstall (and re-do all my preferences each time).

@kirill200777 - I’ll try that meta tag, and I’m looking forward to a bunch of the updates in SU 2017, and sounds like the chromium browser will be good as well. Updating the plugin to run with SU 2017 will take some time though. There are some random things in my code that don’t work in SU 2017 already. For example, object_ids now have so many digits that I can’t store them in an attribute dictionary the same way I did before. I’ll have to go through and replace object_ids with persistent_ids - which will be better overall, but takes time to make sure that it all works and nothing gets broken.

I’ll update when I find a solution.

As I said above, it was set to 9 when SU2015 was released (and not changed for SU2016.)

This wasn’t so recent. As I said, the emulation has changed several times in the past.

So this question and discussions like it occurs every time the emulation setting gets changed in major SketchUp release.

Thomas Thomassen’s WebDialogs: The Lost Manual has had a page on this subject for years.

Yes, but according to my personal observations 10 works fine as well.

Well maybe I should write something like “suggested … again recently” instead of just “suggested … recently” to be more accurate. I just haven’t seen such recommendations before that’s why it appeared as a recent event for me personally. Anyway as for me personally I think that suggestion itself (to force some old rendering mode) is controversial as such. In my opinion it may serve only as a temporary workaround (only to make things work while figuring out how to fix html, css, js part to make it compatible with a latest rendering mode).

That’s right. Looks like the latest commit to the “Collection of unofficial documentation of SketchUp’s WebDialog class” was made 4 years ago (not sure if Thomas had been already a member of SU team at that point).
[UPD] I overlooked that “Doctype Quirks vs Standard vs Superstandard” page was revised in 2014. Anyway the whole manual is still “unofficial” and what is more important mentioned page describes quite opposite situation: as far as I understand it tells how to force more recent document mode (IE8 at that point) instead of default IE7 for SU at that point. And what is even more important referenced page explains why SU forced old document mode at that point (because quote: “some plugins might rely on the IE7 mode”). Current situation (after installation of SU2017) is opposite to referenced technical paper.

I got it working. There were two things that helped:

  1. I removed the “inline” tags from css styles - for some reason this was completely messing up my tables

  2. I used the following tags:

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

specifying anything higher than IE=8 creates a problem where I could not assign an id to any element created using wd.execute_script(script)

So, for transition to SU2017, I’ll look into the html dialog class. Hope my experience and solution can help someone avoid some headaches. Thanks again for all the help.

Edit: When I posted the above, I didn’t realize that there were still some problems. Everything LOOKED right, but it still wasn’t functioning correctly. My onChange() events were not triggering, so anything input into the webdialog forms was not being saved. Fixing this took some serious sleuthing. To summarize, I had to remove any instance in which I modified an HTML element with javascript after creation. So now I’m pretty sure everything is working again.

1 Like

It is necessary if for example, your plugin will be running on an old SketchUp that is running on a Windows XP machine, which can only support MSIE 8 max.

(moved to end of thread)

@DanRathbun - thanks for your super informative reply. It’ll help me figure out what I need to do further in updating to SU2017.