The Chromebook Help Community is an active, searchable community for user discussion of bugs and feature requests. It‘s a great place to ask for help, and there’s a good chance that your question has already been asked (and answered, hopefully).
Feedback reports are the primary mechanism by which ChromeOS users can send feedback about the project. Reports are clustered into categories that are used to identify larger issues, but they are typically not individually reviewed. Submitted reports are not publicly accessible.
To submit a feedback report, type Alt+Shift+i or click
Report an issue... within the
Help submenu while logged in. Feedback reports include selected system logs if the
Send system and app information, and metrics checkbox is checked. You can click the links within the checkbox text to see the information that will be attached to the report. See the official feedback documentation for more information.
The Chromium project's public trackers are used to track ChromeOS bugs and feature requests.
If you have a bug or feature request which is related to the ChromeOS operating system itself and not the user interface or browser, please proceed to the instructions on filing bugs in ChromeOS in the ChromeOS Issue Tracker.
If you have a bug or feature request which is related to the user interface or browser, please file it using the Chromium project's public issue tracker. new.crbug.com or crbug.com/new are interchangeable handy shortcuts that can be used to start a new issue in this public tracker. Issues are publicly-viewable by default, but the
Restrict-View-Google label restricts the issue to Google employees. go/newcrosbug (internal link) may be used to start a new issue with this label.
New issues submitted to these trackers are periodically triaged to receive correct component assignments, at which point they should be examined by component owners. If you are a Chromium project member or a member of ChromeOS, you can assign components and other labels/hotlists yourself to expedite this process.
If you want to report a security bug, please follow Reporting Security Bugs.
That covers how to securely and privately report issues to the right group. Please do not use the default crbug.com/new system as that creates public bugs which anyone can view.
Note that while the Chrome browser does not consider physically-local attacks to be inside its threat model, ChromeOS does include certain physically-local attacks in its threat model. The reason for this difference is that while the Chrome browser does not control the operating system it runs on, on ChromeOS we are responsible for the entire system. This means that ChromeOS does need to protect against certain physically-local attackers, such as at the lock screen. See the ChromeOS Security Severity Guidelines for details.
Also note that we do not handle account compromises with your Google account (e.g. someone stole your Gmail password). Please see the Google Account Help document and related articles instead.
It is also possible to collect more extensive system logs beyond what is included in feedback reports. Frequently this is not necessary, so check with a developer first.
Include the system_logs.txt fileis checked by default, we encourage including that because many tools can parse that format. (It is the same file that gets sent to feedback reports).
Include a policies.json fileif policy information is relevant (and see PII notes below).
Include all log files collected by debugdto include additional logs as a separate archive.
Include Chrome logsif the complete Chrome log file is needed. A truncated log will be included in system_logs.txt.
All files will be saved to the Downloads folder.
If logs with PII (personally identifiable information) are included, you may want to do one or more of the following:
Screenshots are extremely helpful when debugging UI-related issues. To capture a screenshot on a ChromeOS device, hold Ctrl and hit the Switch Window (a.k.a.
[ ]]]) key (or F5 if you‘re using a non-ChromeOS keyboard). The screenshot will be written to your Downloads folder if you’re logged in or to
/tmp (which can be accessed by browsing to
file:///tmp after logging in) if captured at the login screen. To take a screenshot of a limited region of the screen, use Ctrl+Shift+Switch Window and drag a rectangle using the touchpad.
When the Chrome process, some other system process, or the Linux kernel crashes, a crash report will be generated and sent if the
Automatically send diagnostic and usage data to Google setting is enabled. When this happens, you should later be able to see information about the report at
If you give the ID to a ChromeOS developer, they can look up more details about the report that will hopefully help them determine the crash's cause.
If the entire UI (including the cursor) freezes or hangs, it can indicate various problems, including:
If you see a freeze, try pressing Alt+Volume Up+X once, with the keys depressed in that order. (If you're using a non-ChromeOS keyboard, use Alt+F10+X instead.) This will instruct the Linux kernel to attempt to make the Chrome process crash and restart.
If that doesn't help, try pressing the three-key-combination two more times. This should trigger a kernel panic, resulting in the system rebooting.
If the system is still frozen, you've probably encountered a lower-level issue. Holding the power button for eight seconds should force a reboot.
If you were able to trigger a Chrome crash or kernel panic, you may be able to find the crash ID at
chrome://crashes after logging in again. Full debug logs may also contain more information about what went wrong.
If you think you've identified a bug in ChromeOS, please do the following:
Send system and app information, and metricscheckbox is checked before sending the report. Sending system information allows developers to view logs; this is almost always necessary in order to investigate bug reports. (If an issue is already tracking the bug, please include its ID in the feedback report’s description and add a comment to the issue mentioning that you've submitted feedback).