Alexey Rodionov on web.dev

PWAs on Oculus Quest 2

2022-01-10T00:00:00Z

The Oculus Quest 2 #

The Oculus Quest 2 is a virtual reality (VR) headset created by Oculus, a division of Meta. It is the successor to the company's previous headset, the Oculus Quest. The device is capable of running as both a standalone headset with an internal, Android-based operating system, and with Oculus-compatible VR software running on a desktop computer when connected over USB or Wi-Fi. It uses the Qualcomm Snapdragon XR2 system on a chip with 6 GB of RAM. The Quest 2's display is a singular fast-switch LCD panel with 1,832 × 1,920 pixels per eye resolution that runs at a refresh rate of up to 120 Hz.

The Oculus Browser #

Currently there are three browsers available for the Oculus Quest 2: Wolvic, a successor to Firefox Reality, and the built-in Oculus Browser. This article focuses on the latter. The Oculus website introduces the Oculus Browser as follows.

"Oculus Browser provides support for the latest web standards and other technologies to help you create VR experiences on the web. Today's 2D web sites work great in Oculus Browser because it's powered by the Chromium rendering engine. It's further optimized for Oculus headsets to get the best performance and to enable web developers take advantage of the full potential of VR with new APIs, like WebXR. Through WebXR, we're opening the doors to the next frontier of the web."

User agent #

The browser's user agent string at the time of writing is as follows.

Mozilla/5.0 (X11; Linux x86_64; Quest 2)
AppleWebKit/537.36 (KHTML, like Gecko)
OculusBrowser/18.1.0.2.46.337441587
SamsungBrowser/4.0
Chrome/95.0.4638.74
VR
Safari/537.36

As you can see, the current version 18.1.0.2.46.337441587 of the Oculus Browser is based on Chrome 95.0.4638.74, that is only one version behind the current stable version of Chrome, which is 96.0.4664.110. If the user switches to mobile mode, VR changes to Mobile VR.

User interface #

The browser's user interface (shown above) has the following features (top row from left to right):

Back button
Reload button
Site information
URL bar
Create bookmark button
Resize button with narrow, medium, and wide options as well as a zoom feature
Request mobile website button
Menu button with the following options:
- Enter private mode
- Close all tabs
- Settings
- Bookmarks
- Downloads
- History
- Clear browsing data

The bottom row includes the following features:

Close button
Minimize button
Three dots button with back, forward, and reload options

Refresh rate and device pixel ratio #

For Oculus Quest 2, Oculus Browser renders both 2D web page content and WebXR at a 90 Hz refresh rate. When watching fullscreen media, Oculus Browser optimizes the device refresh rate based on the frame rate of the video, for example, 24 fps. The Oculus Quest 2 has a device pixel ratio of 1.5 for crisp text.

PWAs in Oculus Browser and the Oculus Store #

On October 28, 2021, Jacob Rossi, Product Management Lead at Meta (Oculus), shared that PWAs were coming to Oculus Quest and Oculus Quest 2. In the following, I describe the PWA experience on Oculus and explain how to build, sideload, and test your PWA on the Oculus Quest 2.

Login state is shared between Oculus Browser and PWAs, allowing users to seamlessly switch between the two. Naturally, Facebook Login is supported out of the box. The Oculus Browser includes a password manager that allows users to store and share their passwords securely between the browser and installed app experiences.

PWA window sizes #

Browser windows and windows of installed PWAs can be freely resized by the user. The height can vary between 625 px and 1,200 px. The width can be set between 400 px and 2,000 px. The default dimensions are 1,000 × 625 px.

Interacting with PWAs #

PWAs can be controlled with the Oculus left and right controllers, Bluetooth mice and keyboards, and via hand tracking. Scrolling works via the thumb sticks on the Oculus controllers, or by pinching the thumb and the index finger and moving in the desired direction. To select something, the user can point and pinch.

Permissions for PWAs #

Permissions in Oculus Browser work pretty much the same way as in Chrome. The state is shared between apps running in the browser and installed PWAs, so users can switch between the two experiences without having to grant the same permissions again.

Albeit many permissions are implemented, not all features are supported. For example, while requesting the geolocation permission succeeds, the device never actually gets a location. Similarly, the various hardware APIs like WebHID, Web Bluetooth, etc. all pass feature detection, but don't actually show a picker that would let the user pair the Oculus with a hardware device. I suppose feature detectability of APIs will be refined once the browser matures.

