ラベル Firefox の投稿を表示しています。 すべての投稿を表示
ラベル Firefox の投稿を表示しています。 すべての投稿を表示

2019年1月24日木曜日

Firefox (nightly)をclang 8 + libc++でbuildする

Firefox (nightly)をmercurialのsource treeからbuildしているのだが、先日Debian experimentalに入ったGCC 9をinstallした時に入ったlibstdc++が原因でbuildできない。ただし、これがlibrary側のbugなのか、それともFirefox側の記述に問題があるのかは切り分けていないため不明。

以前から薄々気付いてはいたのだが、error messageを見るに、LLVM/Clangでbuildした場合でもC/C++ standard libraryとしてGCCに付属するlibstdc++が使われている。GCC 9付属のlibstdc++がだめでも、LLVM/Clangに付属するlibc++なら大丈夫なのでは?と思い実験してみた所無事にbuildできた。

なお、GCC 9とLLVM/Clang 8ではdevelopment stageが異なるのでcodeのmature具合が違っていて当然な点、更にはexperimental packagesにtroubleがつきものなのは当然なので予め申し述べておく。Firefox nightlyのbuildもGCC 8に付属のlibstdc++なら正常にできる。


software environment


* Firefox nightly (Mercurial) → cset 454868:c60e6c0c2e23
* llvm-8:amd64/experimental 1:8~svn351401-1~exp1
* llvm-8-runtime:amd64/experimental 1:8~svn351401-1~exp1
* clang-8:amd64/experimental 1:8~svn351401-1~exp1
* lld-8:amd64/experimental 1:8~svn351401-1~exp1
* libc++-8-dev:amd64/experimental 1:8~svn351401-1~exp1
* libc++1-8:amd64/experimental 1:8~svn351401-1~exp1


build instruction


.mozconfigに以下の記述を行う:

export CC='clang-8 -stdlib=libc++'
export CXX='clang++-8 -stdlib=libc++'
ac_add_options --with-clang-path='/usr/lib/llvm-8/bin/clang'
ac_add_options --with-libclang-path='/usr/lib/llvm-8/lib'
ac_add_options --enable-linker=lld-8
ac_add_options --with-ccache=/usr/bin/ccache

今回の肝は、compilerを指定する最初の2行の"-stdlib=libc++"というoption (ただし、これをclang-8の側 (C++ではなくてC)に適用して良いのか、意味があるのかは不明)。Debian packageのclangはdefaultでlibstdc++ (GCC由来)を使うため、-stdlib optionでlibc++ (LLVM/Clang由来)を使うよう明示する。

また、standard libraryの変更とは直接関係ないが、ついでにFirefoxが用いるlibclangなどのpathを指定し、更にlinkerをbinutilsのldではなくLLVM/Clang由来のlldを用いるよう明示する (ほとんど気分の問題)。

あとはいつも通り:

./mach build

で暫く待つ。


2018年3月3日土曜日

Firefox (やその系列の) web browserでJavaScriptによるcontext menuの禁止を解除する

一部のwebsiteではJavaScriptの機能を応用 (悪用?)してcontext menuを出せないようにしている。今時のwebsiteをまともに閲覧するにはJavaScriptを丸ごとdisableするのも難しい (一応、No Scriptのようなextensionsを入れるという手はある)。

そこで、JavaScriptの機能のうち、context menuを変更するための機能のみをdisableしてみる。

* URL barに"about:config"と入力
* dom.event.contextmenu.enabledを"false"にする

これでJavaScriptによるcontext menuの変更 (禁止含む)を解除できる。

以前はPreferenceの画面にJavaScriptの機能を細かく制御できるoptionがあった気がするが、最近のversionだと無くなっている。


2017年12月4日月曜日

Saka Keyという選択肢

