Allen Houchins
89acb97395
**Related issue:** Resolves #50125 Adds NVDA as a Windows Fleet-maintained app, from winget `NVAccess.NVDA` (2026.1.1, NSIS/nullsoft, x86 launcher). ## Identity — read out of the shipped installer, not the manifest I downloaded the 60 MB installer, extracted the NSIS payload, and read the identity fields from `_buildVersion.pyc` and the PE headers. The winget manifest is misleading in two ways: | Field | winget says | Actually is | Source | |---|---|---|---| | Architecture | `x86` | **x64** app behind a 32-bit NSIS launcher stub | `nvda_noUIAccess.exe` / `nvda_slave.exe` PE headers | | Registry DisplayName | PackageName `NVDA` | **`NVDA 2026.1.1`** | `source/installer.py` `getUninstallerRegInfo()`: `DisplayName=f"{name} {version}"` | | Publisher | `NV Access` | `NV Access` (matches) | `_buildVersion.pyc`: `publisher = "NV Access"` | Two consequences: - Because NVDA itself is a **64-bit** process, it registers under the native registry view, **not** `Wow6432Node` (the launcher's 32-bit-ness is irrelevant). Both scripts check both views anyway, for legacy 32-bit copies. - DisplayName carries the version, so this needs `fuzzy_match_name: true` → `name LIKE 'NVDA %'`. Publisher matches the locale manifest, so no `program_publisher` override. `installer_arch` stays `x86` because that's what the manifest declares and the ingester matches on it. ## Version reconciles without a validator exception DisplayVersion is the 4-part `2026.1.1.55980` (`version_detailed`) against winget's `2026.1.1`: - **Validator:** passes via the existing `strings.HasPrefix(result.Version, appVersion+".")` branch in `cmd/maintained-apps/validate/windows.go`. No new skip added — deliberately, since existence-only skips make patch policies always report "patched". - **Patch policy:** `version_compare('2026.1.1.55980', '2026.1.1')` is `> 0`, so an installed copy reads as newer, not outdated. No perpetual false "update available". ## The install script can't trust the exit code `source/gui/installerGui.py` `doInstall()` pops `winUser.MessageBox` / `gui.messageBox` on **every** install failure path with **no `if silent` guard**, and then falls through and exits **0**. Under SYSTEM in session 0 that means: 1. a failure **hangs forever** — nobody can click Retry/Cancel; and 2. if it were dismissed, a failed install would report **success**. So `nvda_install.ps1` uses a watchdog plus an Add/Remove Programs registration poll as the real success signal — the same shape as the existing `azure_data_studio_install.ps1`. Timeouts are 420 + 120 + 30 = 570s, under the caller's 10-minute cap. On timeout it kills only the launcher's `%TEMP%` children (`nvda_noUIAccess` / `nvda_uiAccess`), **deliberately not `nvda.exe`** — an installed NVDA runs as `nvda.exe`, and force-killing it would cut off a signed-in user's screen reader with no warning. ## Uninstall Vendor-documented `/S` (NVDA user guide, "Uninstalling NVDA"), plus `_?=` last so the NSIS uninstaller runs in place instead of relaunching from `%TEMP%` and returning immediately. NVDA writes **no** `QuietUninstallString`, and its `UninstallString` is an **unquoted path containing spaces** (`C:\Program Files\NVDA\uninstall.exe`), so the parser handles that form. The directory comes from NVDA's `InstallDir` value (not `InstallLocation`). Absence of the ARP entry is the success signal, since NVDA removes it via `nvda_slave.exe unregisterInstall`. ## Reviewer notes - **`installer_scope` is `""`, not `"machine"`.** NVDA genuinely installs machine-wide (`%ProgramFiles%\NVDA` + HKLM), but the winget manifest declares no `Scope`, so the ingester derives `""` and `"machine"` panics with "failed to find installer". The one-line ingester fix for this is designed in #48248 but isn't in `main`; I chose not to change shared installer-selection code for a single-app addition. Happy to land that fix here instead if preferred. - **Upgrade caveat:** if NVDA is running for a signed-in user, `--install-silent` refuses to overwrite its own running files by design (`installer.py` `install()`). The script fails with an actionable message rather than force-killing the screen reader. - Installer URL is version-pinned (`download.nvaccess.org/releases/2026.1.1/...`), not a "latest" redirect. SHA verified against my own download of the file. # Checklist for submitter - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements), JS inline code is prevented especially for url redirects, and untrusted data interpolated into shell scripts/commands is validated against shell metacharacters. - [x] Timeouts are implemented and retries are limited to avoid infinite loops ## Testing - [ ] QA'd all new/changed functionality manually `go test ./ee/maintained-apps/...` passes; prettier and `tsc --noEmit` are clean. I have no Windows host or `pwsh`, so **the install/uninstall scripts are unexercised** until FMA validation CI runs them on a Windows runner. No changes file — consistent with other FMA additions (#50415, #50348, #50352).
Fleet frontend
The Fleet frontend is a Single Page Application using React with Typescript and Hooks.
Table of contents
Running the Fleet web app
For details instruction on building and serving the Fleet web application consult the Contributing documentation.
Testing
Visit the overview of Fleet UI testing for more information on our testing strategy, philosophies, and tools.
To run unit or integration tests in ComponentName.tests.tsx, run yarn test -- ComponentName.tests.tsx. To test all Javascript components run yarn test.
QA Wolf manages our E2E test and will maintain the tests as well as raise any issues found from these tests. Engineers should not have to worry about working with E2E testing code or raising issues themselves.
For more information on how our front-end tests work, visit our frontend test directory.
Directory structure
Component directories in the Fleet front-end application encapsulate the entire component, including files for the component and its styles. The typical directory structure for a component is as follows:
└── ComponentName
├── _styles.scss
├── ComponentName.tsx
|-- ComponentName.tests.tsx
├── index.ts
_styles.scss: The component css stylesComponentName.tsx: The React componentComponentName.tests.tsx: The React component unit/integration testsindex.ts: Exports the React component- This file is helpful as it allows other components to import the component
by it's directory name. Without this file the component name would have to
be duplicated during imports (
components/ComponentNamevs.components/ComponentName/ComponentName).
- This file is helpful as it allows other components to import the component
by it's directory name. Without this file the component name would have to
be duplicated during imports (
components
The component directory contains global React components rendered by pages, receiving props from their parent components to render data and handle user interactions.
context
The context directory contains the React Context API pattern for various entities.
Only entities that are needed across the app has a global context. For example,
the logged in user (currentUser) has multiple pages and components
where its information is pulled.
interfaces
Files in the interfaces directory are used to specify the Typescript interface for a reusable Fleet entity. This is designed to DRY up the code and increase re-usability. These interfaces are imported in to component files and implemented when defining the component's props.
Additionally, local interfaces are used for props of local components.
layouts
The Fleet application has only 1 layout, the Core Layout. The Layout is rendered from the router and are used to set up the general app UI (header, sidebar) and render child components. The child components rendered by the layout are typically page components.
pages
Page components are React components typically rendered from the router.
React Router passed props to these pages in case they are needed. Examples include
the router, location, and params objects.
router
The router directory is where the react router lives. The router decides which
component will render at a given URL. Components rendered from the router are
typically located in the pages directory. The router directory also holds a paths
file which holds the application paths as string constants for reference
throughout the app. These paths are typically referenced from the App
Constants object.
services
CRUD functions for all Fleet entities (e.g. report) that link directly to the Fleet API.
styles
The styles directory contains the general app style setup and variables. It includes variables for the app color hex codes, fonts (families, weights and sizes), and padding.
templates
The templates directory contains the HTML file that renders the React application via including the bundle.js
and bundle.css files. The HTML page also includes the HTML element in which the React application is mounted.
test
The test directory includes test helpers, API request mocks, and stubbed data entities for use in test files. See the UI testing documentation for more on test helpers, stubs, and request mocks.
utilities
The utilities directory contains re-usable functions and constants for use throughout the application. The functions include helpers to convert an array of objects to CSV, debounce functions to prevent multiple form submissions, format API errors, etc.
Patterns
The list of patterns used in the Fleet UI codebase can be found in patterns.md.
Storybook
Storybook is a tool to document and visualize components, and we
use it to capture our global components used across Fleet. Storybook is key when developing new
features and testing components before release. It runs a separate server exposed on port 6006.
To run this server, do the following:
- Go to your root fleet project directory
- Run
make deps - Run
yarn storybook
The URL localhost:6006 should automatically show in your browser. If not, visit it manually.
Running Storybook before implementing new UI elements can clarify if new components need to be created or already exist. When creating a component, you can create a new file, component.stories.tsx, within its directory. Then, fill it with the appropriate Storybook code to create a new Storybook entry. You will be able to visualize the component within Storybook to determine if it looks and behaves as expected.