Debugging PWAs via Chrome DevTools #

After enabling Developer Mode, debugging PWAs on Oculus Quest 2 works exactly as described in Remote debug Android devices.

On the Oculus device, browse to the desired site in Oculus Browser.
Launch Google Chrome on your computer and navigate to chrome://inspect/#devices.
Find the Oculus device in question, which will be followed by a set of Oculus Browser tabs currently open on the device.
Click inspect on the desired Oculus Browser tab.

App discovery #

People can use the browser itself or the Oculus Store to discover PWAs. Just like with any other browser, installed PWAs also work in Oculus Browser as websites running in a tab. When a user visits a site, the Oculus Browser will help them discover the app if (and only if) it is available in the Oculus Store. For users that already have the app installed, Oculus Browser will help them easily switch to the app if they desire.

Exemplary PWAs on the Oculus Quest 2 #

PWAs by Meta #

Multiple Meta divisions have created PWAs for the Oculus Quest 2, for example Instagram and Facebook. These PWAs run in standalone app windows that don't have a URL bar and that can be freely resized.

PWAs by other developers #

At the time of this writing, there is a small but growing number of PWAs for the Oculus Quest 2 on the Oculus Store. Spike lets users experience all the essential work tools like email, chat, calls, notes, tasks, and to-dos from their inbox in a virtual environment hub right in the Spike app.

Another example is Smartsheet, a dynamic workspace that provides project management, automated workflows, and rapid building of new solutions.

More PWAs like Slack, Dropbox, or Canva are coming, as teased in a video featuring Jacob Rossi that was released in the context of Facebook's Connect conference in 2021.

Creating PWAs for Oculus #

Meta outlined the required steps in their documentation. In general, PWAs that are installable in Chrome should oftentimes work out of the box on Oculus.

Web App Manifest requirements #

There are some important differences compared to Chrome's installability criteria and the Web App Manifest spec. For example, Oculus only supports left-to-right languages at the moment, whereas the Web App Manifest spec enforces no such constraints. Another example is start_url, which Chrome strictly requires for an app to be installable, but which on Oculus is optional. Oculus offers a command line tool that lets developers create PWAs for the Oculus Quest 2, which allows them to pass the missing (or override the existing) parameters in the Web App Manifest.

Name	Description
`name`	(Required) The name of the PWA. Currently Oculus only supports left-to-right languages for the name.
`display`	(Required) Either `"standalone"` or `"minimal-ui"`. Oculus currently doesn't support any other values.
`short_name`	(Required) A shorter version of the app name, if needed.
`scope`	(Optional) The URL or paths that should be considered as part of the app.
`start_url`	(Optional) The URL to show at app launch.

Oculus has a number of optional proprietary Web App Manifest fields that can be used to customize the PWA experience.

Name	Description
`ovr_package_name`	(Optional) Sets the package name of the APK generated for the PWA. This must be in reverse domain name notation, e.g., `"com.company.app.pwa"`. If not set, developers must provide a package name to the command line tool with the (then required) parameter `--package-name`.
`ovr_multi_tab_enabled`	(Optional) If `true`, this boolean field will give the PWA a tab bar similar to Oculus Browser. In multi-tab PWAs, internal links that target a new tab (`target="_new"` or `target="_blank"`) will open in new tabs within the PWA window. This differs from single-tab PWAs where such links would open to a Oculus Browser window. This feature is currently being standardized as Tabbed Application Mode.
`ovr_scope_extensions`	(Optional) Allows a PWA to include more web pages within the scope of the web application. It consists of a JSON dictionary containing extension URLs or wildcard patterns. This feature is currently being standardized as Scope Extensions for Web Apps.

Packaging PWAs with Bubblewrap CLI #

Bubblewrap is an open source set of libraries and a command line tool (CLI) for Node.js. Bubblewrap is developed by the Google Chrome team, to help developers generate, build, and sign an Android project that launches your PWA as a Trusted Web Activity (TWA).

Meta Quest Browser currently doesn't fully support TWA, but starting from version 1.18.0, Bubblewrap supports packaging PWAs for Meta Quest devices.

It can generate universal APK files that open a TWA on regular Android devices and the Meta Quest Browser on Meta Quest devices.

Assuming you have Node.js installed, Bubblewrap CLI can be installed with the following command:

npm i -g @bubblewrap/cli

When running Bubblewrap for the first time, it will offer to automatically download and install the required external dependencies—Java Development Kit (JDK) and Android SDK Build Tools.

