A <webview> tag in Chromium

I often talk about a webview as a common term. For instance, when I worked on AGL project, we integrated Web Runtime in order to support a webview to native applications from AGL like Android WebView. However, I wasn’t aware of <webview> tag implementation for a web page in Chromium.

<webview>

<webview> is a tag that Chromium Apps and chrome://… pages could use.

Chromium has some samples using <webview> for testing. I launched one of these examples with some modification to include <div> at the same level with a <webview>.

The green box is a <webview> and the blue box is <div>.
A web page includes <webview> that has another web page inside it. Note that a <webview> tag is not a standard and it’s used for Chrome Apps and chrome:// pages.


WebContents is

A reusable component that is the main class of the Content module. It’s easily embeddable to allow multiprocess rendering of HTML into a view.

This image shows the conceptual application layers in Chromium.
https://www.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome/
When we open a web page in Chromium, you can imagine that Chromium creates a WebContents and it shows us the rendered web page.


Current implementation

When <webview> exists in a web page, how does it work and where is it located on these layers from the image above?

Based on the current implementation, WebContents can have inner WebContents. Chromium implements a <webview> tag with a GuestVIew which is the templated base class for out-of-process frames in the chrome layer. A GuestView maintains an association between a guest WebContents and an owner WebContents.

For a <webview> interface at Javascript, Chromium has custom bindings. When a <webview> tag is attached, the API connected by the custom bindings is called from the renderer. The request for attaching it is sent to the browser through Mojo interface.


interface GuestViewHost {
// We have a RenderFrame with routing id of |embedder_local_frame_routing_id|.
// We want this local frame to be replaced with a remote frame that points
// to a GuestView. This message will attach the local frame to the guest.
// The GuestView is identified by its ID: |guest_instance_id|.
 AttachToEmbedderFrame(
     int32 embedder_local_frame_routing_id,
     int32 element_instance_id,
     int32 guest_instance_id,
     mojo_base.mojom.DictionaryValue params) => ();
It triggers WebContentsImpl::AttachInnerWebContents() to attach the inner WebContents to the outer WebContents.

Chromium has also another type of GuestView internally. That is MimeHandlerViewGuest to handle mime types from tags such as <object> or <embed>. For instance, if <embed> tag is linked to pdf file, it’s also managed by a GuestView.


MPArch

These days I’m working on MPArch, that
• enables one WebContents to host multiple (active / inactive, visible / invisible) pages. from MPArch document

For the detail for MPArch, you could refer to this blog post, ‘MPArch(Multiple Page Architecture) project in Chromium‘.

As a GuestView is implemented with a Multiple-WebContents model, it’s also considered for MPArch.
After working on Prerendering and fenced frames intensively, our team started to migrate GuestView tests in order to avoid direct access to WebContents and manage it based on RenderFrameHost.
Once we have some progress regarding GuestView, I hope we could share the status, as well.


We’re hiring. https://www.igalia.com/jobs/


Mojo conversion in printing

[from the renderer to the browser]

For the past few years, Chromium has put effort into the conversion of the legacy IPC system to Mojo.


If you need information about Mojo, please take a look at the documents and a video below.
Igalia also joined the task, and we converted the old-style IPC communication into Mojo messages. The highest priority was the conversion for the messages in //content area, and then we expanded into other components. Regarding the work on Mojo conversion by Igalia, please see the blog post from one of my teammates, Mario.

In this blog post, I’d like to talk about the Mojo conversion in the printing module. I gave a small talk about this during BlinkOn14 lightning talk.

Chromium architecture is based on the multiprocess model and a big amount of IPC messages are for the communication between the browser process and the renderer process. The printing module also communicates with both of them. When I started to work on the Mojo conversion in the printing module, the conversion from the browser to the renderer had already been completed. So, I looked into the messages from the renderer to the browser.


Printing in Chromium

I knew that the printing functionality is great while I was using the Chromium browser, but I was not aware that it has a lot of features with consideration of various environments. On the desktop, you could use it through

