Chat Channels of Web Engine

メジャーブラウザを作っている三者 (Apple、Google、Mozilla) は知ってる限り、各ブラウザプロジェクト用チャットチャンネルを持っている。FreenodeにChromiumとWebKitのチャンネルはあるのだけど、実際そんなに使われているわけではなくて、別のものを使っている。AppleとGoogleはSlackに、MozillaはMatrix上に存在する。Mozillaも社内向けには別のチャンネルがあるし、ずっとIRCサーバーを運用してたのだけど、最近Matrixに移行した

Chromium

https://chromium.slack.com/。chromium.orgアカウントを持っているとか、彼らにとってのパートナー会社であれば、Slackのチャットサーバーに入ることはできる [*]

Gecko

https://chat.mozilla.org/。githubアカウントでもFirefoxアカウントでも入ることが可能

WebKit

https://webkit.slack.com/。https://webkit.org/getting-started/に招待リンクがあるから、そこから入ることはできる

メモとして残しておく

safe-area-insets が本当に使われているとは思えない

Webの仕様はいろんな議論の末にできるものではあるけれど、ある種の企業の都合が発生する場合はそうではない。例えばノッチがついたデバイスがリリースされることが決まった場合、ノッチをどうWebの仕様で盛り込むか？と考えた時、企業の都合 (iPhone Xのリリース日までにはどうにかしたいとか) が多々発生するし、そういうことに依存した仕様ってのは実装も含めて適当なことがたまにある。

ノッチ部分を除いた表示エリアを定義できるsafe-area-insetsというものがCSS Environment Variables Module Level 1で定義されてるのだが、これについてWebKit Blogで、Designing Websites for iPhone Xで解説されている。ようはノッチが含まれないエリアをマージンなどで指定すれば、ノッチのエリアにコンテンツが配置されないようにできる機能。

これがBlinkでの実装がどうなるかというと、フルスクリーン表示のみこのsafe-area-insetsが適用される模様で、WebKitのようにデバイスを回転した場合にちゃんと適用されるわけではない模様。動作をテストする限り、彼らはこれはフルスクリーンでのみ適用するような実装をしてしまってる。

また、Android特有の話にはなるのだけど、フルスクリーン表示をしようとして、 System UI visibilityを変更しようとしても、ちゃんと色々考慮しないとデバイスによってはちゃんとステータスバーが簡単に消えないものがあったりする。Blinkは、もしこのステータスバーが消えてなかったとしても、safe-area-insetsが適用してしまうようで、WebKit Blogのようなサイトを作ったとしても、ノッチとは関係ない変な空白ができてしまうことになる。(OPPO A5とGalaxy S10でテストした限り、間抜けな感じになる。これらでテストする限り、ステータスバーが消えない)

だからこのsafe-area-instes、これがマトモに使われてるとは思えない。無駄な空白が空いてしまうし、フルスクリーンではない時に逆にノッチ領域を除外できないし。一番使われているであろうWebブラウザでね。

それよりも当然バグとして報告はしてあるんだけど、バグと認めさせる (=というよりも、まずフルスクリーンの時にステータスバーが消えてないのがまず大きな問題の一つ) のは面倒ではあったけど、おそらくすぐ直るとは思ってないから、この動作大丈夫なのと本当に思ってる。

なお、Firefox Previewはviewport-fit値はまだ見てないけど、Firefox Preview NightlyであればWebKit Blogのサンプルはちゃんと動作するはず。

WebKitとBlinkのスタンスの違い

最近WebKitとBlinkの実装が異なってることでいろいろ困っているんですが、その話はさておき、WebKitのスタンスが明確にわかるようなメールスレッドが最近あった。

Web NFCのエディタのFrançois Beaufort (Google)がWebKitサイドへWeb NFCについての意見を聞きたいということで、webkit-devにメールを投げたのだけど、そのお話。

メールスレッドはこれ。
https://lists.webkit.org/pipermail/webkit-dev/2020-January/031006.html

事実上WebKitトップのMaciejが、