Firefox 57 (Firefox Quantum)ではlegacy extensionsであるVimperatorや (そのalternativeであった)VimFxが押し並べて使えなくなる (cf. http://typeinf-memo.blogspot.com/2017/11/firefox-57-aka-firefox-quantum.html)。以前のentryでalternative browserであるWaterfoxについて紹介した (cf. http://typeinf-memo.blogspot.com/2017/11/keysnail-user-waterfox.html)が、最新のFxに乗り換える場合にはSaka Keyという選択肢がある。

cf. https://github.com/lusakasa/saka-key

Saka Key


Saka KeyはWebExtensions対応なのでFx 57以降も継続して利用可能だ。VimperatorやVimFxほどcustomizeの自由度はないが、差し当たってVi(m)っぽいkeybindでFxを操るには問題ない。

個人的にSaka Keyは設定が簡単 (項目数が多過ぎない、変更方法が直感的)で使いやすいと思う。

一方で、addonの画面など一部のwindowでkeyboard navigationがきかなくなる場合がある (おそらく仕様)のと、history関連にkeyを割り当てられないなどの不便な点もあるので、これから改善されていけば良いなと思った。

Extensionsやcustomizeとの付き合い方


KeySnailとかVimperatorとかがそうなのだが、徹底的にcustomizeできるようにしようと頑張れば頑張るほど、Fxの(公開されていない)深い部分に突っ込むことになり、core側で大きな変更があった場合に対応不能 (或いは全面的なrewrite)になってしまう。そうならないためには、web browserの浅い部分だけをさらっとなぞるだけにする (=WebExtensionsを使う)必要があるが、今度は痒い所に手が届かない (届きにくい)。

変化が早い時代には、好みに基いて徹底したcustomizeを施すよりも、適当な所で妥協して御仕着せのUIに合わせる方が良いのかもしれない (web browserに限らず)。表層だけならどのweb browserも似たようなものだから乗り換えも自由自在だ。

2017年11月6日月曜日

Firefox 57 (aka. Firefox Quantum)がやって来る

Mozilla Firefox 57 (Firefox Quantum)のreleaseが間近に迫っている (2017-11-14)。

既にdeprecatedとされている従来のadd-on (extension)が使えなくなるため、特に以前からのuserは大きな環境の変更を迫られる。

対策は大きく分けて次の通り:

* Firefox ESR 52を使って暫く環境を維持 (〜2018-06-26)
* WebExtensionsに対応した代替を見付けて新しい環境へ移行
* Firefoxから別のweb browserに乗り換える (Firefox系列 / 非Firefox系列)

ESRで暫く繋ぐ


主に企業user向けに提供されているESR版は、新機能の追加や抜本的な変更が (次のreleaseまでは)行われない。最新版であるESR 52は2018-06-26までsecurity updateの対応がなされる。

cf. <https://www.mozilla.jp/business/#esr>

Pros


* Firefox 52をbaseにしているので従来のadd-onも問題なく動く (はず)
* 移行の手間がそれほど掛からない
* 頻繁なupdateから開放される

Cons


* あくまで対症療法であり、何れは移行先を見付けなければならない

WebExtensionsの世界へ移行


今使っているadd-onやthemeなどの必要性や移行先を検討し、新しい環境へと移行する。

Addonやthemeに余りこだわりがないとか、使い始めたばかりで移行すべきものがないとか、customizeを全く/ほとんどしないuserに向いている。

Pros


* 根本的な対策であり今後暫くは継続的に使える環境が構築できる (はず)
* 改良されたFirefoxのuser experienceを満喫できる

Cons


* 様々にcustomizeしていたuserほど手間も時間も掛かる
* 便利に使っていたaddonやお気に入りのthemeの代替が存在しない

同系統のBrowserへ乗り換え


例えば、以下はFirefoxからforkしたbrowsersである:

* Waterfox (cf. <https://www.waterfoxproject.org/>)
* Pale Moon (cf. <https://www.palemoon.org/>)

XULやXPCOMといった技術が引き継がれるので「深い所まで自由にcustomizeできてこそFirefox」という人には向いている。

Pros


* (おそらく) 移行にかかる手間は少なくて済む
* 現在使っているaddonやthemeなどの資産をそのまま使える
* 見た目や操作体系が同じ

Cons


* 枯れた技術が保守されている状況なので大幅な性能の改善は見込めない
* Browserそのものshareが少ない (websiteが正式に対応していなかったりする可能性が高い)

全く別のBrowserへ乗り換え


現在使っているaddonやら何やらの代替が見付からない場合、いっそ全く別のbrowserに乗り換えてもかかる手間は変わらないかもしれない。

* Google Chrome (或いはChromium)
* Microsoft Edge (Microsoft Windowsのみ)
* Apple Safari (Apple macOS, iOSのみ)
* Opera
* Vivaldi
* Brave
* etc, etc ...

特にChromeはuser数が多くextensionsも充実している (と考えられる)。

Pros


* BrowserはFirefoxだけではないと分かる
* 真っ新な環境から始められる

Cons


* 検討すべき候補がありすぎて選ぶのに手間取る
* これまでの操作体系とかなり異なる場合慣れに時間がかかる
* 移行に手間がかかる (かもしれない)

2017年1月8日日曜日

Debian unstableでFirefox 50.1.1 (release)とFirefox 52.0a2 (aurora)のbuildが失敗する

2017-01-18追記: Firefox 51.0で修正されbuild可能になった

Debian unstableでFxをsourceからbuildするとconfigureの段階で転ける。

> cannot determine icu version number from uvernum.h header file

libicu関連。いつからだったのか分からないが、libicuのversion情報が取得できないせい (因みにunstableが57でexperimentalが58。stableは55)。

firefox-release (50.1.1)は56にdependしており、firefox-aurora (52.0a2)は58にdependしている。何れもsystemにinstallされているlibicuを見付けられず、そこでbuildが止まる。

取り敢えずworkaroundを発見したので暫く様子見。

firefox-aurora


experimentalのlibicu58関連にupgrade。libicu57は別の色々なpackagesがdependしているのでそのまま。

build/autoconf/icu.m4を変更 (72行あたり):

    version=`sed -n 's/^[[:space:]]*#[[:space:]]*define[[:space:]][[:space:]]*U_ICU_VERSION_MAJOR_NUM[[:space:]][[:space:]]*\([0-9][0-9]*\)[[:space:]]*$/\1/p' "$icudir/common/unicode/uvernum.h"`

↓

    version="58"

icuのversionを調べるscriptが何故か失敗する (consoleでやると上手くいくのだが)ので、versionを決め打ちする (この場合はexperimentalの58)。

firefox-auroraについてはこれだけでbuildが通る。

firefox-release


firefox-release (50.1.1)は少々面倒:

* build/autoconf/icu.m4を変更 (versionを58で決め打ち)
* cp -i /usr/include/unicode/uvernum.h /usr/include/unicode/uversion.h intl/icu/source/common/unicode/ → localで持っているversionが古いのでsystemのlibicu58を使う (一応のため)
* cp -i /firefox-aurora/config/external/icu/data/icudt58l.dat config/external/icu/data/ → icudt58l.datが無いとbuildが転けるのでauroraの(libicu58用)をcopyしておく

これで取り敢えず./mach buildが通って、./mach runで動いた。ミソは多分icudt58l.datをauroraから貰って来る所だと思う。