Improve Dev Container Web App Visualization

[ruffsl]

This improves the ergonomics of Web App Visualization for Dev Containers, particularly those running from Codespaces, by consolidating the serving of HTTP traffic over a single network port. This simplifies the user experience when traversing the apps themselves, but also facilitates cookie-based authentication when using the secure and private by default port forward settings in Codespaces. This is achieved by using reverse proxies to reroute websocket traffic for each web app to their respective backend bridge interface. This PR also includes a number of other improvements, including a simple landing page for users to open and auto connect each web app from a web browser.

[ruffsl]

To continue my dev blog, I'll document my progress and findings here, as this was a doozy of a rabbit hole. After final preparations and getting PR #3523 merged, I was disappointed to discover that while the web visualizations where working from local dev containers, enabling it's use from Codespaces in the web browser was not as straight forward as I had hoped.

Straight off the bat, when using default settings for automatic port forwarding from Codespaces, in the web browser, Gzweb would not load a rendered web frontend from the forwarded port, connected to the npm start process, but instead would curiously return it's own index.html in plain text format. While the Foxglove Studio frontend, self hosted by caddy file_server, would successfully load, it still couldn't' connect to the websocket backend, using the forwarded port to the ROS foxglove_bridge node, despite ensuring the websocket scheme was set to use secure transport via wss://, given the frontend itself was also hosted using https://.

Codespaces Port Forwarding

Digging further into Codespaces' port forwarding, the documentation notably differs when using Web browsers. Given the ports are forwarded to the public internet, they are then kept private by default through a remote domain via an authentication method that requires the use of a GITHUB_TOKEN access token. This token is automatically created when starting a Codespace session, an must be included in the http request header in order to authenticate past GitHub's https reverse proxy for the remote domain.

• https://docs.github.com/en/codespaces/developing-in-codespaces/forwarding-ports-in-your-codespace#using-command-line-tools-and-rest-clients-to-access-ports

While this port forwarding is private by default, it can be change to public to disable this token based access control. Although doing so for the port served by the foxglove_bridge websocket backend would allow the Foxglove Studio frontend to connect, it's not ideal. As it would require additional steps to manually configure the port forwarding settings, as well as additional documentation and instruction to inform the end user, should such forwarding settings fall out of sync with the project. While this configuration could be automated via the gh CLI, as a robotics and security researcher, any public port forwarding rubs me the wrong way regardless of how well it could be automated.

Websocket Headers

My first approach to enable visualizations using Codespaces from the web browser, without having to deviate from the default private port forwarding settings, was to modify the websocket request headers to directly include the GITHUB_TOKEN access token for authentication. So I looked into what it would take to modify the Foxglove Studio frontend to provide the user the means to specify custom headers to include in the websocket connection request.

• Support for user defined custom Http headers
  • Support for user defined custom Http headers foxglove/studio#5896

Oddly enough, or at least a little meta, developing this PR was made rather simple with the addition of the dev container template for javascript and node development, which included all the linters, inline docs, and auto-completion, allowing me to jump straight into the code and watch my changes live, without having to putz around with setting up typescript and npm environments from scratch.

• Node.js & TypeScript
  • https://github.com/devcontainers/images/tree/main/src/typescript-node
• Node.js & JavaScript
  • https://github.com/devcontainers/images/tree/main/src/javascript-node
• Node.js & Typescript Development Container Images
  • https://mcr.microsoft.com/en-us/product/devcontainers/typescript-node/about

However, upon reaching the call sight for the creation of the websocket, there were no programmatic means to include custom HTTP headers into the connection upgrade request. After further investigation, it seems that this is a limitation inherent to the web standard, despite developer feedback.

• MDN Web Docs: WebSocket: WebSocket() constructor
  • https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/WebSocket
• HTTP headers in Websockets client API? Nope!
  • https://stackoverflow.com/a/4361358/2577586
• Whatwg Issue: Support for custom headers for handshake
  • Support for custom headers for handshake  whatwg/websockets#16

While some libraries do support this, it would require patching Foxglove's fork of the rosbridge client API, and no longer reuse the standard WebSocket API, supported by most Javascript runtimes and major web browsers. Thus, a bit of a show stopper.

