[Small Talk]「～を検索」は正直邪魔だと思います。

Oakbow — Tue, 12 Jan 2010 21:15:00 GMT

Google Tool Barのアレです。

検索キーワードの入力欄に文字列を入力すると、全角スペース一個分くらいの隙間の跡に「を検索」って表示されるようになりましたね。

慣れてはきましたが、治りかけのかさぶた（今剥がすと確実に出血）くらいどうにかしたくなってくるのは私だけでしょうか。

携帯電話の予測変換ばりに、入力中の検索キーワードの文字列に対して補完機能が働くようになりましたね。

この機能自体には結構感心しました。IMEをONにするの忘れて直接入力していても、ローマ字から日本語に補完してくれるし。

でも、でもね。

私の環境だけなのか分かりませんが、リコメンド機能よろしく出てくるプルダウンメニューが、びろーんと下に垂れ下がったままになることがよくあります。

舌をびろーんと垂れ下げたまましまい忘れてるシュウたんは可愛いですが、こちらは可愛くありません。

タブに重なるので切り替えにくくなるし、当座の作業に問題なくても気になって仕方ないのでなんとか閉じさせようとするんですが、これがなぜかなかなか閉じないんですね。

自宅環境のIE8ではあんまり起きない気がするので、会社環境のIE7が原因なのかな？

できればさっさとIE8にしたいところですが、Webアプリケーションの動作確認の時には重宝するので悩みどころです。

[Browser]IEのウィンドウごとのセッション共有・非共有

Oakbow — Sun, 13 Sep 2009 00:26:00 GMT

私の自宅環境（Windows Xp Professional）でも、とうとうWindows UpdateでIE8が入りました。

会社では3台のPCがあって、それぞれブラウザが違ったりします。

Windows Server2003 R2 日本語版を2年ほど前に自分でインストール。最初に入ってたブラウザはIE6。
自動更新が利かない環境なので、手動でWindows Updateをやっている。
1～2ヶ月ほど前から重要な更新でIE8が出てくるようになるも、IE6のまま使用。
Windows Server2003 R2 英語版を2年ほど前に自分でインストール。最初に入っていたブラウザは多分IE7。
自動更新が利かない環境なので、手動でWindows Updateをやっている。
2～3ヶ月ほど前に重要な更新でIE8が出てきたので、そのまま入れて使用。
Windows Xp Professional 日本語版のプリインストールマシン。1年半ほど前に購入。最初に入っていたブラウザはIE7。
会社のWSUSの環境下にあるので、自動更新でWindows Updateをやっている。
IE8は会社的にまだっぽいので、重要な更新に出てくることは無い。IE7のまま使用。

WindowsXpプリインストールマシンでも、ブラウザがIE6だったりIE7だったりする。

重要な更新でIE8が出てくるようになった時期もなんかちょっと違ったりしますね。環境かな？

IE7は日本だけなぜかまともにWindows Updateで配信されていないので、ほとんどの人がIE6→IE8に一気に飛んじゃうでしょうか。

重要な更新に含まれているので、今後一気に移行が進んでいきそうですね。

さて、前置きが長くなりましたが、IEのセッションクッキーについて。

Webアプリケーションで一般的に使用されるセッションは、セッションIDと呼ばれるキーとなる情報をクライアントとサーバ双方で保持することで成り立っています。

クライアント（ブラウザ）がWebアプリケーションに最初にアクセスしたときに、WebアプリケーションはセッションIDを生成し、その値を持つクッキーの発行をブラウザに要求します。

クッキーに対応したブラウザであればその要求を受け入れ、以後同じサイトへのアクセスであれば、毎回セッションIDをクッキーで送信するようになります。

通常のクッキーはプレーンテキストでブラウザが管理する一時ファイル領域に保存され、ブラウザやOSがシャットダウンされても、次回アクセス時にそのまま使用できるようになっています。

が、セッションクッキーだけは別で、これはブラウザが保持するメモリ領域のみに保持され、ブラウザやOSがシャットダウンされると消えてしまうようになっています。

ここまでが一般のセッションクッキーの共通知識ですよね。

で、複数のウィンドウを開いているときに、セッションクッキーがブラウザでどう扱われているかって情報は見かけない気がして、数年前に一度調べたことがあります。

IE8が出てから復習もかねて調べなおしたりしたので、そのまとめ。

IE6
セッションはプロセス単位で共有しています。ごく普通のマルチスレッドアプリケーションのメモリの扱いと一緒っていっていいかな？
IE6では、「CTRL+N」や「ファイル」→「新規ウィンドウ」、ハイパーリンクをShiftキーを押しながらクリック、ページ内のHTMLやJavaScriptの記述により別ウィンドウを開く、という操作では、ウィンドウ自体は別であっても同じプロセス内で動作しています。
すでに存在するウィンドウから開いたウィンドウであれば同じプロセス、と考えていいと思います。
それに対して、スタートメニューやデスクトップのアイコンからなど、既存のウィンドウに依存しないやり方で新しくウィンドウを開いた場合は、別のプロセスで起動します。
このような違いが発生するので、例えば後者のやり方で二つのウィンドウを開いた状態にすると、セッション管理された会員ページとかで、別々の会員としてログインして動作確認をしたりって事が可能です。
前者のやり方でウィンドウを二つ開くと、片方で会員ページにログインすれば、もう片方はいきなり会員ページ内にアクセスさせても普通に操作できたりもします。
一人の会員に対して何度もログインログアウトを繰り返すような動作確認を行う場合、こちらのやり方を採用するとちょっとだけ楽が出来ます。
IE7
IE6と同じと考えてもらっていいです。当然ですがタブは同じウィンドウであれば同じプロセス内にあり、セッションを共有します。
IE8
IE6/7の考え方は通用せず、上記のようなやり方であればいずれもセッションを共有します。プロセスが違うウィンドウであっても。
そもそもIE6/7であればウィンドウの数よりプロセスの数が多くなることはありませんでしたが、IE8の場合はプロセスがひとつであっても、タブを増やすと複数のプロセスが出来たりします。
IE8でセッションを共有しない新しいウィンドウを開きたい場合は、「ファイル」→「新規セッション」でウィンドウを開きます。

たいていのWebアプリケーションではセッションを使用するでしょうから、ページ遷移などで予期せぬセッション情報の書き換えなどが発生しないように、ブラウザでどのようにセッションが共有されているかは抑えておきたいところです。

私は機能ごとに必要な値をできるだけセッションに持たせないように作るんですが、その理由が複数のウィンドウ開いたときに問題が発生するからだったりします。

ごく普通にユーザーが行う操作を制限したりするのは昨今のトレンドに反するし、何より複数のウィンドウ開いて操作しちゃったせいで問題が発生したって問い合わせがエンドユーザーから結構あったから。

エンドユーザーからの問い合わせは「入力値とは異なる値に書き換わった」ってなものになるので、上のようなウィンドウ間でのセッション共有が発生する仕組みを知らないと、原因すら分からないことになったりもします。