Chromium Issue Tracker migration is complete

Monday, February 5, 2024

We are thrilled to share that Chromium issue tracking has migrated! Access the Issue Tracker , and supporting documentation.

Why was this done

Google Issue TrackerWhat happens moving forward Help & Feedbackissue-tracker-support@chromium.org

Chromium Issue Tracker migration beginning Feb 2, 2024 at 5pm PST

Friday, February 2, 2024

As we shared last year, Chromium is moving to a different issue tracker to provide a well-supported user experience for the long term. Migration is beginning today (February 2, 2024) at 5pm PST. We expect migration will be completed by the end of day (PST) February 4, 2024.

What’s happening

We will migrate all Chromium issues, including issue history and stars, from Monorail to a different tool: Chromium Issue Tracker, powered by the Google Issue Tracker. This tooling change will provide a feature-rich and well-supported issue tracker for Chromium’s ecosystem. Chromium will join other open source projects (Git, Gerrit) on this tooling. Existing transparency levels to bugs will be maintained.

Post-Migration

We will publish another post once the migration is complete. Once the migration completes, existing Monorail issue links will redirect to the migrated issues in the new issue tracker. We will prioritize feedback to continue to improve the issue tracker experience. Documentation on new and common workflows will be added to chromium.org once the migration is complete.

Help & Feedback

You can reach out at any time to issue-tracker-support@chromium.org with questions or concerns.

Update to Developers: Chromium Issue Tracker migration

Monday, October 16, 2023

Update: Migration is on track for early February 2024 instead of January 2024.

Chromium is moving to a different issue tracker to provide a well-supported user experience for the long term. The Google team is targeting January 2024 for migration—this post explains the details.

What’s happening

Timing

We are targeting January 2024 for Chromium’s migration, and will share milestones and timing updates throughout the coming months.

Migration Readiness

In due course, we will share additional resources, including a walkthrough of the new issue tracker, highlighting key features.

Post-Migration

While there will be differences, we are working to make the migration straightforward. Once the migration completes, existing Monorail issue links will redirect to the migrated issues in the new issue tracker.

Help & Feedback

You can reach out at any time to issue-tracker-support@chromium.org with questions or concerns.

Limiting Private API availability in Chromium

Friday, January 15, 2021

During a recent audit, we discovered that some third-party Chromium based browsers were able to integrate Google features, such as Chrome sync and Click to Call, that are only intended for Google’s use. This meant that a small fraction of users could sign into their Google Account and store their personal Chrome sync data, such as bookmarks, not just with Google Chrome, but also with some third-party Chromium based browsers. We are limiting access to our private Chrome APIs starting on March 15, 2021.

For users who accessed Google features (like Chrome sync) through a third-party Chromium based browser, their data will continue to be available in their Google Account, and data that they have stored locally will continue to be available locally. As always, users can view and manage their data on the My Google Activity page. They can also download their data from the Google Takeout page, and/or delete it here.

Guidance for vendors of third-party Chromium based products is available on the Chromium wiki.

Posted by Jochen Eisinger, Engineering Director, Google Chrome

Updates to Form Controls and Focus

Monday, March 30, 2020

HTML form controls provide the backbone for much of the web's interactivity. They're easy for developers to use, have built-in accessibility, and are familiar to our users. One issue with native form controls, however, is the inconsistency in their styling. Older controls, such as <button> and <select> were styled to match the user's operating system. Form controls that were added to the platform more recently were designed to match whatever style was popular at the time. For Chromium based browsers, this has led to controls that look mismatched and sometimes outdated, which causes developers to spend extra time (and ship extra code) styling around the controls' default appearance.

a meter, progress, and input type range element stacked vertically. Their visual styles are very different.

<meter>, <progress>, and <input type="range"> look like they come from different worlds in Chrome 80 on Windows.