• Alternative: ws - a Node.js WebSocket library
  • https://www.npmjs.com/package/ws
  • https://github.com/search?type=code&auto_enroll=true&q=%2Fnew+WebSocket%5C%28.*header%2F+language%3ATypeScript&l=TypeScript
• Alternative: Bun - fast all-in-one JavaScript runtime
  • https://bun.sh/blog/bun-v0.5.0#custom-headers-in-websocket
• Foxglove's fork: roslibjs - ROS JavaScript API
  • https://github.com/foxglove/roslibjs

Another issue with this whole approach is that it doesn't avoid Cross Origin Resource Sharing (CORS) issues, or the foreboding "Mixed Content" popup warnings that some browsers could report when users inevitably misconfigure the websocket address, or when trying to mix resources from different domains. Given the Foxglove Studio frontend was then hosted from a different port than the rosbridge websocket backend, thus a different remote domain, this could lead to other issues if CORS enforcement from browsers are ever tightened.

• Chrome Websockets CORS policy
  • https://stackoverflow.com/questions/22644392/chrome-websockets-cors-policy

Reverse Proxies

While the use of custom headers turned out to be a nonviable solution, I figured I'd try and get the Gzweb frontend to at least load in the browser, given it wasn't even rendering the page as HTML at all. After looking into how npm was serving the static files, I figured the ancient version of Node 16 that Gzweb (classic) targeted was either flaking out from the use of IPv6 addresses for the Codespaces remote domain, or choking from the indirection of GitHub's external https reverse proxy. Given that Caddy was already being used, and working, to serve the Foxglove Studio frontend, it seemed like a good idea to try and use it to serve the Gzweb frontend as well. Lo and behold, it worked! The Gzweb front end was now rendering in the browser over the remote domain: even fixing some UI bugs, e.g. folding menu toggles, that were previously not working when hosted with npm.

• Caddy: File Server
  • https://caddyserver.com/docs/command-line#caddy-file-server

However, that still didn't resolve Gzweb's websocket connection issues, given the HTTP file server and websocket backend for Gzweb where now hosted across separate ports. Unlike Foxglove Studio, Gzweb (classic) does not provide the user the means to specify the backend address to connect to, and instead points back to the same URL that served the frontend, so it was time to look into reverse proxies. After a bit of digging, I found that Caddy also supports reverse proxies, and so switched to a more advance Cadddyfile configuration, leveraging multiple file_server and reverse_proxy directives, to forward the websocket connection requests appropriately.

• Caddy V2 how to proxy websoket (v2ray websocket + tls)
  • https://caddy.community/t/caddy-v2-how-to-proxy-websoket-v2ray-websocket-tls/7040
• Caddy Docs: Named matchers
  • https://caddyserver.com/docs/caddyfile/matchers#named-matchers

While this configuration of reverse proxies worked locally, allowing Gzweb to be hosted and proxy'ed via Caddy, the same could not be said when using Codespaces from the browser. Oddly enough, after comparing the logs from the remote and local dev containers, I discovered that GitHub's own reverse proxy was modifying the capitalization of the request headers, thus evading more basic reverse proxy matchers for catching websocket connection upgrade requests. So I also had to modify the caddy configuration to use regex matching instead. E.g:

{
    "request": {
      ...
      "headers": {
        ...
 -       "Connection": ["Upgrade"],
 +       "Connection": ["upgrade"],
        "Upgrade": ["websocket"],
        ...
      }
    },
    ...
  }

-		header Connection Upgrade
+		header_regexp Connection (?i)(Upgrade)

• Caddy Docs: Standard matchers - header_regexp
  • https://caddyserver.com/docs/caddyfile/matchers#header-regexp

This finally allowed the Gzweb frontend to load and connect to the remote websocket backend running in Codespaces, where I was able to confirm the undocumented fact that cookie based authentication could also be used to route the websocket connection upgrade request through GitHub's https reverse proxy, as long as an existing authenticated HTTP session to the same remote domain could be reused. Given that users must be logged into GitHub in the first place to use Codespaces, and view any privately forwarded http ports from the browser, this seemed like a reasonable assumption to make. This also resolved any possible CORS issues, and mixed content warnings, as any upgrade requests were now routed to the same remote domain as the frontend, and no longer considered cross origin.

