Adding tab strip service to //services

[Fred Shih]

Hello there,

We are currently building a tab strip API service that supports multiple platforms (e.g.: native desktop, webui, android, and maybe ios in the future).

We need to place the service in a shared component because we have several different types of clients. One example is webui and another might be extensions in the future. We were thinking of placing it under //components, but //components code should not depend on higher level browser concepts.

//services (and the servication effort) seem like a good fit, as it is meant to house general services that are tied to Chrome and the browser. However, this project seems inactive at the moment. Is it still possible to add new services here?

We also plan to add several services in the future, such as bookmark. If it is no longer possible to add components to //services, is there a better place to put these components? Thanks!

[Colin Blundell]

On Tue, Oct 7, 2025 at 12:58 AM Fred Shih <ff...@google.com> wrote:

Hello there,

We are currently building a tab strip API service that supports multiple platforms (e.g.: native desktop, webui, android, and maybe ios in the future).

We need to place the service in a shared component because we have several different types of clients. One example is webui and another might be extensions in the future. We were thinking of placing it under //components, but //components code should not depend on higher level browser concepts.

//services should "even less" depend on higher level browser concepts. What exactly do you mean by "depend on higher level browser concepts" here though? e.g. the iOS port can't share any code with //chrome.

 

//services (and the servication effort) seem like a good fit, as it is meant to house general services that are tied to Chrome and the browser. However, this project seems inactive at the moment. Is it still possible to add new services here?

We also plan to add several services in the future, such as bookmark. If it is no longer possible to add components to //services, is there a better place to put these components? Thanks!

Naively //components seems like the right place. Are you planning to run this code in a utility process or in the browser process? //services (and //components/services) are generally for code that needs to run in a utility process. 

[Fred Shih]

Ah, I think i misunderstood the purpose of the //services directory. To clarify, iOS wouldn't necessarily depend on //chrome/browser, but rather on the concept of a browser. I guess it's technically possible to think of a tab in vacuum, but it's kinda strange. But yes, on second look, this service doesn't really belong as a foundational service.

It looks like //components/services might be a better fit in that case. Thanks!

[Colin Blundell]

On Fri, Oct 10, 2025 at 11:38 PM Fred Shih <ff...@google.com> wrote:

Ah, I think i misunderstood the purpose of the //services directory. To clarify, iOS wouldn't necessarily depend on //chrome/browser, but rather on the concept of a browser. I guess it's technically possible to think of a tab in vacuum, but it's kinda strange. But yes, on second look, this service doesn't really belong as a foundational service.

It looks like //components/services might be a better fit in that case. Thanks!

Thanks! I'm still not convinced about the "services" part fwiw given that tabs seems like a browser process concept - see my bolded question below.

[Fred Shih]

The code will run in the browser process. Ah, I see. I incorrectly thought that //components/services could also host browser services because app service has browser code, but I see now that it is actually split between browser-specific code and service (process-agnostic) code.

Since we'll have several services in the future (bookmarks for example), would something like //components/browser_apis or //components/browser_services be reasonable? I'm leaning towards the former so that there isn't a mixup between the different types of services. Thanks!

[Colin Blundell]

On Tue, Oct 14, 2025 at 3:55 AM Fred Shih <ff...@google.com> wrote:

The code will run in the browser process. Ah, I see. I incorrectly thought that //components/services could also host browser services because app service has browser code, but I see now that it is actually split between browser-specific code and service (process-agnostic) code.

Since we'll have several services in the future (bookmarks for example), would something like //components/browser_apis or //components/browser_services be reasonable? I'm leaning towards the former so that there isn't a mixup between the different types of services. Thanks!

If your shared features are conceptually distinct from one another, you can just have them in different components in //components. If they're all conceptually part of "tab strip" (which it doesn't sound like is the case), they could just be subdirectories of //components/tab_strip. I don't see a reason to group them otherwise - essentially *all* components in //components are features to be used by the browser more-or-less.

Agreed on not using the word "service" in the name in any case to avoid any more overloading of that word than is already present in Chromium :).

[Fred Shih]

I'd like to group them together because we want a set of browser APIs that can be used to build most WebUI pages (or any other client, such as Android). Grouping them within a single component will make lookup easier and enforce component-specific guidelines (eg: error handling, API structure, ownership, etc). The end-goal is for WebUI development to feel like building any other web client. That is, you only need to import the set of APIs you need and there is no need to declare your own set of IPCs to proxy browser features to the web, as is the case currently.

So it'd be something like this:

| browser_apis
 ---

     |--- tab_strip

     |--- bookmark

     |--- profile

     |--- .. More APIs as we build it out. 

All of the subdirectories in the browser_apis directory should only contain mojom definitions and typemaps.

[Colin Blundell]

On Tue, Oct 14, 2025 at 10:07 PM Fred Shih <ff...@google.com> wrote:

I'd like to group them together because we want a set of browser APIs that can be used to build most WebUI pages (or any other client, such as Android). Grouping them within a single component will make lookup easier and enforce component-specific guidelines (eg: error handling, API structure, ownership, etc). The end-goal is for WebUI development to feel like building any other web client. That is, you only need to import the set of APIs you need and there is no need to declare your own set of IPCs to proxy browser features to the web, as is the case currently. 

So it'd be something like this:

| browser_apis
 ---

     |--- tab_strip

     |--- bookmark

     |--- profile

     |--- .. More APIs as we build it out. 

All of the subdirectories in the browser_apis directory should only contain mojom definitions and typemaps.

Thanks! Do you have a design doc? I think that would help a lot in understanding the larger context here.

[Fred Shih]

I put something together, let me know if it clarifies what we're trying to accomplish. Thanks!

 Browser APIs Component

[Colin Blundell]

Thanks, Fred! That doc helps a lot. At a high level this makes sense to me. I asked some questions on the doc to clarify my understanding and move toward consensus on a name.

Best,

Colin