Linux 上の WebKit-GTK 2.4.9 で WebKitGTK1 API を使用するアプリがあります。(これは Debian Jessie の現在のバージョンであり、バージョン 2.5 以降は v1 API をサポートしていません。)
ハンドラーを使用して基本的なページ コンテンツ全体を読み込むカスタム URI スキームを実装しました。resource-request-startingハンドラーは着信 URI を解析し、webkit_web_resource_get_uriそれがカスタム スキームと一致する場合は HTML コンテンツを生成し、元の URI を base64 のURIwebkit_network_request_set_uriに置き換える呼び出しを行います。data:レンダリングするコンテンツを含みます。(これは、この質問の受け入れられた回答に似ています。)
これはほとんどうまく機能し、ハンドラーは各リクエスト (同じ元の URI を使用した繰り返しのリクエストを含む) で呼び出され、正しいコンテンツを生成します。生成するデータ URI が異なる場合。
を呼び出した後でもwebkit_web_resource_get_uri元の非 URI を返すことに注意してください。そのため、この URI はキャッシュされていると想定し、実際のURIを使用する代わりに、データをキャッシュするための上位レベルのコンポーネントでキーとして使用されています。リクエストから。data:webkit_network_request_set_uri
残念ながら、これはG_PARAM_CONSTRUCT_ONLYプロパティのようであり、代わりにリクエストの書き換えられた URI を使用するように設定および/またはクリアするパブリック API はないようです。とにかく、構築後にGTKにプロパティを設定させる方法はありますか? 私が知る限り、内部にはセッター メソッドがあり、内部プロパティが NULL にリセットされた場合、ゲッターは Right Thing™ を実行します。
data:または、反対に考えているにもかかわらず、WebKitに新しいURIをレンダリングさせるためのより良い方法はありますか?
今のところ、元のカスタム URI (webkit_web_view_load_uri生成されたページに渡されるか、リンクに渡される) に異なるデータを生成する値を含めることで、この問題を回避しました。これは機能しますが、少し醜く、将来何かを追加するのを忘れた場合、または何かが世代を変更するが事前に知られていない場合に問題になる可能性があります. 間違った URI での URI 比較が原因で、(おそらく) 正しいデータを生成するイベントを発生させるのに苦労して後でそれを破棄するというのは、少しばかげているように思えます。
既知の一意の値 (たとえば、連続してインクリメントする ID) を使用することも機能し、事前に不明な問題のいくつかを解決すると思いますが、それはそれほど醜いことではありません。