2019-06-27

New Firefox Preview for Android

自分はちょうど半年前くらいにGeckoView Team (要はAndroid用のGeckoを作るチーム) に移籍してる。Input Systemとかがメインで (Windows + macOS + Linux は自分と中野さんがやってるのでAndroidがそれに加わったようなもの)、それ以外もいろいろバグ対応とかしてる。

GeckoViewってのはモバイルというかAndroid版の戦略変更によってここ2年くらいMozillaが作ってるもので、フロントエンドのUXさえ作ればいろんなバリエーションのブラウザを作りやすくなるという代物。例えばFirefox Focusようなものや、Firefox Reality、Amazon EchoShowでGeckoベースのブラウザを作ったりするなど、いろいろバリエーションが増やせるようになった。

そもそも従来のAndroidに内蔵するWebViewにはいろんな制限があって、簡単に言えば元となってるChromeと同様のWeb APIをサポートしてるわけではない。だからWebViewを使ったブラウザというのはそのバージョンのChromeと同等ではない。(もし同等なものができるのであれば、ChromeがWebView使ってると思う)。GeckoViewはそうではなくて、Geckoで実現可能なものはすべて使えるようにAPIをいろいろ追加してる

超簡単なブラウザを作るのであれば、mozilla-centralのツリーに入ってるGeckoView Exampleのがサンプルになる。見てみればわかるけど、簡単なものを作るだけであれば、非常に少ないコードでブラウザをつくることができる。またこれだとヒストリ機能とか足りないので、Android Components (a-c)というものを使うことでブラウザをより現代のブラウザらしくつくることができる。なおa-cはGeckoViewじゃなくてもServoとかシステムWebViewとかに対しても動作するようになってる。

ということで従来のFirefox for Android (Fennec)はGeckoViewを使ってるわけでなかったのだけど、このGeckoView版といえるFirefoxがFenixと呼ばれてた、このFirefox Previewになる。

GeckoViewになって一番うれしいことは、やっとマルチプロセスであるということ (今後FissionとかWebRenderもあるので、プロセス数は増えると思う)。そのおかげでパフォーマンスはよくなってるはず。Firefox 68からでもあるけど、aarch64への標準対応もかな?

なお、従来のFennecは68で最後になる。ESRブランチに移行するので、セキュリティ修正等は当分行われる (今のところいつまでは決まってない)。

このFirefox Previewはまだ開発版なので、Tracking ProtectionとかPWAとかWeb Extentionのサポートが欠けてるけど、これは正式版までにははいるはず。要望やバグ報告は、Bugzillaではなくて、githubへ。日本語じゃないと無理であれば、Mozillazine.jpのフォーラムへ投稿してください。見ておきます。

2018-12-10

RIP EdgeHTML. Software lifecycle is difficult

丁度USへ行っている最中にMicrosoft EdgeがChromiumベースになるというニュースが入ってきた。とにかく残念というしかない。

個人的な感覚で言えば、BillGだったらもう少し違ったやり方を行っているだろう。おそらく今止めるって判断をしない (EdgeHTMLを作る前に止めるか、そもそももっとリソースを投入して製品としての品質を上げる。今のEdgeはUXがちょっと中途半端だと思うんだ) 、ナデラはサーバーサイドの人だからそういう判断もするだろうなと。

Internet Explorer / Microsoft Edgeに対していろいろ怨念なことを書いている人は多いけど、この怨念って (Microsoftの強みでもある) プロダクトライフサイクルが原因としか思えないのだよねと思うことが多々あって、ちょっと書きたくなった。

プロダクト・ソフトウェアライフサイクル


従来 (1990年代) のMicrosoftのプロダクトサポートポリシー (≒Hotfixの提供、セキュリティ修正プログラムの提供) はN-1だった (現在のメジャーバージョンと一つ前のバージョンという意味)。これだと一つ前のバージョンのサポートがいつ終わるが明確ではないということで2000年代にちゃんと正確な日付を設定するようになった。Windows 2000以降上に乗るInternet Explorerというのはこのポリシーとはちょっと異なっており、OSに乗ってるバージョン (Windows 2000の場合はInternet Explorer 5.01) と最新バージョンがサポート対象という考えだった。それをみんな (≒社内も含む) 理解しておらずN-1ルールだと思い込んでいて、5.01はサポート終了するから5.5にアップグレードしてれば安全とか顧客に言ってた人たちが「どうにかならないか?」と私とかに交渉しにくるのは多かった。(Sustained Teamと一緒に働いていた関係上) 日本における最終的に泣きつく先が私だったので。なぜこうなっているかはソースコードが誰のオーナーなのかとかビルドラボとかいろんな事情があるんだけど。

またWindows XPも結果として2014年までサポートすることになったが、そもそもリリースされた最初の段階ではそこまでライフサイクルが長い製品になるなんて誰も思ってなかった。次のWindows Vistaのリリースが2006年になったのはLongHornが失敗したのが原因なのだが (LongHornはBuild 4xxxだったのだが、Build 5000を入れたときにWindows XPまんまの画面が出たのは記憶に残ってる)、リリース期間が開いてしまった結果、より多くの環境でWindows XPが使われることになった。またVistaのリリースの頃くらいに、エンタープライズ系の顧客からの要望の結果、サポート期間がWindows XPのEOL (End Of Life。サポート期間の終了) が2014年になるという話になる (このメールを見たときに殺気を覚えたのはいうまでもない。自分のハードディスクからこのソースコード消せないのかと。それよりも先に会社を退職したけど)。

