Do you use the Web Browser control in any of your Microsoft Access applications?
There are several reasons you may want to embed a web browser control in an application. Perhaps you want to make use of showing product pictures that you store on your company website in your in-house inventory application. Or you may want to get information from specific websites to then store and use as data. Or you may want to display data using a web based utility like Google Maps to show addresses or routes, or Power BI to show reports. Microsoft Access has provided a web browser control for your use for many years. In recent years, however, changes in support for the underlying engine for this control have created concerning issues.
What are the concerning issues for the Legacy Web Browser control?
The legacy web browser control is based on Internet Explorer 11 MSHTML (Trident) engine. As you may know, Microsoft Support for the IE Desktop application ended 6/15/2022. Support for IE Mode in Microsoft Edge or the MSHTML (Trident) engine will continue at least thru 2029. However, many websites are now being designed for the Microsoft Edge browser engine. You may find that opening these web sites throw script errors, render incorrectly, or refuse to render at all with the legacy Microsoft Access Web Browser control. Power BI reports are one example. Microsoftonline.com is an example of a website which displays a nice message “Microsoft 365 applications and services no longer support Internet Explorer 11.” It advises you to “Continue in Microsoft Edge”.
Some companies now prohibit the use of the Legacy Web Browser control available in Microsoft Access because of concerns that security updates are not being sufficiently applied to this older engine.
What is the path forward?
If you are using Microsoft 365 Version 2304 or later (Current channel as of the writing of this blog post), you now have the ability to replace the Legacy Web Browser control with the new Modern Web Browser (Chromium/Edge) control. This control is based on the WebView2 engine used in Edge. Many of the same properties, methods, and events that you used with the old control can be used with the new control. There are a few items that are not exactly the same, the biggest difference is that the Object property is no longer directly exposed. You can still read and/or manipulate the document property of the browser control object, but to do so, you will now need to use the RetrieveJavascriptValue or ExecuteJavascript methods.
One other caveat – if you develop in a version of Microsoft Access that has the new control, but your user base runs the application on older versions of Access, you should wait to use this new control. Fortunately you would still be able to open an application that contains the newer control with an older version of Access, but the new control will rend blank. This might be a case for maintaining two versions of a form during your application migration cycle, one with the old control for older versioned clients, the other with the new control.
Do I have to migrate to the new Edge Browser control now?
Both controls are now available in Microsoft Access so your old legacy web browser controls will continue to function at least to the degree that they are functioning now. The old browser control is now available on the bottom row of the form controls drop down (circled in red in the diagram on the left below.) The new Edge Web Browser control is located on the top row of the Form Design Controls drop down (circled in red in the diagram on the right below.)
At this point, you should make sure that for any NEW development in Microsoft Access that uses a web browser control, you use the NEW Edge Web Browser unless you have an older version user base (see above). You should also gradually phase out any previous use of the Legacy Web Browser control. The new control gives you better and more secure results.
How do I use the new methods, RetrieveJavascriptValue and ExecuteJavascript?
To use the Legacy Web Browser document object, you already needed to understand quite a bit about the HTML document object. To use the new methods it is also helpful to understand a bit about Javascript. A good reference for Javascript is W3Schools.com https://www.w3schools.com/js. Below is an example of some code to get the text from a table in the legacy web browser object versus the new way using RetrieveJavascript method.
Legacy code
Me.txtHTML = Me.WebBrowser1.Object.Document.getElementsByTagName(“table”)(0).innerHTML
New code
Me.txtHTML = Me.EdgeBrowser1.RetrieveJavascriptValue(“document.getElementsByTagName(‘table’)[0].innerHTML”)
Notice that the syntax is very close. You will need to watch out for some peculiarities of Javascript like indexes to arrays are referenced with square brackets. Javascript is also case sensitive and most of the objects/methods start with a lower case letter. It is more difficult to debug Javascript as improper syntax tends to yield no results. Still, some of the same techniques you used to retrieve values from HTML can be used to determine the proper Javascript syntax.
Any other advantages of the new control?
Yes – the new Edge Browser control works in continuous forms, something the old control did not do! This might be particularly handy, for example if you had list of websites and wanted to show a preview, or a list of inventory items to show a web based thumbnail.
Any other caveats?
There are two other issues regarding the new Edge Browser control that catch some people by surprise. To lock down security, Microsoft has purposefully set the control so that unless specified, any forwarding to a different domain done by the initially set website, brings up the new domain in your normal default web browser outside of the application. For clarification, you can still have a form where the web control is bound to a data field that contains a website URL. Moving from record to record, the bound website URL displays as the record changes within the form. However, if the web browser control is displaying a particular website, and you click on something on that web page that redirects to a different domain, then that by default it does NOT render in your web browser control. Instead it opens your default browser and displays there. I have seen this with a http:// that redirects to https://. I have also seen this with a login that redirects to some type of login service. To provide secure control and keep your redirection within your web control inside your Access application, you can set the new TrustedDomains property to a table that contains a list of domains which you trust and it is OK to redirect to.
The second caveat is that to display local files, you must prefix the path name with https://msaccess/YourFullPathName.
Available Documentation
https://learn.microsoft.com/en-us/office/vba/api/access.webbrowsercontrol
AL: new Edge Browser Control in Access, Maria Barnes with George Hepworth + Colin Riddington
