Bug reporting

There are a couple bug trackers relevant to WebRTC:

• crbug.com -- for Chrome¹.
• bugreporter.apple.com -- for Safari
• developer.microsoft.com -- for Edge
• bugzilla.mozilla.org -- for Firefox.
• bugs.opera.com/wizard -- for Opera.
• bugs.webrtc.org -- for WebRTC native code.

and they’re continuously triaged by Chrome and WebRTC engineers.

How to File a Good Bug Report

Instructions

• Identify which bug tracker to use:
  • If you’re hitting a problem in Chrome, file the bug using the Blink>WebRTC component. This can be done after choosing “I am a web developer trying to build something” and “Problems with a browser API” and ensures the right people will look at your bug.
  • If you’re a developer working with the native code, file the bug at this link.
• Include as much as possible from the data points listed below.

Example Data Points

• Version of the browser/app
  • For Chrome: copy/paste from chrome://version
  • For WebRTC native code: if applicable, include the branch (e.g. trunk) and WebRTC revision (e.g. r8207) your application uses
• Operating system (Windows, Mac, Linux, Android, iOS, etc.) and version (e.g. Windows 7, OS X 10.9, Ubuntu 14, etc.)
• Hardware platform/device model (e.g. PC, Mac, Samsung 4S, Nexus 7, iPhone 5S, iPad Air 2 etc)
• Camera and microphone model and version (if applicable)
  • For Chrome audio and video device issues, please run the tests at https://test.webrtc.org. After the tests finish running, click the bug icon at the top, download the report, and attach the report to the issue tracker.
• Web site URL
• Reproduction steps: detailed information on how to reproduce the bug. If applicable, please either attach or link to a minimal test page in HTML+JavaScript.
• For crashes
  • If you experience a crash while using Chrome, please include a crash ID by following these instructions.
  • If you experience a crash while using WebRTC native code, please include the full stacktrace.
• For functional issues or ICE issues, in either Chrome or a native application, please gather a native log.
• For connectivity issues on Chrome, ensure chrome://webrtc-internals is open in another tab before starting the call and while the call is in progress,
  • expand the Create Dump section,
  • click the Download the PeerConnection updates and stats data button. You will be prompted to save the dump to your local machine. Please attach that dump to the bug report.
• For audio quality issues on Chrome, while the call is in progress,
  • please open chrome://webrtc-internals in another tab,
  • expand the Create Dump section,
  • fill in the Enable diagnostic audio recordings checkbox. You will be prompted to save the recording to your local machine. After ending the call, attach the recording to the bug.
• For echo issues, please try to capture an audio recording from the side that is generating the echo, not the side that hears the echo. For example, if UserA and UserB are in a call, and UserA hears herself speak, please obtain an audio recording from UserB.

Filing a security bug

The WebRTC team takes security very seriously. If you find a vulnerability in WebRTC, please file a Chromium security bug, even if the bug only affects native WebRTC code and not Chromium.

A history of fixed Chromium security bugs is best found via security notes in Stable Channel updates on the Google Chrome releases blog.

You can also find fixed, publicly visible Type=Bug-Security bugs in the Chromium issue tracker. Old, native-only, security bugs may also be found in the WebRTC issue tracker , though new security bugs should not be filed there (security bugs normally become publicly visible 14 weeks after they are fixed).

Note that we will generally NOT merge security fixes backwards to any branches, so if you’re using older branches it’s your responsibility to make sure the relevant security fixes get merged. In general, users are strongly encouraged to stay up-to-date with WebRTC's main branch.

Receiving notifications about security bugs in Chrome/WebRTC

To get automatic notifications about activity/comments in security bugs in WebRTC/Chrome, you generally need to be explicitly cc:d on specific bugs (by someone who has access to the bug).

Under some conditions, you can get access to (fixed, but yet) unreleased vulnerabilities in WebRTC. Specifically, you need to:

• be working on a product (based on WebRTC) that has substantial real-world usage
• keep your product generally up-to-date with WebRTC tip-of-tree,
• have a work role that includes applying WebRTC security patches to your product
• and, most importantly, commit to keeping the bugs strictly confidential and only share details with trusted individuals within your organisation on need-to-know basis.

If you meet the criteria, you can send a request to security@webrtc.org, including an explanation and a justification for your need for access.

Note that not all bugs with crashes, memory leaks, etc. are marked as Bug-Security. You can read more about what categories of bugs are considered security bugs in the Severity Guidelines for Security Issues and also on the Security FAQ page.