WebGPU Introduction

WebGPU CTS

Contribution

1. Set up the CTS developing environment.
2. Add to or edit the test plan in the CTS project site.
3. Implement the test.
4. Upload the test and request a review.

Organization

Example

• desc: Describes what it tests and summarize how it tests that functionality.
• params: Defines parameters with a list of objects to be tested. Each such instance of the test is a “case”
• fn: Implementation body of the test.

Parameterization

Contributors

The next steps

References

This article is written by referring to the Multiple Page Architecture document.

Motivation

Goal

• Enable one WebContents to host multiple(active/inactive, visible/invisible) pages
• Allow navigating WebContents to an existing page

Design Overview

• Allow multiple FrameTrees to be created in the given WebContents in addition to the existing main one
• Add a new navigation type, which navigates a given FrameTree to an existing page. (For example, BFCache will use it for history navigation restoring the page from the cache. Prerendering will use it to instantly navigate to a prerendered page.)
• Modify RenderFrameHost to avoid knowing its current FrameTreeNode/FrameTree to allow the main RenderFrameHost to be transferred between different FrameTreeNodes.

Igalia Participation

References

In this article, I share how I started webOS Chromium upstream, what webOS patches were contributed by LG Electronics, and how I’ve contributed to Chromium.

First, let’s briefly describe the history of the webOS. WebOS was created by Palm, Inc. Palm Inc. was acquired by HP in 2010 and HP made the platform open source, so it then became open webOS. In January 2014 the operation system was sold to LG Electronics. LG Electronics has been shipping the webOS for their TV and signage products since. LG Electronics has also been spreading the webOS to more of their products.

The webOS uses Chromium to run web applications. So, Chromium is a very important component in the webOS. As other Chromium embedders, the webOS also has many downstream patches. So, LG Electronics has tried to contribute own downstream patches to the Chromium open source project to reduce the effort to catch up to the latest Chromium version as well as to improve the quality of the downstream patches. As one of LG Electronics contractors for the last one and half years, I’ve started to work on the webOS Chromium contribution since September 2017. So, let’s start to explain the process of contributing:

1. The Corporate CLA

The Chromium project only accepts patches after the contributor signs a Contributor License Agreement (CLA). There are two kinds of CLA, one for individual and one corporate contributors. If a company signs the corporate CLA, then the individual contributors are exempt from signing an individual CLA, however, they must use their corporate email address as well as join the google group which was created when the corporate CLA was signed. LG Electronics signed up the corporate CLA and they were added to AUTHOR file.

• Corporate Contributor License Agreement (Link)
  

• Individual Contributor License Agreement (Link)
  

2. List upstreamable patches in webOS

After finishing the registration of the corporate CLA, I started to list up upstreamable webOS patches. It seemed to me that there were two categories in the patches. One was new features for the webOS. The other one was bug fixes. In the case of new features, the patches were mainly to improve the performance or to make LG products like TV and signage use less memory. I tried to list upstreamable patches among those patches. The patch criteria was either to improve the performance or obtain a benefit on the desktop. I thought this would allow owners to accept and merge the patch into the mainline more easily.

3. What patches have been merged to Chromium mainline?

Before uploading webOS patches, I merged the patches to replace deprecated WTF or base utilities (WTF::RefPtr, base::MakeUnique) with c++ standard things. I thought that it would be good to show that LG Electronics started to contribute to Chromium. After replacing all of them, I could start to contribute webOS patches in earnest. I’ve since merged webOS patches to reduce memory usage, release more used memory under OOM, add a new content API to suspend/resume DOM operation, and so on. Below is the list of the main patches I successfully merged.

1. New content API to suspend/resume DOM operation
   • Note: I added a content API to suspend/resume DOM operation – void PausePageScheduledTasks(bool paused). Embedders who only use the content API as the webOS can suspend or resume DOM operation using the PausePageScheduledTasks. The webOS has been using the API to suspend when web an application goes to the background. Then, it resumes the paused web application when it comes to the foreground. This API will be also useful for other embedders who only use the content API like the webOS.
     • Support to suspend/resume active page tasks of blink in the content layer
2. Release more used memory under an out-of-memory situation
   • Note: According to the Chromium performance bot, the patches to reduce the memory usage in RenderThreadImpl::ClearMemory could reduce the memory usage until 2MB in the background.
     
     • Purge more cache data in RenderThreadImpl::ClearMemory
     • Make RenderThreadImpl::ReleaseFreeMemory call RenderThreadImpl::ClearMemory
     • Call blink::WebMemoryCoordinator::OnPurgeMemory in RenderThreadImpl::ReleaseFreeMemory
   • Note: OnMemoryPressure listener was added to the compositor layers through these patches. So, the compositor has been releasing more used memory under OOM through the OOM handler. In my opinion, this is very good contribution from the webOS.
     • Handle a low memory situation in LayerTreeHostImpl
     • CC: Support the memory pressure handler in StagingBufferPool
     • CC: Support the memory pressure handler in ResourcePool
     • CC: Support the memory pressure handler in SoftwareImageDecodeCache
     • CC: Support the memory pressure handler in GpuImageDecodeCache