Next, I sought to replicate this reverse proxy approach for Foxglove. While this mostly solved the previous issue, the resulting success of websocket connections where flaky and intermittent. I'd often lose track of which backend I was attempting to connect to, be it a local dev container, or a remote Codespace, and would subsequently mistype the wrong websocket scheme into the URL to account for possible https reverse proxies. To try and rule out user URL typos, I'd copy and paste from the browser URL bar, or "Copy local address" button from the ports view in VS Code, to correctly capture the long autogenerated remote domain. A subtle issue that emerged however is that: depending upon where a user copied the remote domain from, the inclusion of the trailing slash / would likely vary and remain inconsistent.

These types of redirects would normally be handled by the file_server directive in Caddy, forgivingly adding or removing trailing slashes to requests internally as appropriate. However, given that the reverse_proxy directive was being used to forward websocket connection upgrade requests, this must be explicitly handled instead. I ended up choosing to use internal rewrites for the websocket paths, to avoid asking the remote browser to re-issue the request, as not all websocket clients gracefully handle 308 Permanent Redirect responses.

• Caddy Docs: Trailing slashes
  • https://caddyserver.com/docs/caddyfile/patterns#trailing-slashes
• Caddy Docs: redir
  • https://caddyserver.com/docs/caddyfile/directives/redir
• Caddy Docs: rewrite
  • https://caddyserver.com/docs/caddyfile/directives/rewrite

Landing Page

While typing websocket addresses for Foxglove was now a little more forgiving, with respect to trailing slashes, the task of entering the correct domain and websocket scheme still added a lot of friction to the user experience, being quite error prone; particularly when frequently restarting backends for live development. To streamline the web app experience, I decided to add a landing page to the root of the remote domain to include shortcut hyperlinks for each web app. Using the templates directive, we can render static markdown files into html pages hosted by the file_server.

• Caddy Docs: Templates
  • https://caddyserver.com/docs/caddyfile/directives/templates

However, this directive needs to be scoped to the respective markdown templates to avoid blowing away the index.html files from the nested web apps, breaking them entirely. This can be done simply enough by adding a path and file matcher to the templates directive. This also provides a simple and clean markdown file to self document the web app resources, or to include debugging information to check the status of the connection.

To streamline the startup of Foxglove Studio in particular, we can hyperlink to a URL that Caddy can then redirect for auto connecting to the websocket backend upon initial page load. This is done by inspecting the initial request to the redirected path, notably the http scheme, requested host, and forwarded HTTP headers, then using that information to populate the URL query parameters, parsable by Foxglove, and embed them in the URL redirect.

A particular nuance for Codespaces, where the web server sits behind an existing https reverse proxy to start with, is that the X-Forwarded-Host and X-Forwarded-Scheme header values must also be checked to determine the correct URL from the client's perspective, e.g: when addressing a remote domain proxy using https, or addressing a local host port using http. Even when using Codespaces, ports could also be forwarded locally using the VS Code desktop or gh CLI, thus all combinations must be considered. These kind of conditionals can be constructed using boolean logic via multiple matcher sets and expressions:

• Caddy Docs: Standard matchers - expression
  • https://caddyserver.com/docs/caddyfile/matchers#expression

Future Work

As for future works, it might be nice to leverage unix sockets to proxy the websocket connections to web app backends when running from the same host machine, to try and reduce the load from serializing and deserializing the websocket messages over the local loopback network interface, as it would seem unix socket paths are supported addresses in Caddy.

• Caddy Docs: Network addresses
  • https://caddyserver.com/docs/conventions#network-addresses

Although, this would also need to be supported by the web app backends, such as Foxglove's websocket bridge for ROS, which in tern depends upon websocketpp, a C++ websocket library that no longer seems to be actively maintained, with experimental support for unix sockets still hanging in open pull requests.

• https://github.com/orgs/foxglove/discussions/703

It might also be nice to profile the performance of the Gzweb backend, given its resource usage remains rather high when actively connected to remote clients. From approximate observations, it seems that the high frequency at which messages from Gzserver are received at the bridge, rather than the rate of messages relayed through the bridge, would be the source of most CPU load, given this load does not change when using corse positional update settings. But this could also be due to relayed tick rate of the simulation's time step. Thus, rate limiting these messages from gzserver could help with CPU usage for gzweb bridge.

