Issue 332 Files Viewer Would Not Open

📂 #332 Opening a file in Files said "Cannot read properties of null (reading 'open')"

GitHub #332, reported by pappas81 · Files · broken in 5.2.0, fixed in 5.3.0 (#2907)

What you saw

On the Files desktop, double-clicking a file - a CSV, a spreadsheet, a text file, anything - showed a red message, Cannot read properties of null (reading 'open'), and no preview. The report came after moving Files' storage to S3 (a Nextcloud S3 API), so S3 looked like the cause - but S3 had nothing to do with it: the failure happened in the browser before the server was asked for the file, so it was the same on local storage. Opening the same file from a ticket's note worked.

The report also said that deleting a file in Files did not remove it from the bucket. That is by design: a delete in Files marks the file as deleted and keeps its bytes, on any storage, so it can be brought back. Restoring and permanently deleting are the recycle bin, #293.

What was wrong

The Files viewer (assets/js/files-viewer.js) remembered the Files window manager once, when its script loaded:

var WM = window.FilesWM || null;      // read once, at load
...
var w = WM.open({ kind: 'viewer', ... });   // later, when a file is opened

and loads only once per page (if (window.FilesViewer) return;).

In 5.2.0, #303 made documents open in place everywhere, so the page header (includes/waffle-menu.php → documentsPanelAssets()) now loads the viewer on every page. On the Files desktop that copy runs before files-wm.js has set up window.FilesWM - so WM was null for good, and the Files page's own, later copy of the viewer returned straight away because a viewer already existed. Every open from the desktop then called null.open(...).

A file opened from a ticket worked because that path (openItem) uses the page's floating window, not the Files window manager.

The fix

The viewer asks for the window manager when it opens a file, not when it loads, and falls back to the page's floating window when there is none:

function wm() { return window.FilesWM || null; }
...
var WM = wm();
var host = WM || window.FloatWin.page();
var w = host.open({ kind: 'viewer', ... });

The translation helper does the same. A TRAP: comment at the top of the file says why the window manager must never be captured at load.

📁 Files

File	Change
assets/js/files-viewer.js	wm() instead of a captured WM; open() and L() ask at use
files/index.php, includes/documents_panel.php, tickets/index.php	files-viewer.js?v=10

How it was verified

On a test install, Files' storage was pointed at a small S3 stand-in (path-style, as Nextcloud needs) holding a CSV:

• Before the fix: opening it from the desktop failed with exactly the reported message, and the S3 stand-in's request log was empty - nothing reached storage.
• After the fix: the viewer window opens, the stand-in logs one ranged GET of the object, and the CSV is drawn as a table.
• The page's script list confirmed the viewer loaded twice (header, then the Files page), the first time before files-wm.js.

What this means for you

Update to 5.3.0 and opening files from the Files desktop works again, on any storage. If you are on 5.2.0, opening a file from a ticket, task or Documents panel was never affected.

Related: Files · #303 Documents open in place · #293 Files recycle bin