We do not believe a permission prompt is a sufficient mitigation for the serious security and privacy risks raised by this specification.

という話を出ししてて、まぁプロンプト程度で有効にするしないで決められるようなAPIはおそらく実装されることはないんだろうなと

In addition, we think exposing direct hardware access to the web is a bad idea and compromises the device-independence of the web platform.

ということで、WebKitに関しては基本的にデバイスを触るようなAPIは(よほどのユーズケースがない限り)実装されるのはほぼないようだ。

なお、出来レースなんだろうなという感の強いblink-devへのIntent to experimentは全くこういう話を語られることはないし、LGTMとしか反応がない感強いし、もし議論があったとしてもたぶんpublicな場で議論することはないんだろうなと。

webkit-devでは、とどめにniwaさんに、

I'll go off a bit on a tangent and say that one of the primary strengths of the Web is that users can visit any website without the fear of their computing devices being permanently compromised

というように、"Web" というものの利点が語られて、

If we continue this path, at some point (or maybe we're already there), the Web will turn into any other non-Web platform where ordinary users can (or are advised to) only use well known trusted applications or visit well known trusted websites just like how native apps work today.

言われてて、WebKitの考えるWebの利点と反するようなものはWebKitでは実装されないのだろうとわかる。

いろいろなMeet upでたまにDevice API系の話 (WebUSBとかWebMIDIとか) をする人を見かけるけど、WebKitがこんな感じなのでWICGとかを抜けて標準化に持ってくもの (≒2つのエンジンの合意) はほぼなさげだよなと (Mozillaはプライバシー問題が解決されないものは基本実装されない感じ)

自分用async / await functionsメモ

Firefox / SpiderMonkey

Bug 1185106 - Implement async functions (ES7 proposal)

もともとインターンがオーナーだったけど、araiさんが直してる

Safari / JavaScript Core

Bug 156147 - [JSC] implement async functions proposal

IgaliaのCaitlinが書いた。でConstさんがReviwer

Chrome / V8

Issue 4483 - V8 - Feature Request: Support async/await functions

InitialコードはIgaliaのCaitlinが書いた。でも今はGoogle自身で直してる。

How to add API status to Firefox Platform Status

ChromeやEdge、WebKit (決してSafariではない) に続き、Firefoxもステータスページを作った。

MDNにも対応情報はあるがこれの情報はMDNと同期してるわけではない。また、例えばChrome Statusとかcaniuseには載っているけど、FirefoxのStatusにおなじ情報がないってのもある。

ただ当然のことならが、githubにこのコンテンツ用のレポジトリが存在してて、issueを立てたりPull Requestを送ることで、ここに項目を追加したり情報を修正することは可能になってる。実際features配下へマークダウンファイルを追加することで項目を追加できる (実際、実装やってたAPIのIssue投げたらPull Request投げろって言われて投げた)。詳細はCONTRIBUTING.mdに書いてある。

なお、Chrome Statusは、https://omahaproxy.appspot.com/からJSONとかでも取得できる。

何か情報が間違ってれば、WebKit以外は以下のgithubでissueとかを投げられるし、WebKitもhttps://bugs.webkit.org/に投げれば拾ってくれるはず。

• Chrome ... https://github.com/GoogleChrome/chromium-dashboard/
• Edge ... https://github.com/MicrosoftEdge/Status
• Firefox ... https://github.com/mozilla/platatus/

Adobeが行っている各ブラウザへのコントリビューション

Microsoft EdgeでAdobeがコードの貢献をしたという話があったのだけど、これを見て、EdgeはAdobe、Microsoft連合だ思っている人が多いみたいなので、Adobeが各ベンダに対してやってることを書こうかと。

まず、彼らはSVGとかCSSとかの仕様への貢献をずっと行っていて、SVGの場合ではSVGWGのFace to Faceミーティングの場所を毎年貸し出したりしてる（シアトルのオフィスがそれ）。

そもそもAdobe自体はいろいろとWebに対しても行っているのだけど、彼らにとって、仕様の貢献を行っていても実際ブラウザベンダが実装しない限り絵に書いた餅でしかないので、彼らが必要と思っている(関わっている)仕様に関しては実装まで手を出しているってのがここ数年の状況だ。

Geckoサイドでいうと、CSS Filtersは彼らの貢献なしでは実装が進まなかったというか、その部分に関しては彼らがコード書いている。

WebKitだとCSS ExclusionsとかCSS FiltersとかCSS Regionsらへんが絡んでる。(Feature FlagをAppleがOnにしないとSafariとかで使えないけどね)

BlinkだとBlendingとかCSS Sharpesとか

このようにAdobeという会社は各ベンダーのエンジンに対してコードを書いてたりする。自分たちが必要だから仕様を策定しているのだから、そりゃ当然実装にも手を出すよねってこと。Microsoftの件はそれがOSSでなかったとしても手を出し始めたということだね。

基本的にAdobeのブログとかで触れられるCSSとかの仕様・技術の話は彼らが仕様策定に絡んでいたり、実装を行っていたりするものなので、そういう視点でブログを読むとより楽しく感じる思う。

ちなみにAdobeのMozillaへの貢献としてTamarinというJITエンジンの話を出す人がいるけど、あれパフォーマンス出なくてGeckoへ統合されなかったものなんだよね。しかもその後、現Mozilla CTOのGalがほぼ一人で書いたTracing JITのほうが遥かに速かったというオチまでついた。(JavaVMへのTracing JITの実装を大学でやってた時にBrendanに引きぬかれたのがMozillaに来たきっかけだった記憶がある）

WebView Hell

現在の（ちゃんと開発されている）OSってのは、だいたいが組み込みのHTMLレンダリングエンジンを持っていたりする。こういう流れは、Internet Explorer 3以降やAppleのCyberDog (誰も知らないと思うけど) が最初だと記憶してるけどね。iOSのおかげでWebViewという表現がよく使われるのでWebViewって言葉を使って書いてる。

Trident

独禁法の裁判でもOSなのかアプリなのかという点で争ったこともあるけど、現在の判断だとOSという判断で差し控えないと思う。Internet Explorer 4にShell Update (Active Desktopと呼んでたけど) が含まれていた関係上シェルの動作に支障がきたすことがあったが、このShell Updateをインストールしなかったとしてもいろんな問題が生じてた。

例えばOS初回起動時に表示される"ようこそ画面"はHTMLで書かれてて、HTML Component (HTC)を使って動いていたのだけど、これがInternet Explorerのバージョンアップでスクリプトエラーになるとか、OS側でWebViewを使ってるコードは結構問題を引き起こしてた。(Windows 2000以降のExplorerのビューもHTML使っててみたいな話があってだな、動作が変わってしまう機能が存在してた)

OSとWeb Browserは切り離してバージョンアップ可能な仕組みを持ってたのにも関わらず、OSモジュールとしてメンテナンスされている古いバージョンのモジュールを残す仕組みを持っていないためにいろんな問題を引き起こしてた。Windows XP移行は Side-by-Side (SxS) が導入されているので古いバージョンのモジュールを残すことはできるようにはなったけど、Internet Explorerはいまだにこれを利用してない (はず)。

その変わりといってはなんだけど、Shellに関するモジュールだけはInternet Explorer 7以降ではアップデートしないような構造にはなった (IEFRAME.DLLというバカでかいモジュールがその役目)。

レンダリングエンジンが変わってしまうってところに関しては解消されなかったけどね。

そんな感じでOS内蔵のレンダリングエンジンをOSとは別にアップデート可能にするといろんな問題を引き起こすのをMicrosoftは証明したわけだ。

Chrome + blink

Android上で利用できるWebViewはシステム組み込みのものを利用することになっている。これがAndroid 4.4からは独自WebKitベースのものからChromeのBlinkベースに変わりはするけども同じような問題を持つ。標準ブラウザがChromeになるっぽいってことからこれで非互換からおさらばできるって考えてる人が結構いるみたいなんだけど、それは無理だと思う。それはChromeのバージョンアップがシステムのWebViewのバージョンアップを含めることができるかどうかなんだ。

そもそもアプリケーションパッケージのインストール機構でOSのファイルを置換できる仕組みをGoogleは取らないだろうし、一つのアプリケーション (この例でいえばChrome) のバージョンアップでシステムのフラッシュに入ってるモジュールを置換できるような方式をとることができることを許すとなれば、それはある種の脱獄の穴を作ることになる。Playストアからアップデートさせるんじゃなくて、6週間ごとに新バージョンのChromeを含む新しいシステムアップデートが全端末にOTAされるとかって方式になるんだったら、その限りではないけどね！。

また一番重要なのはシステムのWebViewはChromeベースになったとしてもその使ってるコードはおそらくベンダがカスタマイズしたコードでしかなくなる。そのカスタマイズさがフラグメントの理由になるんだ。しかもApache 2とかBSDライセンスだと変更点は公開する必要がないから変更点はベンダしか知らないからブラックボックスでしかない。しかも独自のバグがあってもそれはGoogleがやったことではないからGoogleが直せないんだ。

だからハッピーになるかと言えば、まぁならないんじゃないかな？。回避策はえっと、Android認証のテストツールにBlinkのテストツールをすべてパスするようなことを要求するしかないんじゃない？そうすればマシになると思うよ。

Firefox OS

OSとブラウザが完全統合されている場合で一番いい例がFirefox OSになると思うからそこも最後に書く。

個人的にはFirefox OSはフラグメントはAndroidほどひどいものは起きないと予測してる。なぜかというとGecko部分のソースコードはMPL2ライセンスであるってこと。MPL2だとソースコードの変更点は要求があれば公開しないといけない。各ベンダでカスタマイズってのは今後起きるとは思うけど、変更点がわかる以上ブラックボックス化しないから、どうにか対処可能じゃないかと。

もちろんフラグメントは起きるだろうけど、Androidほどはひどくならないんじゃないかな。まぁ今後はどうなるかは興味ある。

Blink

BlinkというWebKitフォークの話がやってきた。Googleにはエイプリールフールに発表してほしかったね。イースターで祝日だからしょうがないか。

GoogleのWebKitにまつわる話は2010年くらいにマウンテンビューで聞いたことがあるんだけど、Chromeチームはマージに非常に苦労しているという印象だった。だからフォークしてしまうってのはGoogleにとっては非常に正しい判断なんだろうなとは思うし、Googleの抱えている人の数からしてみればWebKitに固執する必要はなく、新しいレンダリングエンジンを投入するだろうなとは思ってたから、一年遅いなってのも印象でもある。

それよりもだ。興味があるのはレンダリングエンジンとかじゃなくて、WebKitというオープンソースプロジェクトの今後だ。実際WebKitはいろんな人たちが関わっているプロジェクトではあるけれど、Googleのチェックイン数が群を抜いてるものでもある。そこからGoogleが抜けることになるとは思うんだけど、ここからWebKit発のイノベーションが消えてしまうのかどうかが気になるところ。今後AppleとかSamsungがどうこのプロジェクトをドライブするのかが見もの。

WebKitは企業がOSSに参加しているものとしていい代表例の一つでもあったとは思うんだけど、実質企業コントロール化されたOSSプロジェクトがメインスポンサーを失うとどうなるのかといういい例になる気がしてる。MeeGoとかも末路はね。。。(Tizenは後継と言ってるけど、実際のところほとんどのコードを破棄してプロジェクトの新規作成に近いので後継と言う表現は間違ってると思う)

FirefoxというかGecko自体も (レイオフの結果) Netscapeというメインスポンサーが抜けた後、現在の形 (Mozilla FoundationからMozilla Foundation / Corporationという形) になるまで非常に苦労をしたわけだし。

あと、ここはLunascapeあたりにWebKitとBlink内蔵ブラウザを期待するんで頑張ってね。BlinkはAPI固まらなそうでChromium以外は苦労しそうだけどさ。