Synopsis #
Firefox, Firefox ESR, and Chromium are available as FreeBSD packages on supported combinations of release, architecture, and package branch. Package availability does not promise that a proprietary media service, meeting platform, extension, hardware-acceleration path, or enterprise authentication method supports FreeBSD.
Install one browser first and test it from a known-working graphical session. This keeps browser failures separate from desktop startup , audio , and webcam failures. For conferencing, protected playback, and capture requirements, record the complete workload with the multimedia-readiness guide .
Check the configured package source #
Inspect the repository policy and search for the exact package names:
$ pkg repositories
$ pkg search -x '^(firefox|firefox-esr|chromium)$'
The result can vary by architecture and by the quarterly or latest package branch. Do not change branches only to obtain one browser without reviewing the complete package transaction. Choose a package policy for the whole system.
Choose one initial browser #
| Requirement | Initial package | Maintenance implication |
|---|---|---|
| Current Firefox release | firefox | Receives the current feature-release line available in the configured repository |
| Longer Firefox release cycle | firefox-esr | Uses Mozilla’s ESR line as packaged by FreeBSD |
| Chromium engine required by a site | chromium | Adds a second browser engine and its own update cadence |
Install one selected package:
# pkg install firefox
Substitute firefox-esr or chromium only when that is the deliberate choice. Installing multiple browsers is reasonable for compatibility testing, but it should not be the first response to a broken graphical session.
Start it from a terminal first #
Within the graphical session, inspect its display variables:
$ echo "$XDG_SESSION_TYPE"
$ echo "$DISPLAY"
$ echo "$WAYLAND_DISPLAY"
Then start the selected browser from that terminal:
$ firefox
Terminal diagnostics often distinguish a missing display, unavailable shared library, profile error, and graphics-backend failure. Preserve that output before changing environment variables or disabling browser features.
Confirm the installed package and version:
$ pkg info firefox
Substitute the actual package name. Include this output, the FreeBSD release, display-session type, and graphics package version in a useful bug report.
Test capabilities separately #
Use ordinary sites first, then test each required capability:
- Page rendering, downloads, and certificate validation.
- Audio playback after base-system audio works.
- Microphone selection after recording works outside the browser.
- Camera selection after
/dev/video*exists and a local viewer works. - Screen sharing under the actual Xorg or Wayland session.
- Required extensions, hardware keys, corporate authentication, and protected media.
A browser permission prompt cannot grant operating-system access that the login does not have. Conversely, a readable camera node does not grant a site browser permission. Diagnose the OS device, browser permission, and site permission as separate layers.
Do not use a meeting provider’s marketing compatibility table as proof that its web application supports FreeBSD. Test the required meeting as a guest before depending on it, and keep a fallback device for time-critical calls.
Treat protected media as a separate requirement #
Some streaming services depend on proprietary digital-rights-management components and platform policies. A site that renders correctly may still refuse protected playback. Do not weaken browser security settings or install an unrelated Linux browser stack merely because ordinary video playback works differently.
Record protected-media support as its own preflight item. Recheck it after browser and service updates because either side can change independently.
Update the browser through the package policy #
Browsers process untrusted network content and should not be left outside routine package maintenance:
# pkg update
# pkg upgrade
Review the full transaction. Restart the browser after its package or shared libraries change. A running browser process continues using code and libraries from before the upgrade until it exits.
When a browser update regresses a required feature, save the package versions and diagnostic output. Do not keep an indefinitely vulnerable browser as the permanent workaround.