3 Ways to Remove Browser Chrome and Go Fullscreen in Java Web Apps

Imagine your Java web application running without browser toolbars or navigation bars—just pure, focused content filling the entire screen.

This guide reveals three proven methods to eliminate browser chrome in Vaadin applications, from zero-code solutions to Progressive Web Apps and the Fullscreen API, complete with working code examples you can implement today.

Why remove browser chrome from your Java web application?

Web browsers traditionally show — in addition to the actual content — the address bar, back/forward buttons, and bookmarks bar. All that is called “the browser chrome.”

It’s helpful for browsing, but not ideal for web applications.

Recently, the trend has been to reduce chrome height slightly, but in many cases, the UX of an application improves even more if the browser chrome, and possibly even OS-provided decorations, can be hidden.

Not only do you get more screen estate for your web application, but relevant content can be better focused when needed.

Let me introduce three practical methods to get rid of the browser chrome and go full screen, each with its own pros and cons.

1. Rely on Browser and OS Fullscreen Features

Most web browsers have some sort of support for going fullscreen, possibly utilizing built-in OS features.
For example, on macOS, in Chrome and Safari, if you click on the OS’s maximize button, the browser automatically also hides the location bar and other browser chrome.

Tip: This requires no code or configuration from you as a developer.

firefox-os-fullscreen

Utilizing full-screen functionality by the OS requires nothing from the web developer. Here, Firefox on a desktop Mac enters full-screen mode. Some browsers also hide their own “chrome”, but Firefox by default leaves that visible.

The problem with this approach is that there are differences in how browsers behave. For example, Firefox by default keeps the chrome visible.

A bigger issue for developers is that most users don’t even know these features exist — and since the shortcuts are OS-specific, it’s nearly impossible to guide users toward them through your app’s UI or documentation.

2. Progressive Web Apps (PWAs): The App-Like Experience Web Apps

Apple introduced the concept of “home screen web apps“ originally as the only way to create custom applications for iPhones.

In case web developers also provide some metadata, they get superpowers like stronger caching and the ability to remove obsolete browser chrome.

Google later invested heavily in this technology, rebranded it as Progressive Web Apps(PWAs), and this variation has now essentially become a cross-platform de facto standard.

Example: Starpass

Starpass is an inspirational example of a web application that heavily utilizes PWA features.

Here it is “installed” on an iPhone, with its main menu open. Technically, it is “just a web app”, but it opens without the “browser chrome” and can utilize the whole screen estate - even the area behind the iPhone’s always visible top bar.

One thing that even many web developers have missed is that these “installable web applications” have also become available on desktop devices.

This is probably the best method today to deliver a better UX for frequently used web apps. Not only will your application gain more usable estate, but it will also be faster for users to open, as it will appear in the operating system’s application switches and docks like real apps.

With frameworks like Vaadin, enabling PWA support can be as simple as adding an annotation. Get started with PWA technology.

3. The Full-screen API: Total Control via JavaScript

Basic web pages and less frequently used apps can also benefit from removing browser chrome.
Think about use cases like:

Watching a video
Exploring a large map
Playing a game
Displaying a slideshow

Modern browsers provide a standardized JavaScript API to enter full-screen.
With this API, you can remove both browser chrome and OS UI — and almost all modern browsers support it, except Safari on iPhones*.

looping-fullscreen-api (1)

The slideshow feature in Google Slides is built on the standardized Fullscreen API. On most common browsers, it allows you to get rid of both browser chrome and OS decorations.

How It Works

The Fullscreen API is very handy because it lets you remove both browser chrome and parts of your own app chrome (like menus).
The requestFullscreen() method is available on every DOM element, and the browser hides the rest of the DOM when it’s invoked.

This is useful when you want, for example, a video element or map component to fill the entire screen.

However, focusing a certain element for full screen may have some unexpected side effects:

Background color may have been set only for parent elements that are not displayed in full screen, which may completely destroy your theme.
Complex UI widgets can render partially to the root of the DOM, for example, to show temporary elements floating on top of the UI – these might simply not appear at all.

To overcome these issues with least fiddling, I urge you to go all the way up to document or document.documentElement in the DOM tree and request full screen for that. If you need to hide some of your own app chrome as well, it might be easier to hide them yourself than to workaround the side-effects.

Activation Requirements

The Fullscreen API requires “transient activation”, which means that you can’t just go and immediately make your video play in full screen.
Like with many other similar APIs, browsers ensure that entering full-screen is only triggered by a meaningful action from the user themselves.
In practice, you’ll need a click event or similar, but direct asynchronous callbacks of such events are fine as well.

This is why the Progressive Web App approach is better for apps that constantly need the maximum screen estate.

Fullscreen with Vaadin and Viritin

Vaadin doesn't yet have an official Java API to trigger full-screen.
In the meantime, you can either:

Create your own helper using the Element API and a JS call
Use the Fullscreen helper class in the Viritin add-on.

The Fullscreen helper class also supports requesting full screen of specific components, but it doesn’t actually call the JS Fullscreen API on the underlying HTML element.
Instead, to workaround the previously mentioned issues this can cause, it hides the rest of the UI and then technically requests full-screen mode for the entire web view.
This way you will get the desired result without the unexpected.

With the following Java snippet, the image is displayed full screen when clicked – the surrounding UI will be temporarily hidden. Clicking again resets the UI.

Example:

var photo = new Image("/view.jpeg", "view");
photo.addClickListener(event -> {
   FullScreen.isFullscreen().thenAccept(isFullscreen -> {
       if (isFullscreen) {
           FullScreen.exitFullscreen();
       } else {
           FullScreen.requestFullscreen(photo);
           Notification.show("Click the image again to exit fullscreen");
       }
   });
});

*) I assume that for iPhone, Apple engineers just haven’t figured out a decent way to exit the full-screen mode.
For iPads (with pretty much the same OS), the feature is already available, OS showing a gray “X” in the top right corner as an escape mechanism.

Summary

Each method for hiding browser chrome has its own ideal use case and trade-offs:

Relying on browser/OS features is the most straightforward approach, but it is inconsistent across platforms and largely hidden from end users.
There is nothing needed from you as a web developer, but it isn't easy to guide users toward it programmatically or via UX cues.
Progressive Web Apps (PWAs) offer the best experience for frequently used web applications. When installed, they run in a standalone window without browser chrome, making them feel like native apps.
They're cross-platform and can significantly improve both usability and perceived performance, especially on desktops. With frameworks like Vaadin, enabling PWA support can be as simple as adding a single annotation.
The Fullscreen API is ideal for immersive, transient experiences—such as videos, maps, games, or slideshows—where full-screen focus is only occasionally required.
It gives fine-grained control but has constraints like needing user interaction to activate and possible UI quirks when focusing on individual elements.
Workarounds exist, such as using utilities like Viritin's Fullscreen helper class to simplify integration in Vaadin apps.

Choose the method that best fits your application's context:

Progressive Web Apps → for app-like UX
The Fullscreen API → for immersive views
Native fullscreen toggles → for minimal-effort gains when user-savvy is expected