ユーザーの同意とブラウザーの更新処理

本記事は、マイクロソフト本社の IE チームのブログ から記事を抜粋し、翻訳したものです。 

【元記事】Consent and Browser Refreshes (2011/5/25 11:35 AM)

 

GeoLocation API のような最新のブラウザー API は、ユーザーの同意がすぐに得られない場合にも対応できるように設計されています。このような API では、単純に、ユーザーが同意していない場合は同意が必要な処理を行わないという動作が可能です。

しかし、ポップアップ ウィンドウや ActiveX コントロールなどのブラウザー機能の多くは、権限の制限が導入されるより以前に作られており、多くの Web サイトは、API がすぐに (同期的に) 同意されて動作することを前提とした構造になっているのが現状です。

ポップアップ ブロック、サイト別の ActiveX 許可、ActiveX フィルター、追跡防止機能などが、ユーザーの同意を必要とする処理をブロックした場合、Internet Explorer は、ユーザーが許可を与えると (たとえば、ユーザーが [ブロックの解除] ボタンや [許可] ボタンをクリックすると) その Web ページを更新します。このときに問題となるのは、ブラウザーが何らかの機能 (ActiveX コントロールやポップアップなど) を想定されるタイミングで読み込まなかった場合に、その機能の存在に依存する JavaScript が失敗するという点と、ユーザーが後からコンテンツのブロックを解除してそのコンテンツが最終的に利用可能になっても、JavaScript が自動的に復元されることはないという点です。

Internet Explorer は、コンテンツのブロックが解除された後でページを更新するという方法で、ユーザーの同意を得るステップの影響をある程度緩和できます。

ページを更新すれば、ページが再度読み込まれるときに、スクリプトおよびコントロールが想定どおりに読み込まれます。ただし、この更新処理が問題となる場合もあります。たとえば、ページ上にデータを入力していた場合はブラウザーが更新処理を実行するとデータが失われることがあります。

Web アプリケーションは、ユーザーから同意を得るステップを避け、API がブロックされる場合もスクリプト エラーが発生しないように設計することができます。

たとえば、Outlook Web Access (OWA) チームは、ポップアップ ブロックに対して巧みな方法で対応しています。

既定では、ユーザーによる操作 (クリックや Enter キーの押下げなど) の後でのみ、ポップアップは許可されます。OWA では、ポップアップのほとんどをユーザーが行うクリックの直接的な結果として表示することで、ポップアップ ブロッカーの発生が自動的に回避されるように設計されています。しかし、予期しないタイミングで通知が表示され、ブロックが発生する場合もあります。

OWA は、ポップアップがブロックされたこと (window.open の戻り値が null であるなど) を検出すると、以下のような HTML の確認メッセージを表示します。

ユーザーが [ はい ] ボタンをクリックすると、それがユーザーによる操作として解釈され、ポップアップ ウィンドウが許可されます。この 2 回目の確認でポップアップ ウィンドウを開くことができなかった場合、Web アプリケーションはユーザーが標準でない設定 (「すべてのポップアップをブロックする」設定など) をしていると判断し、以下のようにユーザーに通知します。

ユーザーが OWA の確認メッセージではなく、ブラウザー上の [ 許可 ] ボタンをクリックした場合、Internet Explorer はページを更新しようとします。OWA には OnBeforeUnload ハンドラーがあり、これは、更新でコンテンツが失われることをユーザーに警告します。

ユーザーが、 [ ページに留まる ] を選択した場合、ページの更新は行われず、電子メール メッセージはそのまま保持されます。

IE 9 では、「ページでポップアップの使用を許可する」フラグの設定が、更新処理をしなくても現在のマークアップに設定されるように改善されました。これにより次回以降のポップアップは表示され、ユーザーの同意に基づいて許可が与えられるようになりました。

こちらはポップアップ ブロックのテスト ページです。

Web アプリケーションのベスト プラクティスとして、ユーザーから同意を得るステップを伴う API は、すぐには同意されず、動作しない可能性があると想定することをお勧めします。

Eric