Chromium Weekly 4

一、Change

1.BoringSSL/NSS Chimera

We will be porting Chromium on Linux and CrOS to a BoringSSL/NSS “chimera” where BoringSSL provides crypto and SSL, while certificate handling uses the system copy of NSS.

As of 41, Chrome on Android, Mac, and Windows are using BoringSSL.

All that’s left are the Linux, CrOS, and iOS ports.

BoringSSL和NSS用来加密和认证，应用于WebCrypto、SSL、client certificate。

Chrome-M41 在 Android, Mac, 和Windows上，已经从NSS切换到BoringSSL。为了剩下的Linux, CrOS, 和iOS ，他们设置了编译开关USE_OPENSSL、USE_OPENSSL_CERTS等，这个过渡称为Chimera.

Chimera， 厄喀德那和堤丰的后代，“Chimera”在希腊语里的意思是“山羊”，它拥有羊身、狮头（赫西奥德的《神谱》中记载有说它有三个头）和蛇尾，会喷火，最终被骑着飞马的贝勒洛方所杀。也有人说它是九头蛇许德拉的后代，或说是厄喀德那和她的儿子双头犬所生。在中世纪的叙事诗、绘画、雕刻和建筑中常会出现。凯米拉的来源众说纷纭，比较切实的说法认为它产于利西亚火山区，该火山的山脚下盛产蛇类，较高的山坡上盛产山羊，荒凉的山顶则是火山口，有狮子出没其中，因此凯米拉可能是这一地区的隐喻。

2.status of libjingle

Libjingle is a collection of open-source C++ code and sample applications that enables you to build a peer-to-peer application.

WebRTC (Web Real-Time Communication) is an API definition drafted by the World Wide Web Consortium (W3C) that supports browser-to-browser applications for voice calling, video chat, and P2P file sharing without the need of either internal or external plugins.

The code in webrtc/libjingle is already practically separate from the rest of webrtc/. It includes an implementation of XMPP and Jingle, and WebRTC does not use it.

WebRTC would be fully merged with the non-XMPP parts of libjingle and the XMPP-specific parts of libjingle would live on separately.

Google Talk是Google推出的一个即时通讯产品，她采用的XMPP协议。这个协议是公开的，所有基于此协议的客户端都可以互相通讯。同时，Google开源了Libjingle，作为大家开发XMPP客户端来使用， 简单认为是实现了XMPP协议的一个库。

据传说，Google Talk可能也要被关停。WebRTC应该是将来的趋势吧，她复用了libjingle，并将关于XMPP的代码移除了，libjingle中只保留了XMPP相关的代码。这样于libjingle开发XMPP客户端的人，是不是就哭了？改动有点大。貌似这也是Google放弃GTalk的信号啊，代码都不好维护了，只管WebRTC了。

3.PSA: RenderView(Host) is dead; long live RenderFrame(Host)

The work on out-of-process iframes and Site Isolation is progressing well. We’ve gotten to the point that RenderFrame(Host) has replaced the majority of the RenderView(Host) functionality and therefore we shouldn’t be adding any new code or usage of the latter in new code. Please put new code in RenderFrame(Host) or WebContents instead, as explained in our Feature Update FAQ.

以后RenderView(Host)相关的地方，不会再增加代码了，目前大家会看到如下的代码

 FOR_EACH_OBSERVER(RenderViewObserver, render_view_->observers_,
                   DidCommitProvisionalLoad(frame, is_new_navigation));
 FOR_EACH_OBSERVER(RenderFrameObserver, observers_,
                   DidCommitProvisionalLoad(is_new_navigation));

这只是为了兼容、过渡之用，大家要把代码写在RenderFrame(Host) 相关里了。

Site Isolation就是站点隔离，只有同一个站点才能共用一个Render进程。何谓同一个站点呢？

we use a precise definition for a site that we use as a principal: a page’s site includes the scheme and registered domain name, including the public suffix, but ignoring subdomains, port, or path.

这样Cross-Site Navigations、 Cross-Site POST submissions时，只要发现不是同一个Site，就新开一个Render进程。但是为了兼容性和资源占用不太高，Site Isolation做的并不彻底，只对安全性要求较高的站点做了个白名单，打开白名单内站点时、omnibox和 bookmark打开网页时应用了这样的策略。

Out-of-process iframes就是进程外iframes，以前iframe是和主frame在一个Render进程中的，这样iframe就可以访问主frame的资源，如果它俩来自不同的网站，就存在安全隐患了。

比如：

应用之后：

这就是所谓的Same Origin Policy。

可以看出out-of-process iframes通过Site Isolation变为进程之外之后，对cookie、HTML5 stored data、XML, and JSON documents等资源更好的隔离，防止 cross-site访问，增加安全性。

这样的设计导致以前的假设–所有frame都在一个进程，就被打破了。诸如FrameID、计算所有Frame的数量，Frame间的交互全都要变化了。本进程内的称为LocalFrame，进程外的称为RemoteFrame。

这样的改变应该说是挺大的一次架构上的变化，涉及了Chromium和Blink。

三、Tips

1. Identifying the script that creates elements, modifies DOM, etc.

You could use Document::domTreeVersion() to check DOM modification.

2.How to enable MATHML build

Blink doesn’t support MathML unlike WebKit.

More specifically, MathML support was removed from Blink very soon after the fork from WebKit, due to the significant number of security and bug issues with MathML support.

Blink不支持MathML，完全砍掉了。

3.COMPILE_ASSERT vs static_assert

Use static_assert. COMPILE_ASSERT is deprecated and just maps to static_assert anyway, and will ultimately be removed.