[ruffsl]

Loading Foxglove Layouts

Another friction point I encountered while self hosting Foxglove Studio was configuring the layout used to arrange Foxglove Studio panels into custom workspaces for Nav2. For example, it would be nice to replicate the same user experience as when launching Rviz via launch files, where the configuration file for Rviz can be programmatically specified and loaded automatically upon startup. Although Foxglove does provide a convenient service to share and manage layouts between users and team organizations, this inevitably requires logging into an account by accessing Foxglove's backend service. While layouts for Foxglove Studio can also be manually imported and exported using JSON via the web UI, this requires the user to upload JSON files using their browser and local filesystem. Such caveats render existing options non ideal in our use case, for either practical or technical reasons as discussed below, so we'll need an alternative solution.

Practical Issues

In terms of practicality, having to manually upload a JSON file every time we launch Foxglove Studio from a new Codespace would be rather tedious, not to mention error prone, as one could easily upload the wrong file, or an out-dated version of the layout. For instance, users would first have to acquire the appropriate Foxglove layout, out of band, for the respective version of Nav2, save it to their local filesystem, then navigate through the menu UI to upload the file to Foxglove Studio web app. Even such a simple process can be exacerbated when conducting courses with many young students, or providing workshop tutorials for novice users that easily get lost in new interfaces.

While the user's browser cache of the web app can be leveraged to retain recent layouts, avoiding the need to upload the layout json file every time the web app is revisited, this would only be applicable when the user uses the same browser, on the same machine, for the same self hosted domain. For instance, each time the user launches a new Codespace, the remote domain allocated to the Codespace is uniquely different, and thus the user would then have to reconfigure the layout again.

Technical Issues

With respect to technical limitations, given the user's browser or device, it may not even be possible for the user to upload the layout JSON file to begin with. Given Foxglove's current use of showOpenFilePicker(), a method of the Window interface to show a file picker, is only supported by Chromium based browsers, and only when those browsers are also running on desktop devices, this severely impairs the importation of custom layouts when using common classroom and student owned devices, such as Android tablets, iPads, or administrated computer terminals without Chromium installed, requiring the user to manually configure the layout from scratch from the web UI.

• MDN Docs: Window: showOpenFilePicker() method
  • https://developer.mozilla.org/en-US/docs/Web/API/Window/showOpenFilePicker

While distribution and synchronizing of layouts is perhaps best handled by Foxglove's own account based service, usable from either the Foxglove Studio's desktop app or official web app https://studio.foxglove.dev , given the constraints discussed previously above, such as token authentication for privately port forwarding or CORS policies enforced by browsers, we'll still need to handle and automate some of this locally. Recall that when using private port forwarding for Codespaces via the web, the use of custom headers to include the authentication token is not inherently supported in Foxglove Studio, nor the standard websocket client library API it builds upon. Additionally, when using Foxglove's official web UI, the cookies used to authenticate an HTTP session through GitHubs own internal reverse proxy would not be accessible, nor applicable, to the web app served from Foxglove's own remote domain.

• MDN Docs: Restrict access to cookies
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies

While the desktop or official web app for Foxglove would still otherwise be applicable when using locally forwarded ports, such as when using the VS Code desktop or gh CLI, the necessity of such local prerequisites would be counter to our goals in providing a pure web based development environment, not to mention the additional overhead of having to sign-up and enroll all attendees of a course or workshop into a third party service and team organization in order to import demo/version specific layouts.

Workaround

Rather than manually importing layouts from out-of-band sources, or configuring them from scratch directly from the web UI, we can automate the loading of local layouts using similar techniques as discussed previously for auto connecting to the websocket backend by leveraging the URL query parameters. Foxglove already provides a layoutId query parameter to specify the layout to use upon startup. All that is missing is a way to specify a path to import the layout from, rather than relying on the web UI to already have the layout cached in the browser. In fact, this is a common enough use case that such a feature is already being discussed in the Foxglove community:

• URL param to allow loading layout from a remote URL # 192
  • URL param to allow loading layout from a remote URL foxglove/community#192

