Access Dev Team Progress Update: New Web Browser Control

The Microsoft Access Engineering Team presented a feature update session to the Denver Area Access User Group (DAAUG) on November 17, 2022.  The team covered four topic areas:

• New Web Browser Control
• VBA Macro Code Signing in Access
• Improvements in exporting Access tables to Dataverse
• Q&A with the new Access Prinicipal Engineering Manager, Dale Rector

Check out the full video on YouTube: New and Upcoming in Access.

Highlights

• Development started 2 years ago–put on hold for DataVerse
• Existing (legacy) browser control will be supported until 2029
• The legacy browser control is built on the MSHTML browser engine (same as IE11)
• The new browser control is built on WebView2 (same underlying engine as Chrome/Edge)
• Both browser controls will live side-by-side until 2029
• Most existing functionality will be available in the new browser control, but...
• ...JavaScript programming will replace most of the VBA API functionality

Overview

Joe Jimenez presented this session starting at the 30:40 mark.

He started out by addressing the June 2022 retirement of IE11 and reassuring everyone that the legacy browser control would continue to work until 2029.

Next, he spoke about backwards compatibility being a key goal.  Almost everything you could do in the old browser control should be possible in the new browser control. That said, how you achieve that functionality may change.  The legacy browser control had an extensive VBA API.  The new control will not.  Instead, it appears that most of the functions that were possible via the VBA API on the legacy browser will need to be rewritten in JavaScript.

Joe then gave a short demo of some of the new capabilities added to the control this summer (refer to list below).  As part of the demo, he showed how Daniel Pineault's Pivot Table and Chart Demo database could be updated to run using the new browser control.

Finally, he finished with a chart that showed the VBA API capabilities of the legacy browser control alongside how (or if) those features would be implemented in the new browser control.  See below for a screenshot of this chart.

Sneak Peek at Future Migration Challenges

The new browser control will NOT be a drop-in replacement for the existing browser control. This is especially true if you are using the VBA API to automate interactions with web pages.

The MSHTML engine (which runs both the legacy browser control and the now-defunct IE11) has a built-in VBA API.  This is available via the Object property of the legacy browser control.  

For example, here's how you would execute arbitrary JavaScript in the legacy browser control:

Me.WebBrowser0.Object.Document.parentWindow.execScript("alert('hello from access');")

However, WebView2 does not have a VBA API.  So, the Access team is recreating that functionality from the ground up.  What this means in practical terms is that:

1. Not all API functionality will be available in the new browser control
2. Some new API functionality may be added
3. Any existing code that refers to the legacy browser control's Object property will need to be rewritten

For example, here's how you would execute the same arbitrary JavaScript code in the new Edge-based browser control:

Me.EdgeBrowser0.ExecuteJavascript("alert('hello from access');")

It remains to be seen how many methods will be added to the new browser control.  The following methods appeared in the presentation:

• .ExecuteJavascript()
• .RetrieveJavascriptValue()

Here's a list of the Access team's in-scope VBA API requirements.  It appears that everything listed on the left side will be available in the new browser function, though many feature available via VBA in the legacy browser control will only be available via JavaScript in the new browser control.

Progress To This Point

New capabilities built during summer 2022:

• Report support
• Edge Chromium dev tools
• Renavigate bound browser
• Load local files
• Scrollbar properties
• Mouse events
• Key events
• Basic VBA API (javascript, navigate, refresh)

Remaining Hurdles

The following features will be implemented:

• Print support
• Continuous forms
• Navigation allow list

The engineering team also has to meet with the Microsoft Security team and get their blessing.  And something tells me that's easier said than done...

Expected Release Date

Microsoft won't commit to an official release month for a new feature until they are 90% confident in the date.  

However, the team was asked this question point-blank during the Q&A portion of the presentation, and their response was, "We're hoping to be able to ship it early next year."

As a fellow programmer, I recognize "optimistic programmer speak" when I hear it.  With that in mind, I expect this feature to be released between April 2023 and August 2023.

My Final Thoughts

The web and programming world have changed since the original web browser control debuted.

The original Active Server Pages technology ("Classic ASP") was basically just VB6/VBA on the web.  That is why the MSHTML engine has such strong VBA API support.  With Microsoft abandoning VB6 in favor of the .NET Framework, I expect a very minimal VBA API for the new browser control.

The bad news for Access developers is that you will likely need to learn JavaScript to translate any existing VBA code that relies on the legacy browser control's .Object property.  The good news is that you won't be relying on the meagerly-funded Access team to provide support beyond a small number of VBA methods whose main purpose is to integrate with JavaScript.

I think the new browser control will be a bit like the introduction of the ribbon:

• It will require developers to rewrite working code
• Some simple things will be harder to do (code using WebBrowser0.Object)
• Certain advanced features will be possible for the first time

On the other hand, I don't think the legacy browser control is as popular as custom menus and toolbars were back in their day.  So, I don't expect quite the same level of wailing, dental gnashing, and garment rending as occurred with the release of Access 2007 and the introduction of the ribbon.

For developers who will be using a browser control for the first time, I think they will be quite happy with the experience.  For those whose projects are heavily dependent on the legacy browser control's VBA API, they should start transitioning to the new browser control as soon as it's available.  2029 will be here before you know it.

External references