To generate a Meta Quest compatible Android project that wraps your PWA, run the init command with the --metaquest flag and follow the wizard:

bubblewrap init --manifest="https://your.web.app/manifest.json" --metaquest

Once the project has been generated, build and sign it by running:

bubblewrap build

This will output a file called app-release-signed.apk. This file can be installed on the device or published to the Meta Quest Store, Google Play Store or any of the other Android app distribution platforms.

Packaging PWAs with Oculus Platform Utility #

Oculus Platform Utility is the official command line tool developed by Meta for publishing apps for Oculus Rift and Meta Quest devices.

It also allows to package PWAs for Meta Quest devices with the create-pwa command and publish them to the Meta Quest Store and App Lab.

Set the output file name via the -o parameter and the path to Android SDK via the --android-sdk parameter.

Point the tool at the live URL of the web app manifest via the --web-manifest-url parameter.

If you don't have a manifest on your live PWA or wish to override the live manifest, you can still generate an APK for your PWA using a local manifest file and the --manifest-content-file parameter.

To leave the manifest as pure as possible, use the --package-name parameter with a value in reverse domain name notation (for example, com.company.app.pwa), rather than adding the proprietary ovr_package_name field to the manifest.

ovr-platform-util create-pwa -o output.apk --android-sdk ~/bin/android-10 --manifest-content-file manifest.json --package-name com.company.app.pwa

Packaging PWAs with PWABuilder #

Using PWABuilder is in the authors' view the easiest and therefore recommended way to package PWAs for Meta Quest at the moment.

PWABuilder is an open source project developed by Microsoft, that allows developers to package and sign their PWAs for publishing to various stores, including Microsoft Store, Google Play Store, App Store, and Meta Quest Store.

Packaging PWAs with PWABuilder is as easy as entering the URL of a PWA, entering/editing the metadata for the app, and clicking the Generate button.

PWABuilder gives developers the choice of what tool under the hood to use for packaging PWAs for Meta Quest devices.

You can choose the Meta Quest option to use the Oculus Platform Utility.

You can choose the Android option to use the Bubblewrap and select the Meta Quest compatible checkbox.

Installing PWAs with ADB #

After creating the APK file, you can sideload it to the Meta Quest device using the ADB via USB or Wi-Fi:

adb install app-release-signed.apk

If you use the Bubblewrap CLI for packaging PWAs, it provides a convenient alias command to sideload the APK file:

bubblewrap install

Sideloaded apps appear in an Unknown Sources section in the app drawer.

App submission #

Uploading and submitting PWAs to the Oculus Store is covered in detail in the Oculus Developer Center docs.

Apart from submitting apps to the Oculus Store, developers can also distribute their apps via platforms like SideQuest directly to consumers safely and securely, without requiring store approval. This allows them to get an app directly to end users, even if it is early in development, experimental, or aimed at a unique audience.

Testing multi-tab apps #

To test multi-tab apps, I created a little test PWA that demonstrates the various link features: namely opening a new in-PWA tab, staying on the current tab, opening a new browser window, and opening in a WebView staying on the current tab. Create a locally installable copy of this app by running the commands below on your machine.

ovr-platform-util create-pwa -o test.apk --android-skd ~/bin/android-10 --web-manifest-url https://tomayac.github.io/oculus-pwa-test/manifest.json --package-name com.example.pwa
adb install test.apk

Here's a screencast of the test app.

An Oculus version of SVGcode #

To take the instructions for a spin, I created an Oculus version of my most recent PWA, SVGcode. You can download the resulting APK file output.apk from my Google Drive. If you want to investigate the package further, I have a decompiled version, too. Find the build instructions in package.json.

Using the app on Oculus works fine, including the ability to open and save files. The Oculus Browser doesn't support the File System Access API, but the fallback approach helps. The only thing that didn't function is pinch-zooming. My expectation was for it to work by pressing the trigger button on both controllers and then moving the controllers in opposed directions. Other than that, everything else was performant and responsive, as you can see in the embedded screencast.

Immersive 3D WebXR PWAs #

PWA support on Oculus Quest is not limited to flat 2D apps. Developers can build immersive 3D experiences for VR using the WebXR API.

Wondering how various prompts (PWA install, permission requests, notifications) are handled from within VR, if at all?

Here's a screencast of User Agent Prompts test from the Immersive Web Working Group's WebXR Tests.