3. Introduce new command line switches for embedded devices
   • Note: I’ve added command-line switches to tune memory limit or disk cache size through these patches. Other embedders can also customize the memory usage and disk cache size for their devices. The webOS has been tuned by using the command-line switches.
     • Pass the skia resource cache limit in the command line to renderer processes.
     • Support to set the maximum decoded image bytes through a command line
     • Pass the skia font cache limit in the command line to renderer processes
     • Pass the maximum disk cache size of appcache in the command line to appcache thread
     • AppCache: Add command-line flags for default quota and disk size.
     • Pass the cache size in the command line to the ShaderDiskCache::CacheSizeBytes
     • Introduce a new command-line switch to set the network timeout in FMP

4. Trace LG Electronics contribution stats

As more webOS patches have been merged to Chromium mainline, I thought that it would be good if we run a tool to chase all LG Electronics Chromium contributions so that LG Electronics’s Chromium contribution efforts are well documented. To do this I set up the LG Electronics Chromium contribution stats using the GitStats tool. The tool has been generating the stats every day.

• The chart shows all contribution activity done by LG developers by date.
  
• The table shows LGE Chromium authors
  
• URL of the tool. You can see the stats in the URL
  https://lgsvl.github.io/lge-cr-stats/authors/lge_authors.html

I was happy to work on the webOS upstream project over the past year. It was challenging work because the downstream patch should show some benefits in Chromium mainline. I’m sure that LG Electronics will continue to keep contributing good patches to webOS and I hope they’re going to become a good partner as well as a contributor in Chromium.

UPDATE: I made a presentation at the lightning session of BlinkOn9 Sunnyvale.

• Lightning talks schedule
• Slide

Have you heard that navigator.registerProtocolHandler javascript API?

The API is to give you the power to add your customized scheme(a.k.a. protocol) to your website or web application. If you register your own custom scheme, it can help you to avoid collisions with other DNS, or help other people use it correctly, and be able to claim the moral high ground if they use it incorrectly. In this post, I would like to introduce the feature with some examples, and what I’ve contributed to the feature.

Introduction

The registerProtocolHandler had been started discussing since 2006. Finally, it was introduced in HTML5 for the first time.

• Spec URL:   https://html.spec.whatwg.org/multipage/webappapis.html#custom-handlers

This is a simple example of the use of navigator.registerProtocolHandler. Basically, the registerProtocolHandler takes three arguments,

• scheme – The scheme that you want to handle. For example, mailto, tel, bitcoin, or irc.
• url – A URL within your web application that can handle the specified scheme.
• title – The title of the handler.

<script>
     navigator.registerProtocolHandler("web+search",
                                       "https://www.example/search/url=%s",
                                       "web search");
</script>
<a href="web+search:igalia">Igalia</a>

As this example, you can register a custom scheme with a URL that can be combined with the given URL(web+search:igalia)

However, you need to keep in mind some limitations when you use it.

1. URL should include %s placeholder.
2. You can register own custom handler only when the URL of the custom handler is same the website origin. If not, the browser will generate a security error.
3. There are pre-defined schemes in the specification. Except for these schemes, you’re only able to use “web+foo” style scheme. But, the length of “web+foo” is at least five characters including ‘web+’ prefix. If not, the browser will generate a security error.
   • bitcoin, geo, im, irc, ircs, magnet, mailto, mms, news, nntp, openpgp4fpr, sip, sms, smsto, ssh, tel, urn, webcal, wtai, xmpp.
4. Schemes should not contain any colons. For example, mailto: will generate an error. So, you have to just use mailto.

Status on major browsers

Firefox (3+)

When Firefox meets a webpage which includes navigator.registerProtocolHandler as below,

navigator.registerProtocolHandler("web+search",
                                  "https://www.example/search/url=%s",
                                  "web search");

It will show an alert bar just below the URL bar. Then, it will ask us if we want to add the URL to the Firefox handler list.

