Hovering over a hyperlink in the "new" outlook doesn't display the actual URL. How can this be remedied.

Hi Lee,

I hate to burst your theory, but Chrome is not an approved browser in our environment, and all users are using Microsoft Edge. I've posted the WebView2 information here a couple of times, and we're always up to date. The same is true for Microsoft Edge (currently running 128.0.2739.79 which is the most current production version as of 2024-09-16 according to your link as well).

As expected, the WebView2 version reported in the new Outlook is the same, with the new Outlook version being 1.2024.903.200. Hover over links - including titles - is not showing up. There is no point in installing another version as we're already running the latest.

Regarding how we got here - I don't bemoan Microsoft wanting to coalesce around a single platform and user interface across Windows, Web, and mobile. I actually am for that - although I do wish they had chosen a more cross-platform foundation than WebView2, or made it cross-platform and open source from the get-go (different discussion for a different day). I think Microsoft would have a win if they could bring web, mobile and desktop apps to parity for not just Outlook, but all major Microsoft 365 apps.

To be clear, we're not seeing either a hover over for the title at the cursor location, or the URL in the lower left corner as you describe. This is the issue. There is no additional details anywhere when hovering over a link. If the URL was at least visible, even if it wasn't at the cursor position but in the bottom left, I could at least train users for that. This is fundamentally broken. If you have any ideas on why this is happening, I'm all ears. Please let me know.

Hi Joshua,

That's interesting. When you mouse over a link, you don't get a tooltip that could point to WebView2 as a possible cause, which would match some other comments on this thread.

Generally speaking, you will see this on most websites. If you hover over a button or anchor(text link) tag, you will get a tooltip displaying the title attribute's contents on those HTML tags. However, of course, in a full browser, you can see the destination at the bottom left in the case of anchor tags as they have a href attribute. As such, you should at least get the standard functionality of a tooltip containing the title attribute of a link because the new Outlook app is just a progressive web app(PWA), and it's rendered in WebView2, and that is just a mini Edge browser.

Regarding Edge, I wonder if the users having the issue with the tooltip don't run Microsoft Edge but instead opt for Chrome or some other browser. I suggest this because the WebView2 runtime is part of Microsoft Edge. As such, when Edge updates, so does the WebView2 runtime.

Microsoft is aware that people may not always use Microsoft Edge; as such, they offer a distribution of the WebView2 component that any developer can package with their PWA-based applications. Microsoft almost certainly distributed a version of WebView2 with the new Outlook app to ensure it worked. However, if Edge isn't updating the WebView2 component, then you have to wait for Microsoft to update the component and distribute the update via an update to the Outlook app. This is likely slower than if you had gotten the update through Edge.

For reference, I'm presently running Edge/WebView2 Version 128.0.2739.79.

You can download the latest version of the WebView2 component and install it yourself should you need to by going to the following URL. https://developer.microsoft.com/en-us/microsoft-edge/webview

If updating WebView solves the issue in your test environment, you could push out the MSI installer via SCCM to ensure all devices on your network are on the latest version.

The worst part is that Microsoft went out of its way to disable the status bar in WebView2. You can see in the documentation by default that this is enabled, and this is the same function you would see in any browser, which shows the URL destination at the bottom left. Enabling this would likely fix this problem for everyone. https://learn.microsoft.com/en-gb/dotnet/api/microsoft.web.webview2.core.corewebview2settings.isstatusbarenabled

I don't believe this is an attempt by Microsoft to push people to use Microsoft Defender, though I can see how someone could come to that opinion, given the situation.

My theory on how we go here is that Microsoft wants to save money on developing its various email applications. The first step in that process was picking a single application to use going forward, and that application was the one that runs on outlook.live.com. It's already a PWA. It'll run on any OS with a browser supporting PWAs. This allows Microsoft to divest itself of the old Mail clients and the various Outlook desktop apps. It can likely also replace the Exchange OWA web app with the new application. Instead of developing/managing a half-dozen or more applications, Microsoft can now focus on one.

I did run a quick test, and the issue with not seeing the URL when mousing over a link also exists on outlook.live.com when you disable Safe Links. You would only see the URL if it's in the Title attribute. As mentioned above, you can see the URL in the status bar at the bottom left of the browser window, so it's less of an issue.

Of course, that's the final workaround, and it's highly impractical. You tell users not to use the new Outlook app to view emails, though you may want to keep it so you get nice notifications of new emails and ask them to use the following link instead for viewing and reading emails.

https://outlook.office.com/mail

You will at least see the URL of links in the bottom left corner of the browser window.

However, if you can switch back to the classic Outlook and use it for as long as possible before you are forced to switch, hopefully, Microsoft will have fixed it before you are forced to use the new Outlook.

Hi Lee,

I just did a test sending an email from the new Outlook with links in it, and opened it in the new Outlook for the recipient user and the hover over still isn't there. The hover over also isn't there in the email in the sent folder. It shows up when I view the email using the classic Outlook however. These emails were between internal users (same organization / M365 Tenant).

If Microsoft made the mistake of tying this to having Microsoft Defender that would be surprising. Many companies use 3rd party email protection services like ProofPoint, Mimecast, etc. But since my test of two users within the same M365 Tenant bypasses any external email filtering, that doesn't apply in this case. Also considering users within the same tenant have different experiences (between the new Outlook and classic Outlook), I'm leaning towards this not being dependent upon Microsoft Defender.

Hi Joshua,

Interesting. That's unfortunate. Hopefully a more complete solution will appear from Microsoft at some point.

I did notice one thing, however, and I have no idea if this is related to why it sort of works with some users and not others:

Emails composed within the new Outlook client and the consumer Hotmail/outlook.com web app will present the link's destination when hovering over it, while emails sent from the old Outlook client will show nothing. This is also the case when you send an HTML-formatted email through an SMTP relay.

I can see two things from the email source:

1. Emails composed via the new Outlook client have the "title" attribute set to the link's destination. As such, the hover function just shows the link's title. This is easy to fudge. You could easily have a malicious URL defined in the "href" attribute, which is where the link will take you, and have the Microsoft home page URL in the Title, making it seem the link goes to the Microsoft website when instead it goes elsewhere.
2. The link rewritten by Safe Links doesn't use the "title" attribute. However, they do add an "originalsrc" attribute. This contains the link's original destination before it was changed to the Safe Links URL. It also seems Microsoft has put some level of protection in place, as an attempt to set this manually in a test didn't work. I assume it's related to the hash values I can see in the source of the email.

This tells us that if the "Do not rewrite URLs, do checks via Safe Links API only" is enabled, which it is in the default "Built-In protection (Microsoft)" policy, and you see the URL when hovering over links, it could be picking up the title someone has set on the link. This could show that it's working for some emails and not others. In addition, you can whitelist URLs to bypass Safe Links rewrites, and this could also contribute to some emails where the hover function doesn't work, while for other emails, it does.

The following examples show the difference between the two link hover responses for anyone interested.

Title hover example.

Safe Links hover example.

It's not a complete solution, though. Users who don't use Microsoft Defender for email security and use third-party tools like Proofpoint may run into issues, as those solutions may not be able to present the same hover functionality that Microsoft's Safe Links system provides and have no reasonable path to using Safe Links in such an environment.

Hi Jérôme,

You are correct, the hover over works in message editing mode. The code is there! It just needs to work in reading mode also. I'm not going to train my users to enter editing mode on every email so they can hover over the links. Please address this ASAP Microsoft!