Windows XPのサポート期間の延長の決定がInternet Explorer 6のサポートが2014年になってしまうということに。Webブラウザが13年間サポートされるというこがいかにクレイジーなのか (GNOME 2.0でさえ2002年のリリースだよ!)。もしサポートがWindows 7のリリースと同時に終了してれば、Web開発者はそこまで不満を持たなかっただろう。

Internet Explorer 6に対して標準準拠のことをよく言われるが、1990年代というのは標準化というのは後で付いてくるようなもので、NetscapeやMicrosoftはその相互運用性なんてそこまで考えてはなかった (自分はよくIntranet Explorerという言葉を使ってた。イントラネット環境においての最高なブラウザである意味)。Internet Explorer 6なんてその頃に生まれたような産物で、Netscape/MozillaだってGeckoベースになるまでは標準化なんてそれほど考えてなかった。Internet Explorer 7でいろいろ軌道修正を行っていろんな問題を解決し始めて (7の開発時に本社のInternet Client All Handsに行った時はその話がメインだった)、Internet Explorer 9では非常にトレンドにのった実装になったし、さすがMicrosoftだなと (Internet Explorer 8を作ってる最中に9も同時進行だったんだろうなと推測される)。

また、Webの進化を進めるため、Chromeが仕掛けたラピッドリリースモデルも彼らへの不満を増幅させた要因になった。リリースから2年経過したブラウザの対応が辛い状況を作られれば、Microsoftの従来のやり方だと不満しか残らなくなる。

結果として、Microsoft製ブラウザへの対応をすることへの不満に持つ人が増える。これは完全にプロダクトライフサイクルのせいだろう。

その後、OSに付随するバージョンのInternet ExplorerのサポートはOSと同時に終わるのをやめて最新バージョンのみになったが、決断が遅かった。

EdgeHTML


個人的にEdgeHTMLの一番の判断のミスは、古いOSへのサポートがなかったことだろう。WinRTのサブセットをWindows 7に持ってくるか、二つのOS対応のコードを作ればよかったのでは (MainsoftがInternet Explorer 5に対して行ったようにshimレイヤー作ればよかった。Tridentだって抽象化レイヤーあったのに)。EdgeがWindows 7で動かない以上、Internet Explorer 11へ対応することが求められる。Internet Explorer 11だって2013年のリリースだから5年前。そりゃつらい。

まとめ

Windows 7上でEdgeHTMLが動いて、半年サイクルでMicrosoft Edgeが全OS向けにリリースされていれば、EdgeHTMLをやめるというニュースを喜ぶ人も少なかったのだろうなと思う。Windows Phoneみたくいろんな戦略を間違った結果なんだよね。たらればだけど。ソフトウェアライフサイクルの定義は難しい。

2018-08-22

llvmとrustにおけるWindows/aarch64のサポート

llvm自体には基本的にはWindows/aarch64 (COFF/aarch64) の初期サポートがすでに入っていたのだけど、Unwind InformationとかExceptiion Handlerのサポートは入ってなかった。そのため、C++のコードをコンパイルしようとしても以下のようなInternal Compiler Errorでclangとかがクラッシュする状況だった。
clang version 6.0.1-5 (tags/RELEASE_601/final)
Target: aarch64-pc-windows-msvc
Thread model: posix
InstalledDir: /usr/bin
...
fatal error: error in backend: Funclet EH is not implemented for this target clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 6.0.1-5 (tags/RELEASE_601/final)
Target: aarch64-pc-windows-msvc
Thread model: posix
InstalledDir: /usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test-1a3737.cpp
clang: note: diagnostic msg: /tmp/test-1a3737.sh
clang: note: diagnostic msg:
先月くらいからいろいろLLVMにコードが入り始めており (ex. https://reviews.llvm.org/D49637)、基本的なUnwind Informationとかをllvmが生成できるようになってきている。そのため、rustにもWindows/aarch64対応が入った。ただし、rustup等でインストール可能ではなく、自分でビルドする必要がある。
rustc.exe --target aarch64-pc-windows-msvc -O hello.rs
で生成されたバイナリをみると確かにaarch64のコードが生成されている
Microsoft (R) COFF/PE Dumper Version 14.15.26726.0
Copyright (C) Microsoft Corporation.  All rights reserved.

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
AA64 machine (ARM64)
8 number of sections
5B7D2340 time date stamp Wed Aug 22 19:38:00 2018
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
22 characteristics
Executable
Application can handle large (>2GB) addresses

...

main:
str     lr,[sp,#-0x10]!
mov     x3,x1
adrp    x8,0000000140001000
adrp    x1,anon.4a7df3b253b8104c34e7c5ba0fd9252b.0.llvm.9631437952416841302
sxtw    x2,w0
add     x8,x8,#0x30
add     x1,x1,#0
add     x0,sp,#8
str     x8,[sp,#8]
bl      _ZN3std2rt19lang_start_internal17hac3e63ad7889c515E
ldr     lr,[sp],#0x10
ret
なお、Microsoft Visual Studio 15.8に入っているaarch64アセンブラ (armasm64) はそれ単体だとUnwind Informationを生成できないので、Cプリプロセッサを使ってマクロを読み込んでUnwind Informationを生成しないといけないという面白状態 (それもドキュメントがないのだけど、dotNETとかChakraのコードを読めば理解できる) なのだが、Cプリプロセッサ通さなくてもいいようにしてほしいと願ってる。