As you can see, entering VR mode requires the user's permission. Permissions are asked once per origin. Requesting permissions leaves the immersive mode. Notifications are currently not supported.

Hand tracking #

You can use your hands to interact with PWAs in immersive mode thanks to the WebXR Hand Input API and Meta's AI-based hand-tracking system.

Here's a screencast of Hand Tracking Sample from the Immersive Web Working Group's WebXR Samples.

Augmented/Mixed Reality (Passthrough) #

As announced at Meta Connect 2022, Meta Quest Browser has added support for WebXR Augmented Reality (AR), also known as Mixed Reality (MR), on Meta Quest 2 and Meta Quest Pro devices.

Let's check a slightly modified A-Frame starter example with scaled-down models and hidden sky and plane for augmented reality.

A-Frame is an open source web framework for building 3D/VR/AR experiences entirely out of declarative, reusable custom HTML elements that are easy to read, understand, and copy-and-paste.

Here's a screencast of this demo on Meta Quest 2.

Meta Quest 2 has monochrome cameras, so the passthrough is in grayscale, while Meta Quest Pro has color cameras.

Conclusions #

PWAs on Oculus Quest 2 are a lot of fun and very promising. The endless virtual canvas that lets users scale their screen to whatever fits the current task best has a lot of potential to change the way we work in the future. While typing in VR with hand tracking is still in its infancy and, at least for me, doesn't work very reliably yet, it works well enough for entering URLs or typing short texts.

What I like the most about PWAs on the Oculus Quest 2 is that they are just regular PWAs that can be used unchanged in a browser tab or through a thin APK wrapper without any platform-specific APIs. Targeting multiple platforms with the same code has never been easier. Here's to PWAs in VR and AR on the web. The future is bright!

Acknowledgements #

Oculus Quest 2 photo by Maximilian Prandstätter on Flickr. Oculus Store images of Instagram, Facebook, Oculus Browser, and Spike apps as well as app discoverability illustration and hand tracking animation courtesy of Meta. Hero image by Arnau Marín i Puig. This post was reviewed by Joe Medley.

Displaying a Notification

2016-06-30T00:00:00Z

The notification options is split into two sections, one that deals with the visual aspects (this section) and one that explains the behavioral aspects of notifications (the next section).

You can play around with various notification options in various browsers on various platforms using Peter Beverloo's Notification Generator.

Visual Options #

The API for showing a notification is simple:

<ServiceWorkerRegistration>.showNotification(<title>, <options>);

Both arguments, title and options are optional.

The title is a string and options can be any of the following:

{
  "//": "Visual Options",
  "body": "<String>",
  "icon": "<URL String>",
  "image": "<URL String>",
  "badge": "<URL String>",
  "dir": "<String of 'auto' | 'ltr' | 'rtl'>",
  "timestamp": "<Long>"

  "//": "Both visual & behavioral options",
  "actions": "<Array of Strings>",
  "data": "<Anything>",

  "//": "Behavioral Options",
  "tag": "<String>",
  "requireInteraction": "<boolean>",
  "renotify": "<Boolean>",
  "vibrate": "<Array of Integers>",
  "sound": "<URL String>",
  "silent": "<Boolean>",
}

Let's look at the visual options:

Title and body options #

This is what a notification looks like without the title and options in Chrome on Windows:

As you can see, the browser name is used as the title and the "New notification" placeholder is used as the notification body.

If a progressive web application is installed on the device, the web app name will be used instead of the browser name:

If we ran the following code:

const title = 'Simple Title';

const options = {
  body: 'Simple piece of body text.\nSecond line of body text :)',
};

registration.showNotification(title, options);

we'd get this notification in Chrome on Linux:

In Firefox on Linux it would look like this:

This is what the notification with a lot of text in the title and body looks like in Chrome on Linux:

Firefox on Linux collapses the body text until you hover the notification, causing the notification to expand:

The same notifications in Firefox on Windows look like this:

As you can see, the same notification may look different in different browsers. It may also look different in the same browser on different platforms.

Chrome and Firefox use the system notifications and notification center on platforms where these are available.

For example, system notifications on macOS don't support images and actions (buttons and inline replies).

Chrome also has a custom notifications for all desktop platforms. You can enable it by setting the chrome://flags/#enable-system-notifications flag to the Disabled state.

Icon #

The icon option is essentially a small image you can show next to the title and body text.

In your code you need to provide a URL to the image you'd like to load:

const title = 'Icon Notification';

const options = {
  icon: '/images/demos/icon-512x512.png',
};

registration.showNotification(title, options);

You get this notification in Chrome on Linux:

and in Firefox on Linux:

Sadly there aren't any solid guidelines for what size image to use for an icon.

Android seems to want a 64dp image (which is 64px multiples by the device pixel ratio).

Assuming the highest pixel ratio for a device is 3, an icon size of 192px or more is a safe bet.

Badge #

The badge is a small monochrome icon that is used to portray a little more information to the user about where the notification is from:

const title = 'Badge Notification';

const options = {
  badge: '/images/demos/badge-128x128.png',
};

registration.showNotification(title, options);

At the time of writing the badge is only used in Chrome on Android.

On other browsers (or Chrome without the badge), you'll see an icon of the browser.

As with the icon option, there are no real guidelines on what size to use.

Digging through Android guidelines the recommended size is 24px multiplied by the device pixel ratio.

Meaning an image of 72px or more should be good (assuming a max device pixel ratio of 3).

Image #

The image option can be used to display a larger image to the user. This is particularly useful to display a preview image to the user.

const title = 'Image Notification';

const options = {
  image: '/images/demos/unsplash-farzad-nazifi-1600x1100.jpg',
};

registration.showNotification(title, options);

In Chrome on Linux the notification will look like this:

In Chrome on Android the cropping and ratio are different:

Given the differences in ratio between desktop and mobile, it's extremely hard to suggest guidelines.

Since Chrome on desktop doesn't fill the available space and has a ratio of 4:3, perhaps the best approach is to serve an image with this ratio and allow Android to crop the image. That being said, the image option may still change.

On Android, the only guideline is a width of 450dp.

Using this guideline, an image of width 1350px or more would be a good bet.

Actions (Buttons) #

You can define actions to display buttons with a notification:

const title = 'Actions Notification';

const options = {
  actions: [
    {
      action: 'coffee-action',
      type: 'button',
      title: 'Coffee',
      icon: '/images/demos/action-1-128x128.png',
    },
    {
      action: 'doughnut-action',
      type: 'button',
      title: 'Doughnut',
      icon: '/images/demos/action-2-128x128.png',
    },
    {
      action: 'gramophone-action',
      type: 'button',
      title: 'Gramophone',
      icon: '/images/demos/action-3-128x128.png',
    },
    {
      action: 'atom-action',
      type: 'button',
      title: 'Atom',
      icon: '/images/demos/action-4-128x128.png',
    },
  ],
};

registration.showNotification(title, options);

For each action you can define a title, an action (which is essentially an ID), an icon, and a type. The title and icon is what you can see in the notification. The ID is used when detecting that the action button had been clicked (more about this in the next section). The type can be omitted because 'button' is the default value.

At the time of writing only Chrome and Opera for Android support actions.

In the example above there are four actions defined to illustrate that you can define more actions than will be displayed. If you want to know the number of actions that will be displayed by the browser, you can check window.Notification?.maxActions:

const maxVisibleActions = window.Notification?.maxActions;

if (maxVisibleActions) {
  options.body = `Up to ${maxVisibleActions} notification actions can be displayed.`;
} else {
  options.body = 'Notification actions are not supported.';
}

On desktop, the action button icons display their colors (see the pink doughnut):

On Android 6 and earlier, the icons are colored to match the system color scheme:

On Android 7 and later, the action icons aren't shown at all.

Chrome will hopefully change it's behavior on desktop to match Android (i.e. apply the appropriate color scheme to make the icons match the system look and feel). In the meantime, you can match Chrome's text color by making your icons have a color of #333333.

It's also worth calling out that icons look crisp on Android but not on desktop.

The best size I could get to work on desktop Chrome was 24px x 24px. This sadly looks out of place on Android.

The best practice we can draw from these differences:

Stick to a consistent color scheme for your icons so at least all your icons are consistently displayed to the user.
Make sure they work in monochrome as some platforms may display them that way.
Test the size and see what works for you. 128px × 128px works well on Android for me but was poor quality on desktop.
Expect your action icons not to be displayed at all.

The Notification spec is exploring a way to define multiple sizes of icons, but it looks like it'll be some time before anything is agreed upon.

Actions (Inline Replies) #

You can add an inline reply to the notification by defining an action with the 'text' type:

const title = 'Alexey Rodionov';

