タグ

ブックマーク / wontfix.blogspot.com (7)

  • OSのIME関連APIとWebブラウザは相性が悪い

    Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. 今どきのWebブラウザは複数のプロセスで動くことが前提になっている。Chromeで言えば、メイン(UI)プロセスとレンダラープロセス。Firefox用語であればChromeプロセスとコンテンツプロセスという感じで別れて動作している。Webコンテンツはコンテンツ用のプロセスで表示され、文字入力はUI用プロセスで動作している。だから入力された文字はコンテンツ用のプロセスへプロセス間通信で送られ、コンテンツ用プロセスで内部的に描画されるいることになる (実際に画面上に描画されるのがGPUプロセスだったりUIプロセスだったりするけど)。 今どきのOSで使われるIMEのためのAPIは入力された文字をただアプリケーションに渡すだけではなく、様々なことを要求してくる

  • Chat Channels of Web Engine

    2023 (7) ► 05 (1) ► 04 (1) ► 03 (4) ► 01 (1) ► 2022 (3) ► 12 (1) ► 06 (1) ► 05 (1) ► 2021 (9) ► 12 (1) ► 11 (1) ► 10 (1) ► 09 (1) ► 07 (1) ► 06 (1) ► 05 (3) ▼ 2020 (13) ► 12 (1) ► 11 (2) ► 10 (1) ▼ 09 (2) Chat Channels of Web Engine IS_PRIVATE on Windows 10 20H1 ► 08 (1) ► 06 (1) ► 04 (2) ► 03 (1) ► 02 (1) ► 01 (1) ► 2019 (1) ► 06 (1) ► 2018 (6) ► 12 (1) ► 08 (1) ► 07 (2) ► 02 (1) ► 01 (1) ► 201

  • Edge/ARM64の出来をみると、Windows on ARMのx86エミュレーターは結構速い

    Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. WebCrypto APIのベンチマークというのは結構難しくて、そもそも現在のWebCrypto APIはPromiseベースの実装のため、下手をするとWebブラウザに実装されたマイクロタスクをテストするだけのものになることもある (≒なのでベンチマークを取るとったとしても正確なデータかというと、、、な時がある。WebCryptoを使ったベンチマークを説明する時にPromiseの話を触れない人は正しいマイクロベンチマークを書くことが出来ない人なのかもしれない)。Promiseで結果を返すようなAPIはベンチマークが正しい結果を出すとは限らないのだが、それを抜きにしても面白いデータが取れたのでここに書いておく。 jsperf.comに簡単なWeb Cry

    Edge/ARM64の出来をみると、Windows on ARMのx86エミュレーターは結構速い
  • Firefox Nightlyで位置情報プロバイダがGoogleからMozillaに変更になった

    Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. ブラウザ内で位置情報を取得する際、FirefoxではGeoIPとWiFi情報から位置情報を決定している。従来のFirefoxではGoogleの位置情報APIを利用していたのだが、先週末のFirefox NightlyからGoogleの位置情報APIではなくて、Mozilla自身の位置情報APIを使うように変わった。 Mozillaの位置情報サービスはMozilla Location Servicesという名前で開発を行っていて、GoogleAPI互換かつ、サーバーなどのソース、収集されたデータさえも公開されている。(細かい話は以前書いたエントリを参照のこと。) ここで参照されるデータというのは、以下のアプリで収集されたものがベースになっている。 Mo

    raimon49
    raimon49 2015/02/01
    Google API互換の独自リソースへ。これは知らなかった。
  • WebView Hell

    Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. 現在の(ちゃんと開発されている)OSってのは、だいたいが組み込みのHTMLレンダリングエンジンを持っていたりする。こういう流れは、Internet Explorer 3以降やAppleのCyberDog (誰も知らないと思うけど) が最初だと記憶してるけどね。iOSのおかげでWebViewという表現がよく使われるのでWebViewって言葉を使って書いてる。 Trident独禁法の裁判でもOSなのかアプリなのかという点で争ったこともあるけど、現在の判断だとOSという判断で差し控えないと思う。Internet Explorer 4にShell Update (Active Desktopと呼んでたけど) が含まれていた関係上シェルの動作に支障がきたすことが

    raimon49
    raimon49 2013/12/23
    WebViewの断片化 かつてIEが通って来た道
  • Googleが抜けた後のWebKit

    Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. 久々にwebkit-dev見てたら、こんなメールがあったりしてウケた。差出人はAppleの中の人ね。 Hi WebKittens, I’d like to propose removing the Pointer Lock API code from WebKit. The code hasn’t been touched for 12 months, and AFAICT no ports are building with ENABLE(POINTER_LOCK). Is anyone currently building (and shipping / planning to ship) this API? Other thoughts? -Kl

  • Mercurialでのブランチ

    Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. まぁ、自分がMercurialユーザーだったらvim-jpの記事を読んで間違いに気づくはずだ。 まず、Mercurialでのブランチというのはどういうものが理解すべき。Mercurialでは、ブランチというのは、一種のtagとheadsの総称でしかない。gitだとローカルブランチとリモートブランチという概念があって、ブランチをpushするときには、特別な方法を取る必要があるけど、mercurialの場合は通常のpushに自分で作ったブランチが含まれてしまう (もちろんheadsが合わなければリジェクトされるし、明示的にブランチへのpushを使う必要もある)。 だから、多数での開発をしてる際に自分のコードを管理するためにブランチを作るのはよくない。Mer

    raimon49
    raimon49 2011/10/03
    Mercurialでのローカルブランチングは専らcloneばっかりやってたけど、そろそろmq覚えよう。
  • 1