I can’t pinpoint yet what the common denominator is for these cases but I believe all from non-English speaking countries. I’ve yet to get a report from USA, CAN, or UK.
I will update this thread when I receive more information from the customers who made the reports. I was just wondering if any other developers have seen this issue?
Have you guys come across this issue? It only seems to occur when using SU2020.
Thanks John but I’m not trying to debate the merits of HtmlDialogs over WebDialogs.
The point is that I am seeing JS in WebDialogs fail in SU2020 where they work fine in SU2019. Both SketchUp versions should be using the same version of Internet Explorer to display the dialogs, would they not? @thomthom what could be causing this?
OK, I want to give an update on this issue as some new information has come to light.
What we have found is that issue was only occurring for our plugins that use jquery 2.1.4 (our other plugins use an older version and did not have any issues)
In versions of SketchUp prior to 2020, the SU installer would set Windows registry values that would modify Internet Explorer compatibility for WebDialogs to be some specific version of IE. This is no longer being done by the SU2020 installer.@thomthom Was this intentionally removed or is this a bug in the installer?
We did not realize that our plugin was relying on these registry values to be set. It turns out that for some SU2020 users (we don’t know why it only affected some), even though they had IE11 installed on their computer, when using local WebDialogs, the IE version that was detected was only 7 or 8. Perhaps some other software had configured this compatibility mode for local html files, I don’t know.
Or perhaps, the user installed multiple SU versions in an unusual order (starting with SU2020 and then ending in SU2015) which may have resulted an old IE compatibility version being set in the registry.
We seem to have fixed this issue by applying a meta tag to all of our local html dialogs as noted below. Developers should also be aware that there seems to be different configurations and registry settings related to local html files, intranet files, and internet files. In other words, if you have a local WebDialog that is designed based on a certain version of IE don’t assume that a WebDialog that loads from a remote server will use the same version of IE as the local one.
The tag below seems to have fixed this issue for us. <meta http-equiv="X-UA-Compatible" content="IE=edge" /> <!-- Tells Page to load with newest version of IE -->
I hope this info can help other developers as well. These sort of issues are hard to pin down.
Yup. We’ve discussed this here in this category for many years as the IE browser emulation registry setting was incrementally changed from 9 on up (SU2015 and later.) At one release it had to be increased to IEv10 because the Google Maps API wouldn’t support anything earlier.
Many of us especially ThomThom have been preaching for years not to rely upon the default setting, but to instead always include a <!DOCTYPE html> tag …
The HTML5 document type directive tells a webbrowser to display webpages in standards mode. … If your webpage uses one or more features that require standards mode and you do not include a standards-compliant !DOCTYPE directive, the resulting behavior depends on the version of Internet Explorer used to view the webpage.
… along with the meta tag …
That was back in 2016. Again, in later SketchUp releases it had to be set to emulate MSIE 10 minimum so that the Add Location would work. But likely SketchUp 2018 set the IE emulation up to 11 (0x2AF8), as that is what mine is set as.
And also ThomThom explained why SketchUp 2017 was still using UI::WebDialog for the embedded web services (EW, 3DW, Generate Report and Add Location) …
I did publish a set of reg files to set the emulation for testing or if it really becomes necessary (ie, such as after having to rerun an older installer to repair an older version SketchUp.)
Also for years the UI::Webdialog section, of the IDEAS page, of the pinned Ruby Learning Resources, has promoted ThomThom’s “Lost Manual” as well as the MSDN pages on HTML document compatibility.
Yea, it’s a good chance this isn’t set by the new installers. As Dan mentions, the registry setting set by previous SU versions set it per executable name, so newer versions would affect older SU versions.
This would not be considered a bug since it’s never been part of the API contract and is part of an deprecated feature. Using a <meta> is the most reliable method to control the IE rendering mode for a given UI::WebDialog instance.