After allowing to add it to the supported handler list, you can see it in the Applications section of the settings page (about:preferences#general).

Now, the web+github custom scheme can be used in the site as below,

<a href="web+github:wiki">Wiki</a>
<a href="web+github:Pull requests">PR</a>

Chromium (13+)

Let’s take a look Chrome on the registerProtocolHandler. In Chrome, Chrome shows a new button inside the URL bar instead of the alert bar in Firefox.

If you press the button, a dialog will be shown in order to ask if you allow the website to register the custom scheme.

In the “Handlers” section of the settings (chrome://settings/handlers?search=protocol), you’re able to see that the custom handler was registered.

FYI, other browsers based on Chromium (i.e. Opera, Yandex, Whale, etc.) have handled it similar to Chrome unless each vendor has own specific behavior.

Safari (WebKit)

Though WebKit has supported this feature in WebCore and WebProcess of WebKit2, no browsers based on WebKit have supported this feature with UI. Although I had tried to implement it in UIProcess of WebKit2 through the webkit-dev mailing list so that browsers based on WebKit can support it, Unfortunately, some of Apple engineers had doubts about this feature though there were some agreements to support it in WebKit. So I failed to implement it in UIProcess of WebKit2.

• [webkit-dev] Support “registerProtocolHandler” in WebKit2
  – https://lists.webkit.org/pipermail/webkit-dev/2015-May/027451.html

My contributions in WebKit and Chromium

I’ve mainly contributed to apply new changes in the specification, to fix bugs and improve test cases. First, I’d like to introduce the bug that I modified in Chromium recently.

Let’s assume that URL has multiple placeholders(%s).

navigator.registerProtocolHandler("test",
                                  "http://example.com/%s/url=%s",
                                  "title");" 
<a href="test:duplicated_placeholders">this</a>

According to the specification, only first “%s” placeholder should be substituted, not substitute all placeholders. But, Chrome has substituted all placeholders with the given URL as below, even though Firefox has only substituted the first placeholder.

http://example.com/test%3Aduplicated_placeholders/url=test%3Aduplicated_placeholders

So I fixed the problem in [registerProtocolHandler] Only substitute the first “%s” placeholder. The latest Chromium substitutes only first placeholder like below,

http://example.com/test%3Aduplicated_placeholders/url=%s

This is a whole list what I’ve contributed both WebKit and Chromium so far.

1.  WebKit
   • Change a url parameter type with URL in NavigatorContentUtils
   • Add *final* keyword to NavigatorContentUtils class
   • [EFL][WK1] Apply std::unique_ptr<> to NavigatorContentUtilsClientEfl
   • Change NavigatorContentUtils client ownership from port side toNavigatorContentUtils
   • Remove unnecessary null checking in NavigatorContentUtils
   • Mark Supplement instead of RefCountedSupplement in NavigatorContentUti
   • Rearrange conditions to find invalid protocol in NavigatorContentUtils::verifyProtocolHandlerScheme()
   • Replace DEPRECATED_DEFINE_STATIC_LOCAL with NeverDestroyed<T> in NavigatorContentUtils
2. Chromium
   • [Custom Scheme] Remove isProtocolHandlerRegistered in the NavigatorContentUtils of blink
   • Update DOMString url types with USVString in the NavigatorContentUtils.idl
   • Remove an unnecessary loop when converting scheme in NavigatorContentUtils
   • Use OwnPtr|PassOwnPtr to pass a pointer of NavigatorContentUtilsClient instance
   • Mark Supplement instead of RefCountedSupplement in NavigatorContentUtils
   • Remove unnecessary null checking in NavigatorContentUtils
   • Improve scheme validation check in NavigatorContentUtils
   • NavigatorContentUtilsClientImpl has own files
   • Call isValidProtocol() function first in order to remove duplicated protocol checking in NavigatorContentUtils
   • Use NavigatorContentUtils guard for unregisterProtocolHandler()
   • Refactor verifyProtocolHandlerScheme() in NavigatorContentUtils.cpp
   • Remove a command line for NavigatorContentUtils
   • [Custom Scheme] Remove isProtocolHandlerRegistered in the NavigatorContentUtils of blink
   • [Custom Scheme] Remove ‘title’ parameter in the tests of unregisterProtocolHandler
   • fixup! [Custom Scheme] Restore isProtocolHandlerRegistered in historical.window.js
   • [registerProtocolHandler] Only substitute the first “%s” placeholder
   • [registerProtocolHandler] Add a unit test for percent-encoding
   • Introduce mock test system for navigator content utils
   • Use a consistent scheme name in navigatorcontentutils tests
   • Scheme of content utils should be compared in an ASCII case-insensitive manner

Summary

So far, we’ve looked at the navigator.registerProtcolHandler for your web application simply. The API can be useful if you want to make users use your web applications like a web-based email client or calendar.