2002/02/04で書いたように違うウィンドウでブラウズするのが上手くいかないので調べていたときに発見したページ。
このサンプルで試しても、やっぱり同じウィンドウの中で開いてしまう。。
IDocHostUIHandler Extended CHtmlView
ちょっと古いけど、これも参考になりそう。
Take Total Control of Internet Explorer with Advanced Hosting Interfaces
スクリプトの実行やコントロールのダウンロードの制御なんかは、2002/01/31でリンクしたページの"Controlling Download and Execution"に書いてある方法でできそうだけれども、ホストのIDispatchはATLに握られていて手出しができない。
んー、やっぱりどうしたものか。
やはりちゃんと動作しないので、しょうがないのでこうすることにしました。
DWebBrowserEvents2をインプリして、Invokeで、DISPIDがDISPID_BEFORENAVIGATE2だったら、ナビゲートをキャンセルしてから、ShellExecuteでそのURLを開く。
でも、このままだと送られてきたメールがフレームを使っていた場合に、Content-IDの参照でフレームの中身を開くときにもキャンセルされてしまうという問題が。
んー、どうしよう。。。
インラインのイメージは同じContent-Idに対する参照が複数入っていても一回しか要求されないけれど、フレームがきってあって複数のフレームが同じContent-Idのパートを参照していると複数回要求される。
ので、IInternetProtocolRoot::Terminateが呼ばれたときにコンテンツを破棄するのはダメっぽい。
ついでに、フレームの時にうまくロードできないとWebBrowserの子ウィンドウごとどこかへいってしまう。2002/01/31で書いた方法でロードしているので、どこかにいかれてしまうととっても困るんだけど。
1. リフレッシュされると内部で表示されてしまう
<meta http-equiv="refresh" content="0; url=http://...">
みたいなタグがあると、QMAILの内部でリフレッシュ先が表示されてしまう。
2. Web Bug対策は？
<img src="http://...">
のようにインラインイメージのソースが外部URLだったり、フレーム・インラインフレームのソースが外部URLだったときにアクセスするのは問題？
Web Bug使うと開封したかとかも確認できてしまう。
3. クロスサイトスクリプティング対策？
1を使って、クロスサイトスクリプティングの対策がされていないWebページにrefreshされると、HTMLメール自体にスクリプトが入っていなくてもCookieが漏洩する恐れがある。
などなど。