During the last years Igalia<\/a> and Protocol Labs<\/a> have been working on improving the support of this HTML API<\/em> in several of the main web engines, with the long term goal of getting the IPFS<\/em> protocol a first-class member inside the most relevant browsers.<\/p>\n In this post I’m going to explain the most recent improvements, especially in Chrome, and some side advantages for Chromium embedders that we got on the way.<\/p>\n The first challenge faced by Chromium-based browsers wishing to add support for a new protocol was the architecture. Most of the logic and relevant codebase lived in the \/\/chrome<\/em> layer. Thus, any intent to introduce a behavior change on this logic would require a direct fork and patch the \/\/chrome<\/em> layers with the new logic. The design wasn’t defined to allow Chrome embedders to extend it with new features<\/p>\n The Chromium project provides a Public Content API to allow embedders reusing a great part of the browser’s common logic and to implement, if needed, specific behavior though the specialization of these APIs. These would seem to be the ideal way of extending the browser capabilities to handle new protocols. However, accessing \/\/chrome<\/em> from any layer (eg. \/\/content<\/em> or \/\/components<\/em>) is forbidden and constitutes a layering violation.<\/p>\n After some discussion with Chrome engineers (special thanks to Kuniko Yasuda and Colin Blundell) we decided to move the Protocol Handlers logic to the \/\/components<\/em> layer and create a new Custom Handlers component.<\/p>\n The following diagram provides a high-level overview of the architectural change:<\/p>\n The new component makes the Protocol Handler logic Chrome independent<\/strong>, bringing us the possibility of using the Content Public API to introduce the mentioned behavior changes, as we’ll see later in this post.<\/p>\n Only the registry’s Delegate and the Factory classes will remain in the \/\/chrome<\/em> layer.<\/p>\n The Delegate<\/strong> class was defined to provide OS integration, like setting as default browser, which needs to access the underlying operating systems interfaces. It also deals with other browser-specific logic, like Profiles. With the new componentized<\/em> design, embedders may provide their own Delegate implementations with different strategies to interact with the operating system’s desktop or even support additional flavors.<\/p>\n On the other hand, the Factory<\/strong> (in addition to the creation of the appropriated Delegate’s instance) provides a BrowserContext<\/em> that allows the registry to operate under Incognito mode.<\/p>\n Lets now get a deeper look into the component, trying to understand the responsibilities of each class. The following class diagram illustrates the multi-process architecture of the Custom Handler logic:<\/p>\n The ProtocolHandlerRegistry<\/em> class has been modified to allow operating without user preferences storage; this is particularly useful to move most of the browser tests to the new component and avoid the dependency with the prefs<\/em> and user_prefs<\/em> components (eg. testing). In this scenario the registered handlers will be stored in memory only.<\/p>\n It’s worth mentioning that as part of this architectural change, I’ve applied some code cleanup and refactoring, following the policies dictated in the base::Value Code Health<\/a> task-force. Some examples:<\/p>\n The ProtocolHandlerThrottle<\/em> implements URL redirection<\/strong> with the handler provided by the registry. The ChromeContentBrowserClient<\/em> and ShellBrowserContentClient<\/em> classes use it to implement the CreateURLLoaderThrottles<\/em> method of the ContentBrowserClient<\/em> interface.<\/p>\n The specialized request is the responsible for handling the permission prompt dialog response, except for the the content-shell implementations, which bypass the Permission APIs (more on this later). I’ve also been working on a new design that relies on the PermissionContextBase::CreatePermissionRequest<\/em> interface, so that we could create our own custom request and avoid the direct call to the PermissionRequestManager<\/em>. Unfortunately this still needs some additional support to deal with the RegisterProtocolHandlerPermissionRequest<\/em>‘s specific parameters needed for creating new instances, but I won’t extend on this, as it deserves its own post.<\/p>\n Finally, I’d like to remark that the new component provides a simple registry factory, designed mainly for testing purposes. It’s basically the same as the one implemented in the \/\/chrome<\/em> layer except some limitations of the new component:<\/p>\n I also wanted to apply some refactoring as well to improve the inter-process consistency<\/strong> and increase the amount of shared code<\/strong> between the renderer and browser process.<\/p>\n One of the most relevant parts of this refactoring was the one applied to the implement the Custom Handlers’ normalization process<\/a>, which goes from some URL’s syntax validation to the security and privacy checks. I’ve landed some patches (CL#3507332<\/a>, CL#3692750<\/a>) to implement functions that are shared among the renderer and browser processes to implement the mentioned normalization procedure.<\/p>\n The code has been moved to blink\/common so that it could be invoked also by the new Custom Handlers component described before. Both the WebContentsImpl<\/em> (run by the Browser process) and the NavigatorContentUtils<\/em> (by the Renderer process) rely on this common code now.<\/p>\n Additionally, I have moved all the security and privacy checks from the Browser class, in Chrome, to the WebContentsImpl<\/strong> class. This implies that any embedder that implements the WebContentsDelegate<\/em> interface shouldn’t need to bother about these checks, assuming that any ProtocolHandler instance is valid.<\/p>\n In the introduction I mentioned that the main goal of this refactoring was to decouple the Custom Handlers logic from the Chrome’s specific codebase; this would allow us to modify or even extend the implementation of the Custom Handlers APIs.<\/p>\n The componentization of some parts of the Chrome’s codebase has many advantages, as it’s described in the Browser Components design document<\/a>. Additionally, a new Custom Handlers component would provide other interesting advantages on different fronts.<\/p>\n One of the most interesting use cases is the definition of Web Platform Tests for the Custom Handlers APIs. This goal has 2 main challenges to address:<\/p>\n Finally, we would like this new component to be useful for Chrome embedders, and even browsers built directly on top of a full featured Chrome, to implement new Custom Handlers related features. This line of work would eventually be useful to improve the support of distributed protocols like IPFS, as an intermediate step towards a native implementation<\/strong> of the protocols in the browser.<\/p>\n","protected":false},"excerpt":{"rendered":" The HTML Standard section on Custom Handlers describes the procedure to register custom protocol handlers for URLs with specific schemes. When a URL is followed, the protocol dictates which part of the system handles it by consulting registries. In some cases, handlers may fall to the OS level and and launch a desktop application (eg. … Continue reading New Custom Handlers component for Chrome<\/span><\/a><\/p>\n","protected":false},"author":20,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23,11],"tags":[],"class_list":["post-1715","post","type-post","status-publish","format-standard","hentry","category-chromium","category-planet"],"_links":{"self":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1715","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/comments?post=1715"}],"version-history":[{"count":33,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1715\/revisions"}],"predecessor-version":[{"id":1853,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/posts\/1715\/revisions\/1853"}],"wp:attachment":[{"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/media?parent=1715"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/categories?post=1715"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.igalia.com\/jfernandez\/wp-json\/wp\/v2\/tags?post=1715"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Componentization of the Custom Handler logic<\/h2>\n
![\"Custom](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2022\/08\/components-627x1024.png\")
<\/a>![\"Class](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2022\/08\/multi-process-class-diagram-1024x654.png\")
<\/a>\n
\n
Single-Point security checks<\/h2>\n
![\"Refactoring](\"http:\/\/blogs.igalia.com\/jfernandez\/files\/2022\/08\/single-point-security-1024x456.png\")
<\/a>Conclusion<\/h1>\n
\n