Welcome to OpenFin Docs

Explore our guides, resources and references for building with OpenFin

Get Started

Testing and debugging

OpenFin provides application providers with the tools needed to support their application development. These features range from the Chrome Developer Tools to API calls for collecting raw data about an end-user’s machine.

Debugging your app

The Chrome DevTools is available for easy and efficient debugging. There are two ways to access these tools via your OpenFin app:

Launch via Google Chrome browser

  1. Launch the Google Chrome browser.
  2. Enter the following URL: http://localhost:9090
    You’ll see a list of the running web pages.
  3. Select the page you’d like to debug.

Launch via your app

Set the contextMenu option to true in your app manifest file as follows:

"startup_app": {
    …
    "contextMenu": true
}

With this enabled, you’ll be able to right-click on your app and select Inspect Element to open the Chrome DevTools.

🚧

REMINDER

Remember to set contextMenu: false or remove the setting before deploying to your Production environment.

Debugging a render or browser crash

Although rare, renderer or browser crashes may occur within your OpenFin environment. In case this happens, OpenFin has tools to provide application providers to collect the necessary information or logs to diagnose the cause. In our experience, the leading contributors to a renderer crash are application memory leaks or anti-virus software killing a process.

Sample Renderer Crash Message

📘

NOTE

In the OpenFin environment, the renderer process is where application code runs.

Diagnostics mode

Diagnostics mode provides application providers (and end-users) an opportunity to recreate a runtime renderer or browser crash within your application and generate crash logs. The feature is opt-in, can be configured in your application manifest or triggered from a command line.

Add --diagnostics as the value of the argument option in your application manifest, under the runtime object.

"runtime": {
    "arguments": "--diagnostics"
    },

When this setting is enabled, end-users can re-launch your application in this mode and attempt to recreate the crash. When your application runs in diagnostics mode, the OpenFin Runtime supports the following:

  • Verbose logging defaults to enabled ( --v=1).
  • Crash Reporting Tool is enabled.
  • --no-sandbox is enabled (required for Crash Reporter to properly work).
  • Crash and debug logs are delivered on Runtime crash or application close.

If a renderer or browser process crashes with diagnostics enabled, a .dmp file is generated and stored on the end-user's file system in %temp%/OpenFin Crashes/FILENAME.dmp. The OpenFin Runtime delivers this .dmp file and the debug.log file to OpenFin's CDN.

📘

NOTE

Crash logs can be extremely large, require keys to read the .dmp file and can only be delivered to OpenFin. OpenFin will receive the files if the end-user's machine can reach OpenFin's CDN.

Diagnostics can also be manually triggered by adding --diagnostics to the command line for the application's shortcut target.

C:\Users\username\AppData\Local\OpenFin\OpenFinRVM.exe --config="https://YOURAPPSERVER.COM/app.json" --runtime-arguments="--diagnostics"

❗️

DO NOT LEAVE ENABLED IN PRODUCTION ENVIRONMENT

If left enabled for an extending period of time, the files in the end-user's temp folder will become extremely large and may impact performance over time. OpenFin recommends immediately removing diagnostics flag after recreating the crash.

Crash Reporting tool

An alternative approach to diagnostics mode is to enable the Crash Reporting Tool. The benefit of this approach is that there are multiple ways to enable the Crash Reporting Tool, including programmatically. The feature is opt-in, and can be configured in your application manifest or triggered by the System.startCrashReporter method.

Add --enable-crash-reporting --no-sandbox arguments to your application manifest.

"runtime": {
    "arguments": "--enable-crash-reporting --no-sandbox"
    },

As with the diagnostics mode, if a renderer or browser process crashes with diagnostics enabled, a .dmp file is generated and stored on the end-user's machine in %temp%/OpenFin Crashes/FILENAME.dmp. The OpenFin Runtime delivers this file and the debug.log file to OpenFin's CDN.

If you choose to leverage the System.startCrashReporter method in your application, it is important to note two points:

  • OpenFin recommends coupling Verbose logging (v=1) programmatically via the System.setMinLogLevel method. This ensures the debug.log file also captures useful logging in the event a true crash does not occur.
  • In contrast to the other approaches, this approach does not set the --no-sandbox argument. so the Runtime might have less success in automatically delivering the files to OpenFin. Files are stored on the end-user's file system in %temp%/OpenFin Crashes/FILENAME.dmp.

❗️

DO NOT LEAVE ENABLED IN PRODUCTION ENVIRONMENT

As with diagnostics mode, OpenFin recommends immediately removing diagnostics flag after recreating the crash. When programmatically enabling this option, remind end-users to restart the application to exit this mode.

Memory profiling

Through Chrome DevTools, Chromium offers a comprehensive set of tools to profile your application. This tutorial is a good resource for application developers.

🚧

Renderer Crashes

Memory leaks are a primary cause of renderer crashes.

Verbose logging

OpenFin provides two levels of logging:

  • Basic: By default, this mode is always on. It is recommended for production environments.
  • Verbose: This mode must be turned on via an argument (--v=1) in the app manifest or programmatically with System.setMinLogLevel. It is recommended for development purposes or isolated production issues.
"runtime": {
    "arguments": "--v=1"
    },

❗️

Verbose logging in production environments

Please note that the Verbose logging setting --v=1 is a runtime switch, which enables Chromium verbosity logging and subsequently increases the volume of messages written to the log. When used in a production environment, this setting can result in excessive log sizes on the local system.

OpenFin recommends using this setting in a production environment only for isolated situations where debugging a production issue is required. Remember to turn verbosity off when debugging is completed.

Best Practice

To limit the log file sizes, you can enable verbose logging through the System.setMinLogLevel method.
fin.System.setMinLogLevel("verbose");

This programatic approach is well-suited for diagnosing issues in a production environment. Applications can provide this setting embedded in their applications preferences where an end-user can enable the logging while trying to replicate the issue. This same setting can then be switched off by the user in the same location it was enabled, restarting the application or programmatically 'Schedule a Restart', and close the running Runtime:

Application.scheduleRestart();
System.exit();

Log-related APIs

OpenFin offers several methods that you can use directly for your support needs. More details on these calls can be found in fin.System.

OpenFin recommends logging information on a regular basis from the client back to your server or database, as well as active metric gathering when an error or other issue occurs in your application.

Some critical methods in System include the following:

Testing Examples

Have questions? Get in touch with us at [email protected].

Updated 8 days ago


Testing and debugging


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.