旧ページに設置してたGeckoDev
Wikiに書いたもので気合が入ってたのだけをサルベージ。情報としては大変古い（たぶん2008年くらいまでの情報）。今思えばなんだか間違ってる記述
もあり。
Embeddingなどで引っかかったところを書いていきます。
nsIProfile::SetCurrentProfileでNS_ERROR_FAILUREが帰ってくる問題。
http://mxr.mozilla.org/mozilla1.8/source/profile/src/nsProfile.cpp#1291
Mozilla1.8系ではnsIPrefConverterのdo_GetServiceが失敗していることが原因。 prefs.converted-to-utf8をtrueにしておくことでとりあえず回避できるが、根本的な解決にはなっていない気がする。 Gecko1.9ではnsIPrefConverterが呼ばれていないようだ。もしかしたら原因が違うのかも。
Prompt(nsIDOMWindow *aParent, const PRUnichar *aDialogTitle, const PRUnichar *aText, PRUnichar **aValue, const PRUnichar *aCheckMsg, PRBool *aCheckState, PRBool *_retval)
のaCheckStateはたいていNULLなので、NS_ENSURE_ARG_POINTER(aCheckState);とかやってるとはま る。
Windowsではwchar_tとPRUnicharは2バイトなので問題ありませんが、Linuxではwchar_tは4バイトなので、そのま まキャストしても使えません。iconv(3)で変換してやる必要があります。
http://mxr.mozilla.org/seamonkey/source/layout/generic/nsBlockFrame.h
ブロック・インラインフレームのための基本となるクラス。
ブロックフレームは、絶対配置されたフレームを保持する名前付きリスト（Absolute-list）を持っている。
@see nsGkAtoms::absoluteList
<browser>要素のコンストラクタで、pageshow イベントのイベントハンドラを登録する。
onPageShow でattachFormFill()を呼ぶ。
attachFormFill()は 以下のとおり。
if (!this.mFormFillAttached && this.hasAttribute("autocompletepopup")) {
// hoop up the form fill autocomplete controller
var controller = Components.classes["@mozilla.org/satchel/form-fill-controller;1"].
getService(Components.interfaces.nsIFormFillController);
var popup = document.getElementById(this.getAttribute("autocompletepopup"));
if (popup) {
controller.attachToBrowser(this.docShell, popup.QueryInterface(Components.interfaces.nsIAutoCompletePopup));
this.mFormFillAttached = true;
}
}
まだFormFillControllerがattachされていなくて、autocompletepopup属性が設定されてい る<browser>に対してattachが行われる。attachToBrowser のIDL定義は次のとおり。
/*
* Start controlling form fill behavior for the given browser
*
* @param docShell - The docShell to attach to
* @param popup - The popup to show when autocomplete results are available
*/
void attachToBrowser(in nsIDocShell docShell, in nsIAutoCompletePopup popup);
nsIAutoCompletePopupってなんじゃらほい。引き続き読み進む。nsFormFillController.cppに 実際のattachToBrowserがある。ここでDocShellからDOMWindowを得て、DOMWindowのfocus, blur, pagehide, mousedown, click, input, unload, compositionstart, compositionend, contextmenuイベントを監視する。DOMWindow でfocusイベントが発生すると、イベントの発生元がinput type="text"であるかどうかを調べ、かつautocompleteがoffになっていないことを確かめる。そして、StartControllingInputを 呼ぶ。StartControllingInputでは、inputが属するDocShellに対応するPopupをｍFocusedPopupにセット し、キー入力の監視を開始する。また、mControllerにinputをセットする。Inputイベントが発生すると、mControllerのHandleText関 数が呼ばれる。HandleTextは、テキストのいかなる変更が加えられたときに呼ばれるものである。HandleText内で、いろいろな条件を満た すと、StartSearchTimerが 呼ばれ、タイマーがスタートする。タイマーが発動すると、nsAutoCompleteController::Notifyが 呼ばれる。ここでやっとStartSearch()が 呼ばれる。検索が開始され、成功するとonSearchResultイ ベントが発生する。検索結果はProseccResultで 処理される。
眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い眠い
event.targetを見ているだけでは、<a href="hoge"><span>ｽﾊﾟｰﾝ?</span></a>という感じのリンクに対応できない ので、以下のようにする必要がある。window.addEventListenerで"click"を監視しておくこと。監視の方法はnominaまとめの コードを参照。XLink未対応。
//evtはnsIDOMEvent
nsCOMPtr<nsIDOMMouseEvent> mevt = do_QueryInterface(evt);
if(!mevt) return;
PRUint16 mouse;
mevt->GetButton(&mouse);
if(mouse!=1) return; //1ならば中ボタン
nsCOMPtr<nsIDOMEventTarget> tgt;
evt->GetTarget(getter_AddRefs(tgt));
if(!tgt) return;
nsCOMPtr<nsIDOMNode> node = do_QueryInterface(tgt);
if(!node) return;
nsCOMPtr<nsIDOMHTMLAnchorElement> anchor;
nsCOMPtr<nsIDOMHTMLAreaElement> area;
while(node){
anchor = do_QueryInterface(node);
if(anchor) break;
area = do_QueryInterface(node);
if(area) break;
nsCOMPtr<nsIDOMNode> tmp;
node->GetParentNode(getter_AddRefs(tmp));
node = tmp;
}
if(!anchor && !area) return;
nsEmbedString href;
if(anchor){
PRBool retval;
anchor->HasAttribute(NS_LITERAL_STRING("name"),&retval);
if(retval) return;
anchor->GetHref(href);
}
else if(area)
area->GetHref(href);
//ここまで来たらhrefにURIが入っている
| 機能名 | インターフェース |
|---|---|
| 広告ブロック | nsIContentPolicy |
| ブラウザウィンドウごとの画像・プラグイン等読み込み制御 | nsIWebBrowserSetup・nsIDocShell |
| 文字の大きさ変更 | nsIMarkupDocumentViewer |
| 文字エンコーディング変更 | nsIMarkupDocumentViewer |
| DOMノードのある位置までスクロール | nsIMarkupDocumentViewer |
| 戻る履歴の保存・再現 | nsISHistory |
| JavaScriptのロード | mozIJSSubScriptLoader |
| ユーザースタイルシートの個別ロード | nsIStyleSheetService |
| キャッシュ関連 | nsICache で始まる香具師ら |
| サーバを立てる | nsIServerSocket(bbs2chreaderも参考になる) |
| デザインモード | nsIDOMNSHTMLDocument |
古いです
apprunnerを開始するために必要なアプリケーション固有のデータ。
statusはFROZEN。追加フィールドが構造体の最後に将来的に追加される可能性有り。nsXREAppDataのバージョンの実行時検出はsizeフィールドを調べることで行われ得る。
この構造体がXRE_CreateAppDataにより確保され、操作されるとき、文字列フィールドはNS_Alloc で確保され、インターフェースへのポインタは強い参照になる。
この変数はsizeof(nsXULAppData)にセットされる。この構造体は将来のリリースで拡張されるかもしれないので、これがバイナリ互 換性の維持を保証する。
アプリケーションが実行されるディレクトリ。XULRunnerとアプリケーションが同じディレクトリにインストールされた時はNULLでもよい。
アプリケーションベンダの名前。ASCIIでなければならず、通常は「Mozilla」のように大文字と小文字が混ざる。NULLであってもよい が、これをセットすることが強く推奨される。空文字列であってはならない。
アプリケーションの名前。ASCIIでなければならず、通常は「Firefox」のように大文字と小文字が混ざる。必須（＝NULLでも空文字列で もいけない）。
「0.8.0+」のようなメジャーバージョンを示す。NULLであってもよいが、拡張マネージャやアップデート機構のような、より進んだ機能のため には必要である。空文字列であってはいけない。
「2004051604」のような、アプリケーションのビルド識別子
アプリケーションのUUID。互換性のある拡張機能を判断するために拡張マネージャによって使われる。オプショナルだが、拡張マネージャやアップ デート機構のような、より進んだ機能のためには必要である。
これは伝統的には"{AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE}"の形式だが、新規のアプリケーションに は、"appname@vendor.tld"というような、より読みやすい形式が推奨される。次に示す記号のみが許される。
a-z A-Z 0-9 - . @ _ { } *
コマンドラインオプション -h で表示される著作情報。
例：Copyright (c) 2003 mozilla.org
次章で示すNS_XRE_*定数の組み合わせ。
XREのある場所。XRE_mainは自動的にこれを見つけることはできない。
互換性のある最小/最大のXREのバージョン。
クラッシュレポートを送るURL。
プロファイルのディレクトリ。NULLでもよいが、空文字列であってはならない。ASCIIでなければならない。Pathは/と\で区切られる。
プロファイルを作るとき、プロファイル移行ウィザードサービスが呼び出されるかを示す。
拡張機能マネージャが起動時に初期化されるかを示す。
Breakpadによるクラッシュ報告を使うかを示す。
nsIXULAppInfoのContractID。
* A directory service key which provides the platform-correct "application
* data" directory as follows, where $name and $vendor are as defined above and
* $vendor is optional:
*
* Windows:
* HOME = Documents and Settings\$USER\Application Data
* UAppData = $HOME[\$vendor]\$name
*
* Unix:
* HOME = ~
* UAppData = $HOME/.[$vendor/]$name
*
* Mac:
* HOME = ~
* UAppData = $HOME/Library/Application Support/$name
*
* Note that the "profile" member above will change the value of UAppData as
* follows:
*
* Windows:
* UAppData = $HOME\$profile
*
* Unix:
* UAppData = $HOME/.$profile
*
* Mac:
* UAppData = $HOME/Library/Application Support/$profile
有効な拡張機能のリストを提供するディレクトリサービスキー。リストには互換性のあるプラットフォーム固有の拡張機能のサブディレクトリを含む。
現在のプロセスを実行するために使われている実行ファイルのディレクトリサービスキーを提供する。これは下記で定義されるXRE_GetBinaryPath関数で返される値と同じである。
プロファイルディレクトリを定めるディレクトリサービスキー。NS_APP_USER_PROFILE_50_DIRと違い、これはプロファイルが 開始される前、またはシャットダウンされた後でも利用可能である。もしアプリケーションがプロファイルなしに実行されている場合(例えばプロファイル選択 ダイアログを表示しているとき)、このキーは利用できない。このキーはXUL apprunnerまたはXRE_InitEmbeddingに渡されるaAppDirProviderによって提供される。
プロファイルディレクトリを定めるディレクトリサービスキー。NS_APP_USER_PROFILE_LOCAL_50_DIRと違い、これはプ ロファイルが開始される前、またはシャットダウンされた後でも利用可能である。もしアプリケーションがプロファイルなしに実行されている場合(例えばプロ ファイル選択ダイアログを表示しているとき)、このキーは利用できない。このキーはXUL apprunnerまたはXRE_InitEmbeddingに渡されるaAppDirProviderによって提供される。
XULアプリケーションを開始する。ユーザがアプリケーションを終了しない限り返らない。
カレントディレクトリからの相対パス、または絶対パスから、nsILocalFileオブジェクトを生成する。
実行中のアプリケーションのパスを取得し、aResultに格納する。
libxulにビルトインされた静的コンポーネントを得る。
プラットフォーム固有の手法でプロファイルディレクトリをロックする。
(nsILocalFile *aLibXULDirectory,
nsILocalFile *aAppDirectory,
nsIDirectoryServiceProvider *aAppDirProvider,
nsStaticModuleInfo const *aStaticComponents,
PRUint32 aStaticComponentCount)
libXULを組み込み用途に初期化する。
toolkitに新しいプロファイルを伝える通知を出す。このメソッドは、もしプロファイルとともに実行したい場合にはXRE_InitEmbeddingが呼ばれた後に呼ぶべきである。通常組み込み者はこのメソッドを呼ぶ前 に、ディレクトリをロックするためにXRE_LockProfileDirectoryを呼ぶべきである。
* @note There are two possibilities for selecting a profile:
1)XRE_InitEmbeddingを呼ぶ前にプロファイルを選択する。XRE_InitEmbedding.に渡されるaAppDirProviderオブジェクトは NS_APP_USER_PROFILE_50_DIRキーを提供すべきであり、次のキーも提供するかもしれない。
このシナリオでは、XRE_NotifyProfileはXRE_InitEmbeddingの後すぐ呼ばれるべきである。コンポーネント登録情報はプロファイルに 保存されるだろう。また、JSコンポーネントはfastloadキャッシュに保存されるかもしれない。
2)XRE_InitEmbeddingの後のあるタイミングで呼ぶ。このケースでは組み込み者は次のキーを提 供するディレクトリサービスプロバイダをインストールしなければならない。
コンポーネント登録情報はアプリケーションディレクトリに格納され、JSコンポーネントはfastloadには格納されないだろう。
XRE_InitEmbeddingまたはXRE_InitEmbedding2で開始された組み込みを終了する。
application.iniファイルからnsXREAppData構造体を新しく生成する。
すでに存在するnsXREAppDataに対して、INIファイル(application.iniまたは override.ini)をパースする。
XRE_CreateAppDataで確保したnsXREAppData構造体を解放する。