Rockridgeのブックマーク - はてなブックマーク

なかのんの旅々(Masayuki Nakano) on Twitter: "Firefox Nightlyで"Slow Tracking Elements"を"Always"にすると笑えるぐらいにページの読み込みが高速化するな。Geckoの速度自体よりも、アクセス解析のGecko利用時のパスの遅さに問題があるのかよく分かる。"

Firefox Nightlyで"Slow Tracking Elements"を"Always"にすると笑えるぐらいにページの読み込みが高速化するな。Geckoの速度自体よりも、アクセス解析のGecko利用時のパスの遅さに問題があるのかよく分かる。

Rockridge 2018/08/19

Firefox Nightly 63で、Content Blocking（旧トラッキング防止）を有効化し、"Slow Tracking Elements"を"Always block"に設定すると、Webページの読み込みが高速化する。

Perf

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "XULアドオンって色んなタイミングを捕まえられるように、さまざまなobserverになり得たんだけど、これってmutation event listenerが大量にあるイメージで、呼び出し時にセキュリティを確保しつつ安全に全obs… https://t.co/t9Yyo8XGPf"

Rockridge 2018/06/10

XULアドオンの仕組みを維持することが、Firefoxのパフォーマンス向上の妨げとなる一例。

Perf

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "ユーザがサイトごとに、Webアプリによる、ブラウザのショートカットキーの横取りを許可・不許可に出来るようになりました。 https://t.co/FbqIuRqSPG #もずでぶ"

ユーザがサイトごとに、Webアプリによる、ブラウザのショートカットキーの横取りを許可・不許可に出来るようになりました。 https://t.co/FbqIuRqSPG #もずでぶ

Rockridge 2017/11/13

Fx58：「ユーザがサイトごとに、Webアプリによる、ブラウザのショートカットキーの横取りを許可・不許可に出来るようになりました」。参照：https://bugzilla.mozilla.org/show_bug.cgi?id=380637

Gecko

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "XULアドオンの維持の難しさの原因は、XULアドオンが本当に「直接」Geckoの各種機能にアクセスできたからなので、XULアドオン廃止に伴ってXPCOMオブジェクトの廃止や整理で高速化していくGeckoとのコードに古いXPCOMオブジェクトを存在させ続けるのは難しい。"

Rockridge 2017/09/28

「XULアドオン廃止に伴ってXPCOMオブジェクトの廃止や整理で高速化していくGeckoのコードに古いXPCOMオブジェクトを存在させ続けるのは難しい」。Thunderbirdプロジェクトはまさにこの苦難に直面している。

Gecko

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "accessibility.force_disabledを1にしてリンクの多いDXRみたいなページで極端にパフォーマンス上がるなら、a11yツールがFirefoxのパフォーマンスを落としてます。"

Rockridge 2017/09/22

about:configからaccessibility.force_disabledの値を1に変更すると、アクセシビリティツールが無効化される結果、リンクの多いページでFirefoxのパフォーマンスが向上する場合があるそうだ。

Perf

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "ただ、古いソフトなので古くからあるアプリとの互換性を保つために色々と個別のハックがあるのはつらそうなところ。言って良いのか分からないけど、個人的なパイプで、Firefox向けのハックを2017でざっくりと削除してもらって、50あたりからFirefoxの責任で動くようにしてもらった"

Rockridge 2017/06/03

ATOK 2017では、Mozillaサイドの要請に応えてFirefox向けのハックを削除。現在のFirefoxリリース版/ESRはFirefox側でATOKの挙動との調整を図っている。なのでATOK・Firefoxともに最新版を使うのがよさそうだ。

Gecko

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "DOMイベント周りは私も頑張って、地獄感がかなり減ったけど、contenteditableはかなりの地獄よ? (現Gecko Editorモジュールオーナー談"

Rockridge 2017/05/03

contenteditableは仕様が未熟なのでアプリに実装するならブラウザベンダと緊密に連絡をとる方がよく、覚悟が必要で責任も伴うという。参照：https://twitter.com/d_toybox/status/859420577513086976 https://twitter.com/d_toybox/status/859422316006182912

HTML

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "とりあえず、色々と検討した結果、現状ではメイリオが利用できるならメイリオ、(Windowsに日本語パック入れていない等で)できないなら、游ゴシックにフォールバックという形で行こうかと考えています。 #もずでぶ"

Rockridge 2017/03/28

Windows版Firefoxのデフォルト日本語フォント変更の件は、メイリオが利用できるならメイリオ、できないなら游ゴシックにフォールバックという形になるそうだ。

Firefox

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "なので、Firefoxって、 * 1.0まで * 1.5から2.0 * 3.0 * 4.0以降で統括してる人が違うんで色々と変わってるし、ラピッドリリースのせいでよく分からないけど、4.0以降も途中で何度かマネージャ変わってる。"

Rockridge 2017/03/12

Firefox 4.0ころまでは製品の方針を決めるプロダクトマネージャがいましたが、ラピッドリリースに入ってからはリリース管理に徹するリリースマネージャだけがいる印象です。しかも個人から集団に移行していますね。

RelEng

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "@rockridge07 個別にこういうAPI追加してくれっていうリクエストじゃなくて、UIを構成してるDOMに直接アクセスさせろっていうリクエストなんで筋が悪いですね。それを許可してたから互換問題やら、パフォーマンスの問題やら、メンテナンス性の問題があったんで。"

Rockridge 2017/03/09

Classic Theme Restorerの作者の要望が通らなかったのは、「UIを構成してるDOMに直接アクセスさせろ」という筋の悪い内容だったから。

webext

リンク

なかのんの旅々(Masayuki Nakano) on Twitter: "今の所、Win8.1以降なら游ゴシック、Win7ならメイリオで攻めて見ても良いんじゃないかって気がしてる。フォントメトリックスで見ても、メイリオよりも游ゴシックの方が(多少は)MS Pゴシックに近い。あとはChromeとの互換性だと思う。"

Rockridge 2017/03/09

Windows版Firefoxのデフォルト日本語フォントが変わるかもという話。変わる場合、Chromeのようにメイリオで統一するか、Windows 7はメイリオ、8.1以降は游ゴシックに分ける案が有力。参照：https://bugzilla.mozilla.org/show_bug.cgi?id=548311