ダミーのデータだけを登録したplaces.sqliteを用意して、それを使って検索のテストを行うようにしてみた。Managerを使ったけど、結構めんどかった。2008掲示板の方で障害報告を受けていた、正規表現にマッチするはずなのに強調表示される物とされない物があるという問題。原因を色々調べてみたら、非表示の要素が問題を引き起こしていた。c</p></fieldset>例えばこんな箇所を検索対象にして、a|bという正規表現で検索するとする。Rangeで取得して、文字列に変換し、それに対して正規表現のマッチングを行う。c」という風な文字列が得られ、最初にマッチした「b」がヒット箇所ということになる。次に、この「実際にヒットした文字列」を使ってFirefox自身の持つ検索機能を呼ぶんだけど、ここで問題が起こる。Rangeの文字列化では要素が表示されてるかどうかというのは考慮されないんだけど、nsIFindのRange内検索では、ヒット箇所が非表示の要素の中だった場合はヒットしなかったものとして次候補を探してしまう。上記の例では、非表示のlegend要素の中に「b」という文字列を見つけても、非表示だからということでスルーされてしまい、実際には次のp要素内の「b」という文字列の方にヒットしてしまう。XUL/Migemoで次候補を検索すると、次の(2つ目の)「a」にはヒットする。次候補を検索すると、文書の終了に達して文書先頭から検索し直されるのだけれども、この時も上記のような事が起こって、p要素内の1つ目の「a」ではなくp要素内の「b」がヒットする。よって、普通の前方検索を行っている間は永久に、p要素内の1つ目の「a」にはマッチしないという現象が起こる。TraversalのTreeWalkerを使わないといけないと思う。TreeWalkerではすべての要素ノードに対してJavaScriptの関数呼び出しと条件判定が行われるので、長いページだとヤバイくらいに速度低下が起こりそう......という懸念があって、手を出せずにいる。実際にそのように実装して試してみたところ、確かに正しく検索できるようにはなるんだけど、Rangeを文字列化する処理自体が10倍遅くなった。2008今まで全然知らなかったんだけど、vimperatorでXUL/MigemoのAPIを使ってタブの切り替えやヒントモードを強化するなんてことをやってる人がいたんだ。(←って、分かったような書き方をしてるけどvimperatorの事は全然分かってません......)その関係でいくつかページを渡り歩いてたら、XUL/Migemoのバグって話題が出ていて、なぬ!と思ってさらに辿ってみた所、半角括弧がらみの問題のことらしい。あーこの辺ちゃんと見直さないままずっとここまで来てたんですよね......UxU用のテストも基礎部分の単体テストはさっぱり手つかずのままだったし(ぉぃ)。いうことで本腰入れてテスト書いて、潜在してたバグを潰し始めました。