To help fix this problem, the teams at Microsoft Edge and Google Chrome spent the last year collaborating to retheme and improve the functionality of the built-in form controls on Chromium browsers. The two teams also worked to make the focused states of form controls and other interactive elements like links easier to perceive. These changes are available today in Edge on Windows, and may be seen in Chrome 81 as part of experiments. The chrome://flags/#form-controls-refresh enables the changes in Chrome 81 as well. The changes will roll out in Chrome 83 on Windows, macOS, ChromeOS, and Linux. See the updated release schedule for Chrome 81 and 83. Updates for Chrome on Android should roll out later this year. If you want to hear more about what's coming to form controls, take a look at Nicole Sullivan and Greg Whitworth's talk from CDS 2019. A Fresh Coat of Paint The two teams wanted to make the controls feel like they were part of a matched set. This meant doing away with gradients and using more of a flat design inspired by current design systems. As Nicole Sullivan, a member of the Chrome team, describes it: We were going for beautiful, webby, and neutral. We hope that every design system would see a bit of themselves in the new designs and easily imagine how they might be adapted for their own branding. Below is a comparison of the form controls as they previously appeared in Chromium and as they appear after the redesign: Form controls as they appear in Chrome 80

Form controls as they appear in Chrome 80

Form controls as they appear after the redesign. The styles are much more consistent.

Left: Prior styling of form controls in Chrome 80.

Right: Controls as they appear after the redesign.

Improved Accessibility and Touch Support In addition to improving the default styling, the two teams also tuned up form controls' accessibility and enhanced touch support.
These changes are most notable in a few key areas: A More Visible Focus Ring The focus indicator—sometimes referred to as the "focus ring"—is an important accessibility feature that helps people using a keyboard or switch device to identify which element they're interacting with.
Previously, Chromium used a light single color outline to indicate the focused element. However, if the focused element happened to be on a similarly colored background, the ring would be difficult to perceive:
A button on a blue background. The focus indictor on the button is not discernible.

A button on a blue background. The focus indictor on the button is not discernible.

The previous focus ring on a similarly colored background.

The new focus indicator uses a thick dark ring with a thin white outline, which should improve visibility on both light and dark backgrounds. This is an easy accessibility win that automatically improves the keyboarding experience on a number of sites without developers needing to write any new code.
Black and white double-strokes make the focus ring visible on both light background and dark background

Black and white double-strokes make the focus ring visible on both light background and dark background

The new two-line design for the focus indicator ensures that it's visible on both black and white backgrounds.

Note that there are still some scenarios where the focus ring may be hard to perceive—for example, if a black button is on a white background, or if the focus ring is clipped by elements that are positioned closely together.
If you run into a scenario where the focus ring is hard to perceive, or if the new focus indicator does not match the design of your site, there are ways to style focus including the new :focus-visible pseudo-class, which provides fine-grained control over when the focus indicator is displayed. Increased Tap Target Sizes for Multi-input Displays Over the past few years we've seen an increase in multi-input devices like 2-in-1 devices, tablets, and touch-enabled laptops. This means that touch becomes an important consideration for desktop. However, many of the existing form controls were not designed with multi-input surfaces in mind. For example, <input type="date"> works great on mobile, but the tap targets are much too small to be usable on a touch-screen laptop.
The input type date element as it appears in Chrome 80. The element has very small buttons for incrementing and decrementing the date.

The input type date element as it appears in Chrome 80. The element has very small buttons for incrementing and decrementing the date.

The previous design for <input type="date"> with small tap targets.

To improve functionality on touch screens, the updated controls will now have better flyouts, larger tap targets, and support for swiping and inertia when scrolling:
The redesigned input type date element. It has large buttons and easy to click dates.

The redesigned input type date element. It has large buttons and easy to click dates.

The new design for <input type="date"> with much more accessible tap targets
Improved Color Picker Previously the <input type="color"> element was not fully keyboard accessible, meaning users relying on a keyboard or switch device couldn't use it. Along with a new appearance, the control is also now fully keyboard accessible and includes additional modifier keys (Control, or Command on Mac). These improvements let users jump by ten color values at a time.
An animation of the redesigned color picker, showing improved keyboard navigation