However, as of writing, this feature is not yet supported natively in Foxglove Studio, and so accepting another side project, we'll just go ahead and implement this. The following PR adds support for a new layoutUrl query parameter to specify a URL to import a layout from. This URL can either be just a relative URI within the same domain, or a fully qualified URL to a remote domain. While the latter may likely be blocked by default CORS policies enforced by the browser, the former will still satisfy our use case nicely, as we can simply host any layout JSON files using the same Caddy web server hosting the Foxglove frontend.

• URL param to allow importing layout from a URL
  • URL param to allow importing layout from a URL foxglove/studio#5987

We can then serve different layouts for matching versions/branches of Nav2 by hosting the respective JSON files from the checked-out repo for Nav2 in the dev container workspace. This allows us to check-in the layout JSON files along with the rest of the Nav2 source code, and thus always automatically load the intended layout when launching Foxglove Studio from a Codespace. While this still may not be suitable for large scale workflows or rapidly evolving layouts, co-locating such config files with the project source code should be more than sufficient for our community development and educational use case.

Lastly, this has the added bonus of working either for offline settings, or with any browser and device that can at least load the web app UI, even if not fully compatible with Foxglove's use of experimental browser features. This is handy when developing locally on an air gapped network, or teaching within conference WiFi settings, where internet connectivity may be spotty at best, and absent at worst. Attendees or organizers could then simply build or cache these dev containers and reference materials beforehand, but then still automatically configure the lesson environment when launching demos on site.

[mergify]

@ruffsl, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).

[ruffsl]

Merging for integration testing and to rebuild repo's codespace.

[ruffsl]

Refactoring

After conducting further experimentation and closely studying Caddy's documentation, I concluded that some refactoring was necessary. My intention was to simplify the Caddyfile and make it more formulaic, resembling a template that others could easily extend. For example, they could add more apps, modify the static file locations, or even reuse it outside of development containers.

Furthermore, while testing on mobile devices, I found the user experience to be unsatisfactory. Specifically, I was not pleased with the consistency of each web app's behavior upon installation. For instance, while Foxglove could be opened in a full-screen window or standalone view on Android or iOS, other apps like Gzweb or the system monitor would only reopen using regular browser tabs. This inconsistency prompted me to seek ways to further enhance the overall experience.

Now, let's delve into how we can improve these issues.

Caddyfile

The prior Caddyfile configurations employed a basic declarative style, which was simple but had certain drawbacks. The reliance on a monolithic root and symlinks made the setup fragile, not easily extensible, and not very portable. Adding or extending hosted apps required synchronizing symlink changes to the root path. Moreover, using the same Caddyfile outside of a development container necessitated replicating these symlinks in other locations.

To address these issues, we can serve each app using its own configurable directory by leveraging user defined environment variables. This approach allows us to dynamically specify the root paths for each app during file server startup. To streamline the use of multiple root directives, we can utilize the handle_path directive. It enables us to remove the matching prefix from the request path, ensuring that requests for each app are handled within separate scopes. This scoping mechanism helps prevent conflicts with directives specific to each app, such as the templates directive, which previously required manual matching to avoid unintentionally overwriting index files.

