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: 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.


Issues in DayBack for FileMaker 19

Since most of the breaking changes involve fmp:// URLs, DayBack for FileMaker 19 is largely unaffected. We rewrote the calendar to take advantage of FileMaker 19’s new JavaScript functions, including FileMaker.PerformScript, instead of relying on fmp:// URLs. However, since 19.3 web viewers on Windows don’t retain local storage or cookies beyond the current session, DayBack users will notice two changes. Fortunately, both are easily remedied.

Users will be asked to log into DayBack each time

The issue: Since web viewers in 19.3 flush cookies and storage when the file is closed, DayBack’s “remember me” option no longer works when you sign into the file.

The fix: DayBack has long had a way for you to sign your users in automatically, so they’ll never be asked to log into DayBack after logging into your file. You’ll find step-by-step instructions for setting this up in your file here: Signing Users In Automatically.

DayBack won’t remember your calendar state between sessions

The issue: DayBack Calendar remembers how you left it: what day you were on and which view you were using. It can no longer do that in 19.3 on Windows.

The fix: Fortunately, we’ve been working on this issue for a while and will have an update coming out next week (the week of June 28th) to address this. You won’t need to take any action to take advantage of this update.

FileMaker 19.3 Web Viewers

Learn more about DayBack for FileMaker 19

 


Issues in DayBack Classic

Since DayBack Classic uses the fmp:// URL method to call FileMaker scripts, the changes in 19.3 break the app completely. Fortunately, you can modify your DayBack file to work in 19.3.

Events won’t load

The issue. FileMaker 19.3 web viewers on windows will now ask the user to OK calls to perform FileMaker scripts once per session. But the dialog FileMaker tries to show disappears immediately in DayBack, so the calendar draws but can not fetch and render events.

The fix: There are three ways to remedy this…

1. You can modify your file to work in 19.3 and you’ll find step-by-step instructions here. The team at SeedCode worked very hard to come up with a simple fix that doesn’t take very long to implement. Jason Young’s update file includes the scripts you’ll need to copy and paste into your file.

2. You can upgrade to DayBack for FileMaker 19, which doesn’t have these issues (and had lots of new features). Pricing, upgrade instructions, and discounts are here: upgrade to the New DayBack Calendar.

3. You could revert to FileMaker 19.2.2 on any Windows machines that have updated. You’ll do this by uninstalling FileMaker 19.3 via Control Panel/Programs and then reinstalling 19.2.2 from the installer here.

DayBack won’t remember your calendar state between sessions

The issue: DayBack Calendar usually remembers how you left it: what day you were on and which view you were using. It can no longer do that in 19.3 on Windows.

The fix: We have no fix for this in DayBack Classic, but you can script the calendar to always go to a specific date or view on startup: scripting calendar navigation.

 


Issues in ProMaps

Users will be asked to OK running FileMaker scripts

The issue: Whenever you click on a link or do a constrain search, you’ll be presented with a request to authorize ProMaps to run FileMaker scripts. Selecting the “Always allow” checkbox, then clicking the Open button will authorize this during the current FileMaker session. Closing and re-opening the file again will require authorization again.

The fix: No action required. (Note that you can prevent FileMaker from asking for permission by modifying the registry on your Windows machine as described here.)

 FileMaker web viewer 19.3

 


Issues in FMChat

Users will be asked to OK running FileMaker scripts

The issue: Normally, this authorization works fine, but when clicking on an “entity link,” FMChat will hang without the fix below.

The fix: In the “FMChat Integration Example”, open the “NewChatFromEntity…” script and replace the Value of the Set Variable step on line 40 with: If ( IsEmpty ( Get (HostIPAddress) ) ; “$” ; Get (HostIPAddress)) & “/” & Get (FileName)

(Note that you can prevent FileMaker from asking for permission by modifying the registry on your Windows machine as described here.)

 


 

That’s what we know so far. If you have questions about moving from DayBack Classic to the new DayBack for FileMaker 19, please get in touch. We’re here to help.

 

Tagged with →  

6 Responses to FileMaker 19.3 Web Viewers on Windows

  1. Phil says:

    Where about’s on the local machine is “localfm.assets” stored?
    I used to use the temp HTML file in “C:\Users\username\AppData\Local\Temp\S11” that were created by FM to help when I was debugging code I’d written for a WebViewer.

    • KC Embrey says:

      Hi Phil.
      “localfm.assets” is just the origin URL that FileMaker has these FMP URL requests come from when using a data URL straight in the web viewer.

      One of the big new features with using the WebView2 backend now is that you can open up the Edge debugging tools right in FileMaker! You’ll just need to make sure you enable the advanced tools in FileMaker. Then you can just right-click on the web viewer and choose “Inspect” to open the full debugging tools.

      Here are the instructions from Claris on enabling advanced tools: https://help.claris.com/en/pro-help/content/using-advanced.html

      • Phil Hagen says:

        Can anything in the debugging tools be used to allow local files? Or will they just always be denied until FileMaker fixes this? If not is there any way to tell FileMaker to allow the use of local files in the Web Viewer, now that it uses the Edge engine? I know how to run a local webserver but it is an extra step I don’t need. Plus the file and its dependencies are less portable when it requires a web server. Thanks

        • KC Embrey says:

          Hi Phil, I think we’ve got a solution for you so that you won’t be prompted to allow FMP URL calls to be made from a web viewer in FileMaker 19.3. It’s a small change that needs to be made to each machine, but I’ve created a little registry patch that can make it easier. Details on this can be found in the docs here: https://www.seedcode.com/stop-the-fmp-url-prompts-in-filemaker-19-3-for-windows/

          This could also be applied to an entire organization through Active Directory, if that’s applicable.

          I hope that helps!

          • Phil Hagen says:

            Hi, thanks for the effort. However, my file is in a local directory. My address starts with file:/// and this does not work. I have tried to add the “file:///” to the JSON structure of the registry key and it does nothing. Thanks

          • Austin Keller says:

            @Phil Hagen does the registry key need to be {“allowed_origins”:[“*”],”protocol”:”file”} instead of “fmp” because you are using file:// instead of fmp://

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share →
DOWNLOAD
DayBack Calendar
DayBack's 30-day trial is unlocked so you can customize it and integrate it with your files.
Download DayBack and we'll send you a couple short emails with tips on how to modify it and use some of the coolest features.
Thank you! Please download: DayBack Calendar
Need More?
SeedCode tips & example files in your inbox
Need More?
SeedCode tips & example files in your inbox
Want More?
Be the first to see articles and tips like these
DOWNLOAD
TimeZync
Download TimeZync and we'll send you a couple short emails with tips syncing your FileMaker Go files.
Thank you! Please download: TimeZync
Want More?
Be the first to see articles and tips like these