An animation of the redesigned color picker, showing improved keyboard navigation

The new <input type="color"> with improved keyboard accessibility.

More Consistent Keyboard Access Finally, the teams updated the ARIA role mapping of all the controls to match the recommendations in the HTML Accessibility API Mappings specification. This should provide a more consistent experience for anyone relying on a keyboard or assistive technology, like a screen reader, to access the page. How You Can Get Involved While the design refresh is a much needed change, the two teams have also heard from developers that it should be easier to style the built-in form controls and plan to tackle that work next. If you're excited by the idea of improved styling, functionality, and possibly even new high-level components, the folks at Edge and Chrome need your help! Test Your Sites Try out the new form controls and focus indicator in Edge and Chrome Beta. If the design changes have negatively affected your existing sites or apps, let us know using this bug template. Or, if you find a related bug, give it a star! ⭐️ Starring is extremely valuable because it helps platform teams triage and decide what to work on next. Tell us What You Want to See Much of the work on the new form controls was enabled through surveying developers, and interviewing design system and UI framework authors. In an effort to help centralize this feedback and include as many developers as possible in the standards process, the team at Edge have created open-ui.org. If you work on a design system, or a UI component set, consider sharing your knowledge on Open UI to help classify and identify gaps in the existing form controls.
Posted by Rob Dodson, Developer Advocate

Intent to Explain: Demystifying the Blink Shipping Process

Tuesday, November 12, 2019

If you’re a standards-curious web developer, you may have wondered how features get added to browsers, or even how the Chrome team decides what they will work on. You probably also have, at least at some point, thought to yourself “I have this urgent problem but I’ll have to work around it for the foreseeable future, because browsers are just too slow to bring in changes”. You may have even added some expletives when no one was around.
If that description sounds accurate, this is the post for you! This post will describe the Blink process, how browser engineers (both inside and outside of Google) use it in order to ship features in Chromium, what considerations are taken when deciding to ship a new feature, as well as some considerations that impact what features get worked on, and how you can play a role in all of this! Project goals The Chromium project is the open source project on which Chrome is built, and on which other browsers are also based: Samsung Internet, Opera, Brave, Vivaldi, and last (to join the project) but not least, Microsoft Edge. The project enables all those different browsers to share a single implementation of the web platform, and at the same time, keep their unique characteristics and focus.
Blink is the rendering engine used by Chromium. It is the part of the project that descends from WebKit (the rendering engine Safari uses), and which is mostly (but not exclusively) responsible for the Chromium’s Web Platform implementation. The goal of Chromium and Blink inside it is to continuously improve the web platform as a whole.
How does Blink improve the web platform?

By improving its predictability through testing and infrastructure, making sure developers have to spend less of their time tackling browser-specific issues and more of their time… well, developing.

By removing user hostile features, features that increase the platform’s complexity or make its implementations less secure.

By adding platform capabilities that enable web developers to innovate and create web experiences that meet and exceed their users’ expectations and needs.

If we want the web to thrive in the long term, we need to make sure that our users consider it safe and pleasant to use, and that it supports all the capabilities developers need in order to easily make their users (and businesses) are happy.
Any improvement to the platform needs to take backwards compatibility and cross-browser interoperability into account. There’s a lot of web content out there that will never change. The risk of breaking some of it needs to be weighed against the user benefits of shipping that new feature or removing that risky old one. Similarly, in cases where Blink is the first engine to ship a feature or to remove it, we should make sure other browser vendors can follow. We do that by ensuring shipped features designs are widely reviewed, and have specifications and tests to guide future implementers.
The Chromium project is rather large, and is being worked on by many different entities. Therefore it needs to control which features get shipped, while being even-handed in that decision process. We achieve that through a simple process that guides contributors as they evolve the platform to ensure maximum long-term compatibility and interoperability. What features get worked on? Chromium is an open source project that’s being worked on by over 2000 engineers from ~55 different organizations. Of course, Google is responsible for the bulk of Chromium - 92% of commits to the project (data) come from Google, although about 20% of contributors are not Google-affiliated.

