wasavi の新しいビルドはだいたい週末にここにアップし、さらに某掲示板でアナウンスしているわけなのだが、その中に

クロームでふたクロ使ってると
フローティングのテキストエリアの下にviの編集ウインドウ開いちゃうね
調節する方法あるのかな
これわさびで入れてみたよ

というリプライがあった。ふたクロというのはその某掲示板向けの Chrome 用拡張だ。

さてこれは要素の上下関係の問題だ。具体的には、2 つの要素のそれぞれの z-index プロパティの値の関係だ。確認してみると、ふたクロが生成する textarea のその親となる form の z-index は 2000000013 とかそんな感じだった。20 億飛んで 13。一方で、wasavi が生成する iframe には 16777215 すなわち 0x00ffffff を入れている。したがって wasavi のほうが隠れるというわけだ。

直接的には、20 億飛んで 13 を超える z-index 値、たとえば 0x7fffffff を割り当てるだけの話だが、そんなんでいいのか？　という気も。まずこの値は経験則的な最大値でしかない。32bit バイナリでブラウザを動かして、z-index がとりうる値は負の値を含む数値で……なんてところだとまあ最大値はたぶんこれだろう程度のものだ。しかし CSS2.1 の仕様では z-index の最大値には特に記述がない。すると、もしかしたら 64bit バイナリなブラウザではさらに大きな z-index 値を指定できる可能性もなくはないということになる。そうすると 0x7fffffff を指定したところで意味がない。

実はある時期までは、wasavi の起動時に全要素を舐めて、その時点での最大の z-index 値を算出し、それを超える値を wasavi に与えていた。これならどの環境でも問題ない。手法としては、やはりこれが正道だ。しかし、全要素を舐めるわけなので当たり前なのだが、算出処理がとても重いのだ。100ms オーダーで時間を要する。

次善の策として、全要素ではなく、対象となる textarea 要素をその親へ遡った部分ツリーだけを算出の対象にするという方法もある。これならまあせいぜい数 10 個の要素を舐めるだけの話だ。ただこれだと必ず最大の z-index を得られるわけではないんですけどね……まあしかたないかな。

そういうわけでそう修正。

！？