const options = {
  body: 'How are you doing? )',
  image: '/images/demos/avatar-512x512.jpg',
  icon: '/images/demos/icon-512x512.png',
  badge: '/images/demos/badge-128x128.png',
  actions: [
    {
      action: 'reply',
      type: 'text',
      title: 'Reply',
      icon: '/images/demos/action-5-128x128.png',
    }
  ],
};

registration.showNotification(title, options);

This is what it will look like on Android:

Clicking on the action button opens a text input field:

You can customize the placeholder for the text input field:

const title = 'Alexey Rodionov';

const options = {
  body: 'How are you doing? )',
  icon: '/images/demos/avatar-512x512.jpg',
  badge: '/images/demos/badge-128x128.png',
  actions: [
    {
      action: 'reply',
      type: 'text',
      title: 'Reply',
      icon: '/images/demos/action-5-128x128.png',
      placeholder: 'Type text here',
    }
  ],
};

registration.showNotification(title, options);

In Chrome on Windows, the text input field is always visible without having to click the action button:

You can add more than one inline reply or combine buttons and inline replies:

const title = 'Poll';

const options = {
  body: 'Do you like this photo?',
  image: '/images/demos/cat-image.jpg',
  icon: '/images/demos/icon-512x512.png',
  badge: '/images/demos/badge-128x128.png',
  actions: [
    {
      action: 'yes',
      type: 'button',
      title: '👍 Yes',
    },
    {
      action: 'no',
      type: 'text',
      title: '👎 No (explain why)',
      placeholder: 'Type your explanation here',
    },
  ],
};

registration.showNotification(title, options);

Direction #

The dir parameter allows you to define which direction the text should be displayed, right-to-left or left-to-right.

In testing, it seemed that the direction was largely determined by the text rather than this parameter. According to the spec, this is intended to suggest to the browser how to layout options like actions, but I saw no difference.

Probably best to define if you can, otherwise the browser should do the right thing according to the text supplied.

The parameter should be set to either auto, ltr or rtl.

A right-to-left language used on Chrome on Linux looks like this:

In Firefox (while hovering over it) you'll get this:

Vibrate #