With a project of this magnitude, each of the involved companies and contributors are naturally pushing their own slightly different agenda and priorities. Even within Google’s Chrome team there are multiple ways to prioritize which problems are most urgent to tackle and solve. One area that is consistent, is that we work with the ecosystem and developer partners to understand and address their needs. We do that by creating compatibility dashboards, collaborating with frameworks, and observing development patterns in the wild.
The MDN survey is a great example of how the ecosystem can help shape the priorities that a browser vendor has. We’re still in the process of analyzing the results, but it was clear that compatibility is a top priority for developers and we will commit to keep improving on it. We also plan to create more ways to gather structured data on developer needs and hardships.
As you can imagine, with all these priorities from different contributors, it's important for us to be clear about how a feature goes from inception to shipping.

So, what are the typical phases of creating a new web platform feature and shipping it in Chromium?
The very first step before getting started would be to figure out what we need to be working on and which user or developer problems are the most burning ones. That is typically done by talking to partners, looking at current development patterns and consulting with web developers and framework authors to get a better understanding of what the platform can do better to address their and their users’ needs. Once we know which problem we want to tackle, we can start incubating it! What does “incubating” mean?
Over the years, we found that the best way to design and prototype a new platform feature is through incubation - getting a strong grasp of the use cases a feature is trying to solve as a first step, and then rapidly iterating over the design in a public forum that includes browser engineers and domain experts. Only once we are certain that a feature solves important use-cases and have high confidence that it solves it the right way, we bring that feature to an official track at a Standard Development Organization, such as a W3C Working Group, the WHATWG, or TC39.
Not all incubations turn up to be standards though. Some incubations fail and some prototypes never make it out to the hands of users. That is perfectly fine and by design. The web platform cannot afford features that don’t solve real user or developer problems to creep in, and we want to make sure those features never make it to be a permanent part of the platform. Step 1 - Initial research At this phase, we establish a better understanding of the problem space, by gathering up the specific use-cases we want our future solution to tackle and the constraints under which the solution must operate.
At the end of that phase, engineers are expected to publish an explainer that outlines the above, and maybe have a very rough sketch of what a solution may look like. The explainer is published in a relevant public forum (e.g. the WICG discourse) in order to solicit feedback from the web community at large. Such feedback can include missed-out use-cases, further constraints that can impact the design, or simply statements of support for solving the problem.
It’s important at this stage to focus on the problem, and not over-index on any one possible solution - and this is one of the places we haven’t always been perfect. Step 2 - Design & Prototype Now that we have better grip of the problems we’re trying to solve and the constraints in which we operate, we can start designing the feature and what it may look like. Ideally, the design team would include browser engineers from interested vendors as well as problem space experts from the web developer or framework developer community.
Once we have an initial rough design, it might be a good idea to start building and committing code (behind a flag and turned off by default) in order to better understand the solution’s feasibility and complexity.
That’s when engineers should send out an “Intent to Prototype” email to blink-dev (previously, “Intent to Implement”), in order to notify the relevant code owners that work is underway in that area. Note that such an intent doesn’t mean that the feature is shipping soon, or that it will ship at all for that matter. It just means that this is a problem space that’s being explored, and code is landing to that end.
That’s also a good point in time to make sure the feature will get a wider review, by filing for a TAG review. Step 3 - Experiment & iterate Once code starts to land behind a flag, it’s a good time for interested web developers to start playing around with the solution by turning on the feature flag and testing it out. Feedback on the initial implementation is critical in order to make sure the eventual design would work well for developers and users alike. For some features, such experimentation is enough for developers to get a good handle on what’s the solution looks like, and how well it addresses the problem.
In other cases, it’s critical to gather data from the field regarding the solution, to see how well it works in broader deployment to fulfill user’s needs, or get a better understanding of its performance characteristics at scale. Step 3.5 - Origin Trial In those cases, a browser engineer can request an Origin Trial (by sending out an Intent to Experiment email), which enables interested developers to test the feature out in broader deployment to users who have not turned on the feature flag. Once an Origin Trial is in place, developers can register for the trial, and enable the feature (in production) for their domains. That enables them to gather data on the user impact of the feature, and report it back to the design team, confirming or refuting their assumptions regarding the solution’s viability.
Note that an Origin Trial is a temporary experiment, and there’s a good chance that the feature will significantly change before it will be enabled by default, or even that the effort will be dropped altogether. Developers interested in participating should take that into account, and not rely on the feature being available to their users beyond the scope of the trial. Step 4 - ship it! Once the previous steps were completed with success and the team believes the feature is ready to be turned on by default, that’s when they can submit an Intent to Ship.
That’s a part of the process that’s a bit more strict.
In order to ship a feature by default, engineers need approval for the feature to ship from 3 API owners.
What’s an “API owner”? API owners are a set of trusted Chromium engineers, who are responsible for enforcing the Blink process guiding principles. Each feature we’re trying to ship has some user and developer benefits, otherwise we probably wouldn’t be working on it. Shipping new features can introduce interoperability risks, if other browsers don’t follow us. The API owners are tasked with applying our compatibility and interoperability principles and help evaluate each shipping feature with regards to its risk/benefit tradeoff. They then provide their approval on “Intent to Ship” threads for new shipping features, if they think the benefits outweigh the risks. Those approvals are provided in the form of “LGTM” (“Looks Good To Me”) replies on intent threads.
Note that LGTMs are not required for Intent to Prototype. For an Intent to Experiment, approval from a single API owner is sufficient, as the risk they pose is fairly contained.
As part of the “Intent to Ship” request, chromium engineers need to provide clear signals regarding the risk and benefit tradeoff of the feature.

