[Bug]: Inline PDFs render as a black page in Desktop 6.3.0 but work in 6.2.2

Mattermost Desktop version

6.3.0

Operating system

macOS

Mattermost Server version

11.7.6 Team Edition
Build: 28150404267

Summary

PDF documents embedded inline by a Mattermost webapp plugin no longer render in Mattermost Desktop 6.3.0.

The native PDF viewer toolbar loads, but the document area remains entirely black.

The same document and endpoint:

• render correctly in Mattermost Desktop 6.2.2;
• render correctly in Chrome through the Mattermost web application;
• fail consistently in Mattermost Desktop 6.3.0.

This appears to be a Desktop 6.3 regression rather than a server, PDF, token, or HTTP byte-range issue.

Steps to reproduce

1. Install a Mattermost webapp plugin that renders a same-origin PDF using:

   <object
     type="application/pdf"
     data="/plugins/example.pdf-viewer/api/v1/document#page=69"
   />
   

2. Make the plugin endpoint return a valid PDF with support for HEAD and byte-range requests.

3. Open the PDF from Mattermost Desktop 6.3.0.

4. Observe that the native viewer toolbar appears, but the document area is black.

5. Open the same Mattermost page in Chrome: the PDF renders normally.

6. Repeat with Mattermost Desktop 6.2.2: the PDF renders normally.

Expected behavior

The PDF should render inline using Electron's native PDF viewer, as it did in Mattermost Desktop 6.2.2.

Actual behavior

The native PDF viewer shell opens, but every page remains black.

HTTP validation

The PDF endpoint returns valid byte-range responses:

HTTP/2 206
Content-Type: application/pdf
Content-Length: 65536
Content-Range: bytes 0-65535/17745491
Accept-Ranges: bytes
Content-Encoding: identity
Cache-Control: private, max-age=300, no-transform
Content-Disposition: inline

The returned body has the expected length and begins with %PDF-.

The PDF itself is valid, unencrypted, and renders correctly with PDFium in Chrome and other PDF tools.

Suspected regression

Mattermost Desktop 6.3.0 introduced additional subframe navigation filtering in PR #3928:

https://github.com/mattermost/desktop/pull/3928

isAllowedSubframeNavigation() currently allows only:

• http:
• https:
• about:blank
• about:srcdoc

https://github.com/mattermost/desktop/blob/v6.3.0/src/app/views/webContentEventsCommon.ts#L40-L75

Electron's built-in PDF viewer uses an internal chrome-extension:// subframe. Our current hypothesis is that the new will-frame-navigate handler blocks this internal PDF viewer navigation.

This would explain why the viewer shell appears while the document rendering area remains black.

We have not yet captured the exact blocked frame URL, so this causal link should still be confirmed in Desktop debug logs.

Suggested fix direction

Allow the exact trusted origin of Electron's built-in PDF viewer, rather than allowing the chrome-extension: protocol generally, or otherwise exempt Electron's internal PDF viewer navigation from this subframe guard.

Regression range

• Last known working version: 6.2.2
• First known failing version: 6.3.0

Additional information

The issue is reproducible for multiple users. A screenshot and a minimal test plugin can be provided if required.

Read src/app/views/webContentEventsCommon.ts, especially isAllowedSubframeNavigation(), and inspect PR #3928. Use Desktop debug logs to capture the blocked PDF viewer frame URL, confirm the regression between 6.2.2 and 6.3.0, and verify that inline PDFs render while ordinary disallowed subframes remain blocked.