The new 19.3 update brings some significant enhancements but also includes a few breaking changes in the FileMaker 19.3 web viewers on Windows clients.
For example, DayBack Classic will not work in 19.3 on Windows until you make a couple of changes to the file (instructions follow). Folks using web viewer apps like this will want to update those files before moving to FileMaker 19.3. Other apps like ProMaps and FMChat will see only minor changes and some, like the new DayBack for FileMaker 19, are largely unaffected.
Here’s a great summary of all the cool features in FileMaker 19.3.1: what’s new in the latest release or check out the detailed release notes.
In this article:
- Breaking changes in FileMaker 19.3 web viewers (these only affect Windows clients)
- How these changes affect…
- DayBack for FileMaker 19
- DayBack Classic
- ProMaps
- FMChat
Breaking Changes: FileMaker 19.3 Web Viewers on Windows
FileMaker 19.3 web viewers now use the Microsoft Edge (Chromium) engine instead of the Internet Explorer engine to render web content on Windows clients. (That’s why these changes don’t affect Mac clients or folks who only have a Windows Server.) This is an excellent change overall and a big improvement over Internet Explorer.
However, it comes with a few behavior changes that can break some web viewer apps. Here are the breaking changes we’ve been able to identify so far:
- All fmp:// calls on Windows now show a dialog asking for permission to allow the site to open FileMaker Pro.
- When using a data-URL based web viewer, the permission dialog will appear every time the web viewer loads. Permission is for “localfm.assets.”
- When referencing external files in the web viewer, the permission dialog is accompanied by an option to “always allow.” If referencing local files, permission is for “file://.” Otherwise, it will be for the URL referenced.
- If you’re running into this in your own files, you can tweak the registry to grant access without a prompt.
- Web viewers in Windows clear all settings associated with the site when their FileMaker file closes. This includes local storage, cookies, and selections to “always allow” the site to open FileMaker (described above). Even if FileMaker is still running, it won’t retain those saved settings once the file is closed. It appears these settings are scoped to the file’s session.
The upshot of these two changes is that your users may be asked to OK each time a web viewer wants to run a FileMaker script. In some cases, users may not even see the dialog asking for permission, and it may appear that the web viewer has hung up. And apps that use local storage or cookies to store the user’s state or tokens connecting to APIs, won’t be able to retain those facts after the FileMaker file is closed.
- New browser security rules in Windows prevent an fmp:// URL from being called when not initiated from a user action like a “click.” There seems to be an exception for this when the web viewer’s layout loads. The result of this behavior is fmp:// URLs don’t need to be executed from a click action if the web viewer is being set when rendering the layout. It’s not exactly clear what “rendering the layout” consists of, as URLs can execute when setting the web viewer from a script trigger or the web viewer content being loaded directly in the object itself.
This means that while web viewers can still run FileMaker scripts using fmp:// URLs when they are associated with links and buttons, web viewers can no longer run FileMaker scripts in most JavaScript callbacks. DayBack Classic uses callbacks to limit the number of times the whole web viewer needs to refresh–helping keep users focussed without “unscrolling” them, and making DayBack Classic feel more like a native part of FileMaker.