The feature needs to have a solid specification and a comprehensive cross-browser test suite in order to minimize interoperability risk.

Signals from other browser vendors as well as from wide review forums (such as the TAG) are taken into account, alongside signals from the web developer community and partners who are planning to use the feature.

If the feature went through an Origin Trial, a report outlining the results is also important to better understand the benefits.

Note that the fact that an “intent to ship” is sent indicates the team’s estimate of the feature being ready to ship, but it does not necessarily mean that the feature will ship shortly, or at all.
Some features take a long time to go through the intent process, in order to prove that the risk they pose is low enough to justify shipping. Others get held up addressing feedback from other vendors or from wide-review forums.
In other (rare) cases, features can be rejected by the API owners, and their proponents then need to look for alternative ways to resolve the problem, which won’t hit the same concerns that got their initial intent rejected. Removing features Finally, while adding new feature certainly grabs most people’s attention, an equally important part of the intent process is to deprecate and remove legacy web platform features. In those cases, the main risk is breaking existing content, and the benefits are typically around improving user’s security, privacy and performance. The project’s willingness to take some compatibility risk and remove features is critical to our risk/benefit calculus also when launching features first - if we got it wrong and late feedback causes us to change course, we typically can figure out a path to deprecate those features to get us back on track to interoperability. Summary The Chromium’s project goal is to make sure the web platform remains a healthy and successful platform. For that, we believe the platform needs to make significant progress in the face of shifting developer and user expectations, as well as adapt to the changing market forces and constraints. At the same time, we need that progress to be done in a responsible manner both inside the Chromium project and when it comes to our collaboration with the wider ecosystem.
The Blink process’ role is to keep the balance between those different requirements, and to help ensure the web is a thriving platform for generations to come.

Posted by Yoav Weiss, Wrangler of processes and Advocate of developers.

Chromium Blog

Chromium Issue Tracker migration is complete

Chromium Issue Tracker migration beginning Feb 2, 2024 at 5pm PST

Update to Developers: Chromium Issue Tracker migration

Limiting Private API availability in Chromium

Updates to Form Controls and Focus

Intent to Explain: Demystifying the Blink Shipping Process

Labels

Archive

Feed