This approach also enables us to adopt a more formulaic and DRY (Don't Repeat Yourself) approach with code snippets. Subsequent path matchers can now be left relative and reused between apps. However, there is a caveat when it comes to incorporating the rewrite directive. Previously, with a single file_server directive under a monolithic root, using the rewrite directive to gracefully reroute websocket connections when the trailing slash in the directory path was omitted was relatively simple. But now, with multiple handle_path directives used to match each app's root directory, achieving the same result becomes more complex.

Fortunately, the newly added redirect already automates any websocket setup by programmatically populating URL parameters used by Foxglove, avoiding the issue of typographical errors when addressing websocket URLs altogether.

Mobile View

When using web apps on smaller screen devices like student-owned tablets or school-issued Chromebooks, the app's display is crucial for enhancing usability. In most browsers, the URL bar and navigation buttons take up a significant portion of the vertical real estate, especially on modern screens with wider aspect ratios. While enabling the browser's full-screen mode can alleviate this issue, it can limit the use of multitasking features like multi-window or split-screen views, which are supported even on modest devices.

To address this, users have the option to install web apps as standalone apps. These apps can be launched from the home screen or app drawer, allowing them to run in their own resizable windows separate from the browser. While Foxglove can already be installed as a standalone web app natively, others may not have this capability. To enable this feature, we can add the following <meta> tags to the index.html page of each app:

<head>
  <meta name="apple-mobile-web-app-capable" content="yes">
  <meta name="mobile-web-app-capable" content="yes">
  ...

• Making Fullscreen Experiences
  • https://web.dev/fullscreen/

In fact, you can see this added to Foxglove here; which first clued me in on this feature:

• Hide Safari chrome when launched from Home screen on iOS # 4149
  • Hide Safari chrome when launched from Home screen on iOS foxglove/studio#4149

While we could of course open similar PRs towards every such project we incorporate into our web stack, that could turn our current rabbit whole into a never ending fractal of forks. To keep forking to a minimum, we can instead patch our single page web apps as we serve them using Caddy's replace_response module. This module allows us to inject arbitrary strings into the response body of each app given a matching pattern, allowing Gzweb, our system monitor, and even our simple landing page to be displayed as standalone apps as well.

• Caddy replace_response handler module
  • https://github.com/caddyserver/replace-response
• Module http.handlers.replace_response
  • https://caddyserver.com/docs/modules/http.handlers.replace_response

However, this module is not part of the standard Caddy build, although it is maintained by the official Caddy organization. To use it, we have two options: either build Caddy from source or utilize the xcaddy tool to create a custom Caddy binary that includes the module. It's worth noting that the xcaddy tool is not distributed through Caddy's official Debian repository. Initially, I was concerned that this would lead to a complex detour involving the setup of Golang and friends. However, to my delight, I discovered the preinstalled xcaddy docker image tag in Docker Hub's Official Library. This simplified the process of building and installing custom Caddy binaries, even when compared to using apt-get.

• Docker Hub: Caddy - Adding custom Caddy modules
  • https://hub.docker.com/_/caddy

Web App Manifest

While the aforementioned <meta> tags effectively enable the display of the app as a standalone web app on all browsers, the default startup behavior still lacks consistency across various platforms. For example, when installing Foxglove as a standalone app on desktop or Android devices, the app state and the complete URL are utilized for installation to the desktop or home screen. However, this is not the case on iOS devices, where only the URL path is utilized, resulting in the removal of any query parameters. Consequently, reopening the standalone web app of Foxglove on iOS does not automatically establish a connection, whereas reopening the web app from a bookmarked URL, the same URL that was used during the web app installation, does auto connect.

To address this issue, we can instead adopt a more contemporary and robust approach by leveraging the Web App Manifest standard to declare the apps as compatible with mobile views. This enables us to define the start URL that is utilized when the app is installed as a standalone application, giving us the ability to include a customized query parameter to ensure consistent launching behavior. To do this, we'll instead add the following <link> tag to the index.html page of each app:

<head>
  <link rel="manifest" href="manifest.json" />
  ...

• Web app manifests
  • https://developer.mozilla.org/en-US/docs/Web/Manifest
• Add a web app manifest
  • https://web.dev/add-manifest/

Then we'll configure the Caddy web server to add a redirect to the respective manifest file. Not only does this allow us to specify the start URL and display mode for each app, but also customize the default name of the app as it appears to the user. We can then again use server side templates to dynamically include the host and port information into the manifest file, clueing the user into what domain the web app is hosted from. This is particularly useful when switching between local dev container or remote Codespace environments, or when switching between Codespaces with different names and thus different port forwarded web domains.

{
    "name": "Foxglove: {{placeholder "http.request.hostport"}}",
    ...
    "start_url": "/foxglove/autoconnect",
    "display": "standalone",
    "shortcuts" : [
        {
          "name": "Auto Connect",
          "url": "/foxglove/autoconnect",
          "description": "Auto connect to default data source"
        },
        {
          "name": "Auto Layout",
          "url": "/foxglove/autolayout",
          "description": "Auto connect using default layout"
        },
        {
          "name": "Manual Connect",
          "url": "/foxglove/",
          "description": "Manually connect to data source"
        }
      ]
}

While we're at it, we can also incorporate shortcuts into the manifest file, enabling users to quickly select different startup options through various redirects. Instead of directly templating the complete Foxglove URL, including query parameters, into the server-side generated manifest, we'll just utilize more redirects. This approach avoids hardcoding the URLs into the installed web app, allowing us to centrally update these configurations from the server, while avoiding the need to update each individually installed web app on user devices.

Although, as of writing, shortcuts still seem to be an experimental feature:

• W3C: Web App Manifest - Shortcuts
  • https://w3c.github.io/manifest/#shortcuts-member
• MDN: Manifest - Shortcuts
  • https://developer.mozilla.org/en-US/docs/Web/Manifest/shortcuts

While experimenting with redirects, I discovered that Caddy offers a matcher directive to filter URL query parameters by matching specific value patterns. Although using query matching instead of path matching might be preferable in this case, especially when injecting custom redirects onto an existing web app frontend, I found paths to be more reliable in practice. This is because using paths exclusively for redirects ensures that the browser does not inadvertently cache outdated responses, as it could when requesting the root path of the Single Page Application (SPA). Short of overriding the app's own caching policy, we can side step such caching issues by matching on reserved redirect paths instead.

Another annoyance specific to iOS: the browser cache in Safari doesn't seem to be shared with standalone web apps. In the example manifest provided earlier, you can see that the start_url member is set to the autoconnect redirect instead of the autolayout redirect. This avoids the need to download duplicate nav2 layouts every time the standalone web app is launched and ensures that the same layout selected from the previous session is reused.

However, this also means that when iOS users first navigate to the Foxglove web app from Safari, using the autolayout redirect from the landing page, download the nav2 layout, and then install the web app: subsequent relaunches of the web app in standalone view will not include the cached nav2 layout. This deviates from the behavior of every other platform. Uhg, mobile web development in 2023... 🤦‍♂️

Miscellaneous

With respect to the dev container setup, we can incorporate a few additional miscellaneous improvements. These include leveraging more environment variables to avoid hardcoding container-side paths in config files and enhancing the available tasks in VS Code. As mentioned in previous dev container PRs, these tasks, which facilitate starting and stopping the runtime dependencies for web-based visualizations, are particularly useful when restarting simulations or managing ROS launch files. Given that Gzweb and Foxglove do not handle simulation restarts gracefully, such as when encountering connection drops to gzserver or non-causality of time when caching TF trees in Foxglove Studio, having a quick way to restart the entire simulation stack is beneficial.

Previously, the use of pkill was somewhat haphazard to enable tasks to stop other running tasks. While functional, a better approach is to command VS Code directly to terminate tasks. This can be achieved by utilizing input variable substitution to specify the labeled task to terminate. This eliminates the need for convoluted pattern matching based on process command strings, ensuring that the correct process is always terminated correctly.

To learn more about variable substitution and input variables in VS Code, you can refer to the following documentation:

• VS Code Docs: Variable substitution
  • https://code.visualstudio.com/docs/editor/tasks#_variable-substitution
• VS Code Docs: Input variables
  • https://code.visualstudio.com/docs/editor/variables-reference#_input-variables

Additionally, this cleanup effort resolves issues related to the list of tasks displayed under the terminal panel in VS Code. Previously, terminated task terminals would persist, or reused terminals would exhibit inconsistent icons and names. Now, terminated tasks are removed from the display, providing clearer visibility to students regarding running and inactive processes. This helps avoid confusion and issues like the one mentioned in the following example:

• Task icon for terminal tab entry does not update with task label when terminal is reused
  • Task icon for terminal tab entry does not update with task label when terminal is reused microsoft/vscode#179337

Lastly, there was an issue where xvfb-run and gzserver were occasionally orphaned by ROS launch when restarting simulations. This resulted in subsequent relaunches failing due to display server errors or port usage conflicts, which could be perplexing for younger students. By properly using exec in the wrapper bash script for the headless version of gzserver, hanging child processes now receive escalated SIGKILL signals. This is a known issue, as Gazebo classic often requires such measures.

• gzserver not dying after killing the simulation # 751
  • gzserver not dying after killing the simulation ros-simulation/gazebo_ros_pkgs#751