SU2020 WebDialogs Javascript Problems

We’ve got at least 4 strange reports lately from people using SU2020. It seems that javascript might be somehow becoming disabled in WebDialogs in SU2020 for some users causing our plugins to break. These same users claim that our plugins work fine in SU2019. We have been unable to reproduce the issue ourselves.

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.

mac or windows?

webDialogs use IE or Safari…

Safari has certainly stopped for some of my apps

john

Verify please … UI::WebDIalog instances or UI::HtmlDialog instances ?

UI::WebDialog on Windows. I don’t have any confirmed reports yet from Mac users

Check if they still have IE final release on their machines…

john

to a large extent mac versions of webDialogs convert to htmlDialogs reasonably easily…

both webkit based with only a few gotcha’s…

my main gripe is the lack of any usable dlg.write_image equivalent…

john

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?

I’ve experienced one user who had a broken IE installation that prevented JavaScript to run. The user had to reinstall IE (or repair Windows.)

It could also be that the user has turned off JavaScript in IE settings. (Or IT admins via group policy.)

In that case, wouldn’t ALL versions of SketchUp break? In the case I am describing, only SU2020 seems to break

Hmm… yea. I missed that detail, sorry.
I don’t know what would cause such difference. We didn’t do anything explicitly to the webdialog interface.

If you have a repro case we can look into it.

If it’s specific to non-English countries it could be an issue with dot vs comma as decimal separator. That wouldn’t explain the difference between 2019 and 2020 though.

I don’t see how that would affect JavaScript executing or not…

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)

So it wasn’t javascript that wasn’t working, it was jquery 2.1.4. This version of jquery is only compatible with IE9 or newer.

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.

2 Likes

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 …

MSDN: How to Enable Standards Support

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.

2 Likes

along with a <!DOCTYPE html> tag.

:wink:

1 Like

Yes - indeed, you want a standard doctype rendering and not the nasty quirks mode.