  • window.print() from javascript code.
  • Keyboard shortcut (e.g. ctrl+p)
  • From the context menu: print a page or print a selection.
  • The three dots menu
It might have more entry points I don’t know yet.


Once it arrives at the printing main code, it has almost similar code flow but many issues I faced were caused by these various entrance points and use cases. If you have used the printing from Chromium, I believe you’re aware of the printing preview. But, did you know that you could also directly use the printing native menu, skipping the printing preview? I didn’t know it. To disable the print preview,
Command line Switch option: --disable-print-preview
Keyboard shortcut:
  - Preview : ctrl+p
  - Without Preview : ctrl+shift+p
And, the printing module also supports printing on the headless and Android WebView. Whenever the CL related to the Mojo conversion landed, I tried to verify all the possible combinations but it always contained regressions.



Printing with legacy IPC vs Printing with Mojo

Here are legacy IPC messages. You can see how many messages the printing module had and how they were distributed.
Using legacy IPC

And, the next is how they have been changed now. You can see each end point.
Using Mojo
For the interfaces added, you could refer to //components/printing/common/print.mojom.

So why do we want to use Mojo instead of the legacy IPC? Legacy IPC is deprecated in Chromium and Mojo helps to refactor Chromium into a large set of smaller services. For more detail, please refer to this document. With the Mojo conversation in printing, we also removed multiple layers in printing for legacy IPC.


Replacing EnableMessagePumping()

There were a few challenges while working on the printing Mojo conversion. One of them was when I needed to find something to replace EnableMessagePumping(). That is a function that supports pumping messages while a sync message is waiting for a reply. It was not used in many places because it could increase complexity during IPC and the messages used it or the use cases had been cleaned up already. In the printing module, there were two legacy IPC messages using it. After much deliberation on how to handle this part, I defined a sync message and passed a callback that quits the runloop. Then, the nested runloop allows running tasks while it’s waiting for a reply.


A racing issue

There were also some interesting issues. One of them was related to handling the printing result of multiple renderer processes. When there is more than one renderer process by subframes, the browser process manages all the results from each renderer. In that case, there was a racing issue like below.
A racing issue
The sub frame should be handled after the compositor for the main frame is created but it could be handled before the main frame. So, it’s been updated with queuing the sub frame if the compositor is not created and handling the queue after the compositor is created.


Wrap up

With the Mojo conversion in the printing module, I’ve naturally cleaned up classes, structures, and files that are no longer necessary. \o/


There were a few more problems after I thought the work was done, but with the help of many people I was able to solve them safely. Thanks a lot, all people who reviewed CLs, reported issues, and discussed how to fix them.


Giving a talk at Automotive Linux Summit 2019

Last year, I’ve worked on Chromium and Web Application Manager on AGL platform with some fellow Igalian colleagues. Our goal was to support Chromium with upstream Wayland port and Web Application Manager. Although we faced a lot of challenges, such as porting them to AGL framework, handling SMACK on Chromium multiprocess architecture, supporting wayland ivi protocol on Chromium and so on, we completed our goal and showed a demo at CES 2019.

This year, I gave a talk about our work on AGL at several events such as AGL All Member Meeting, BlinkOn10 in Canada and Automotive Linux Summit 2019.

For Automotive Linux Summit 2019 in Tokyo last week, my colleague, Lorenzo, and I attended the event and managed our Igalia booth.


We showed some demos for Chromium and Web Application Manager on AGL on several reference boards such as Renesas m3 board, Intel Minnowboard, and RPi3. I was very pleased to meet many people and share our works with them.

I gave a talk about “HTML5 apps on AGL platform with the Web Application Manager“.


As you might know, Igalia has worked on Chromium Wayland port for several years. We tried various approaches and finally fully upstreamed our changes to upstream last year. Chromium on AGL has been implemented based on it with supporting ivi-extension.
LG opensourced Web Application Manager used for their products and Igalia implemented Web Runtime solution for AGL on the top of it. My colleague, Jacobo, uploaded a post about ‘Introducing the Chromium-based web runtime for the AGL platform‘. You can find more information there.

I also participated in the AGL Developer Panel in ALS.


We generally talked about the current status and the plans for the next step. Thanks to Walt Minor, Automotive Grade Linux Development Manager at The Linux Foundation, everything went well and I believe all of us enjoyed the time.

I think AGL is one of open source projects growing fast and it shows continuous improving. When I looked around demo booths, I could see many companies tried various interesting ideas on the top of the AGL.

Last, I’d like to say “Thanks a lot, people who organized this event, came by our Igalia booth, and listened to my talk”.

Automotive Grade Linux Logo