The vibrate option allows you to define a vibration pattern that'll run when a notification is displayed, assuming the user's current settings allow for vibrations (i.e. the device isn't in silent mode).

The format of the vibrate option should be an array of numbers that describe the number of milliseconds the device should vibrate, followed by the number of milliseconds the device should not vibrate.

const title = 'Vibrate Notification';

const options = {
  // Star Wars shamelessly taken from the awesome Peter Beverloo
  // https://tests.peter.sh/notification-generator/
  vibrate: [
    500, 110, 500, 110, 450, 110, 200, 110, 170, 40, 450, 110, 200, 110, 170,
    40, 500,
  ],
};

registration.showNotification(title, options);

This only affects devices that support vibration.

Sound #

The sound parameter allows you to define a sound to play when the notification is received.

At the time of writing, no browser has support for this option.

const title = 'Sound Notification';

const options = {
  sound: '/demos/notification-examples/audio/notification-sound.mp3',
};

registration.showNotification(title, options);

Timestamp #

Timestamp allows you to tell the platform the time when an event occurred that resulted in the push notification being sent.

The timestamp should be the number of milliseconds since 00:00:00 UTC, which is 1 January 1970 (which is the UNIX epoch).

const title = 'Timestamp Notification';

const options = {
  body: 'Timestamp is set to "01 Jan 2000 00:00:00".',
  timestamp: Date.parse('01 Jan 2000 00:00:00'),
};

registration.showNotification(title, options);

UX Best Practices #

The biggest UX failure I've seen with notifications is a lack of specificity in the information displayed by a notification.

You should consider why you sent the push message in the first place and make sure all of the notification options are used to help users understand why they are reading that notification.

To be honest, it's easy to see examples and think "I'll never make that mistake". But it's easier to fall into that trap than you might think.

Some common pitfalls to avoid:

Don't put your website in the title or the body. Browsers include your domain in the notification so don't duplicate it.
Use all the information that you have available. If you send a push message because someone sent a message to a user, rather than using a title of 'New Message' and body of 'Click here to read it.' use a title of 'John just sent a new message' and set the body of the notification to part of the message.

Browsers and feature detection #

At the time of writing, there is a pretty big disparity between Chrome and Firefox in terms of feature support for notifications.

Luckily, you can detect support for notification features by looking at the window.Notification prototype.

Let's say we wanted to know if a notification supports action buttons, we'd do the following:

if ('actions' in window.Notification?.prototype) {
  // Action buttons are supported.
} else {
  // Action buttons are NOT supported.
}

With this, we could change the notification we display to our users.

With the other options, just do the same as above, replacing 'actions' with the desired parameter name.

Where to go next #

Web Push Notification Overview
How Push Works
Subscribing a User
Permission UX
Sending Messages with Web Push Libraries
Web Push Protocol
Handling Push Events
Displaying a Notification
Notification Behavior
Common Notification Patterns
Push Notifications FAQ
Common Issues and Reporting Bugs

Code labs #

Notification behavior

2016-06-30T00:00:00Z

So far, we've looked at the options that alter the visual appearance of a notification. There are also options that alter the behavior of notifications.

By default, calling showNotification() with just visual options will have the following behaviors:

Clicking on the notification does nothing.
Each new notification is shown one after the other. The browser will not collapse the notifications in any way.
The platform may play a sound or vibrate the user's device (depending on the platform).
On some platforms, the notification will disappear after a short period of time while others will show the notification unless the user interacts with it. (For example, compare your notifications on Android and Desktop.)

In this section, we are going to look at how we can alter these default behaviors using options alone. These are relatively easy to implement and take advantage of.

Notification Click Event #

When a user clicks on a notification, the default behavior is for nothing to happen. It doesn't even close or remove the notification.

The common practice for a notification click is for it to close and perform some other logic (i.e. open a window or make some API call to the application).

To achieve this, you need to add a 'notificationclick' event listener to our service worker. This will be called whenever a notification is clicked.

self.addEventListener('notificationclick', (event) => {
  const clickedNotification = event.notification;
  clickedNotification.close();

  // Do something as the result of the notification click
  const promiseChain = doSomething();
  event.waitUntil(promiseChain);
});

As you can see in this example, the notification that was clicked can be accessed as event.notification. From this, you can access the notification's properties and methods. In this case, you call its close() method and perform additional work.

Actions #

Actions allow you to create another level of interaction with your users over just clicking the notification.

Buttons #

In the previous section, you saw how to define action buttons when calling showNotification():

const title = 'Actions Notification';

const options = {
  actions: [
    {
      action: 'coffee-action',
      title: 'Coffee',
      type: 'button',
      icon: '/images/demos/action-1-128x128.png',
    },
    {
      action: 'doughnut-action',
      type: 'button',
      title: 'Doughnut',
      icon: '/images/demos/action-2-128x128.png',
    },
    {
      action: 'gramophone-action',
      type: 'button',
      title: 'Gramophone',
      icon: '/images/demos/action-3-128x128.png',
    },
    {
      action: 'atom-action',
      type: 'button',
      title: 'Atom',
      icon: '/images/demos/action-4-128x128.png',
    },
  ],
};

registration.showNotification(title, options);

If the user clicks an action button, check the event.action value in the noticationclick event to tell which action button was clicked.

event.action will contain the action value set in the options. In the example above the event.action values would be one of the following: 'coffee-action', 'doughnut-action', 'gramophone-action' or 'atom-action'.

With this we would detect notification clicks or action clicks like so:

self.addEventListener('notificationclick', (event) => {
  if (!event.action) {
    // Was a normal notification click
    console.log('Notification Click.');
    return;
  }

  switch (event.action) {
    case 'coffee-action':
      console.log("User ❤️️'s coffee.");
      break;
    case 'doughnut-action':
      console.log("User ❤️️'s doughnuts.");
      break;
    case 'gramophone-action':
      console.log("User ❤️️'s music.");
      break;
    case 'atom-action':
      console.log("User ❤️️'s science.");
      break;
    default:
      console.log(`Unknown action clicked: '${event.action}'`);
      break;
  }
});

Inline Replies #

Also, in the previous section, you saw how to add an inline reply to the notification:

const title = 'Poll';

const options = {
  body: 'Do you like this photo?',
  image: '/images/demos/cat-image.jpg',
  icon: '/images/demos/icon-512x512.png',
  badge: '/images/demos/badge-128x128.png',
  actions: [
    {
      action: 'yes',
      type: 'button',
      title: '👍 Yes',
    },
    {
      action: 'no',
      type: 'text',
      title: '👎 No (explain why)',
      placeholder: 'Type your explanation here',
    },
  ],
};

registration.showNotification(title, options);

event.reply will contain the value typed by the user in the input field:

self.addEventListener('notificationclick', (event) => {
  const reply = event.reply;

  // Do something with the user's reply
  const promiseChain = doSomething(reply);
  event.waitUntil(promiseChain);
});

Tag #

The tag option is essentially a string ID that "groups" notifications together, providing an easy way to determine how multiple notifications are displayed to the user. This is easiest to explain with an example.

Let's display a notification and give it a tag, of 'message-group-1'. We'd display the notification with this code:

const title = 'Notification 1 of 3';

const options = {
  body: "With 'tag' of 'message-group-1'",
  tag: 'message-group-1',
};

registration.showNotification(title, options);

Which will show our first notification.

Let's display a second notification with a new tag of 'message-group-2', like so:

const title = 'Notification 2 of 3';

const options = {
  body: "With 'tag' of 'message-group-2'",
  tag: 'message-group-2',
};

registration.showNotification(title, options);

This will display a second notification to the user.

Now let's show a third notification but re-use the first tag of 'message-group-1'. Doing this will close the first notification and replace it with our new notification.

const title = 'Notification 3 of 3';

const options = {
  body: "With 'tag' of 'message-group-1'",
  tag: 'message-group-1',
};

registration.showNotification(title, options);

Now we have two notifications even though showNotification() was called three times.

The tag option is simply a way of grouping messages so that any old notifications that are currently displayed will be closed if they have the same tag as a new notification.

A subtlety to using tag is that when it replaces a notification, it will do so without a sound or vibration.

This is where the renotify option comes in.

Renotify #

This largely applies to mobile devices at the time of writing. Setting this option makes new notifications vibrate and play a system sound.

There are scenarios where you might want a replacing notification to notify the user rather than silently update. Chat applications are a good example. In this case, you should set tag and renotify to true.

const title = 'Notification 2 of 2';

const options = {
  tag: 'renotify',
  renotify: true,
};

registration.showNotification(title, options);

Silent #

This option allows you to show a new notification but prevents the default behavior of vibration, sound and turning on the device's display.

This is ideal if your notifications don't require immediate attention from the user.

const title = 'Silent Notification';

const options = {
  silent: true,
};

registration.showNotification(title, options);

Note: If you define both silent and renotify, silent will take precedence.

Requires interaction #

Chrome on desktop will show notifications for a set time period before hiding them. Chrome on Android doesn't have this behavior. Notifications are displayed until the user interacts with them.

To force a notification to stay visible until the user interacts with it, add the requireInteraction option. This will show the notification until the user dismisses or clicks your notification.

const title = 'Require Interaction Notification';

const options = {
  requireInteraction: true,
};

registration.showNotification(title, options);

Use this option with consideration. Showing a notification and forcing the user to stop what they are doing to dismiss your notification can be frustrating.

In the next section, we are going to look at some of the common patterns used on the web for managing notifications and performing actions such as opening pages when a notification is clicked.

Alexey Rodionov on web.dev

PWAs on Oculus Quest 2

The Oculus Quest 2 #

The Oculus Browser #

User agent #

User interface #

Refresh rate and device pixel ratio #

PWAs in Oculus Browser and the Oculus Store #

State sharing #

PWA window sizes #

Interacting with PWAs #

Permissions for PWAs #

Debugging PWAs via Chrome DevTools #

App discovery #

Exemplary PWAs on the Oculus Quest 2 #

PWAs by Meta #

PWAs by other developers #

Creating PWAs for Oculus #

Web App Manifest requirements #

Packaging PWAs with Bubblewrap CLI #

Packaging PWAs with Oculus Platform Utility #

Packaging PWAs with PWABuilder #

Installing PWAs with ADB #

App submission #

Testing multi-tab apps #

An Oculus version of SVGcode #

Immersive 3D WebXR PWAs #

Hand tracking #

Augmented/Mixed Reality (Passthrough) #

Conclusions #

Acknowledgements #

Displaying a Notification

Visual Options #

Title and body options #

Icon #

Badge #

Image #

Actions (Buttons) #

Actions (Inline Replies) #

Direction #

Vibrate #

Sound #

Timestamp #

UX Best Practices #

Browsers and feature detection #

Where to go next #

Code labs #

Notification behavior

Notification Click Event #

Actions #

Buttons #

Inline Replies #

Tag #

Renotify #

Silent #

Requires interaction #

Where to go next #

Code labs #