Chris Toohey のすばらしいブログ エントリに従って、いくつかの編集可能なフィールドとファイルのアップロードを含む新しいドキュメントを作成するためのダイアログ ボックスを作成しました。. このソリューションでは、ExtLib ダイアログ内で iFrame を使用して、そのコントロールの制限を回避します。しかし、Firefox (V 20) でテストすると、通常は編集可能なすべてのフィールドがブロックされているように見えます。それらをクリックすると、カーソルが短く点滅し、明らかに別の場所に送信されます。何かが js .blur() メソッドを実行するように見えますが、何も見つかりません。ただし、ページ上のすべてのボタンは機能します。そのため、ファイルをアップロードできますが、ダイアログのフィールドに値を入力できません (FF を使用、以下を参照)。ここでさらに奇妙なのは、あるフィールドを右クリックして Firebug の [Firebug で要素を調べる] を選択するとすぐに、フォーム内のすべてのフィールドが開いて編集できるようになり、ダイアログを閉じるまでそのままです。
MSIE (camptibility と IE8 モード) を使用して同じことを試しました。ここでは、最初に、このコンテキストでサイト「about:blank」を開くことを許可するように求められました。許可するとすぐに、すべて問題ありませんでした。ダイアログでフィールドを編集したり、ファイルをアップロードしたりできます。FFではそうではありません。
どういうわけか、何らかのセキュリティ設定がフォームの編集を妨げているように見えます.XSSなどを妨げている可能性があります. しかし、自分のサイトをダイアログの iFrame にロードできるようにする設定が FF に見つかりません。
更新:このクライアント側スクリプトを、これらのフィールドの onblur イベントの 1 つに追加しました。
alert("go away!")
実際、ダイアログを表示してそのフィールドをクリックすると、最初にアラートが発生します。そして: それ以降、すべてのフィールドが利用可能になります。
更新 #2:別の editBox ("outerField") をダイアログの内側に配置しましたが、iFrame の外側に配置しました。また、iFrame にロードする新しい非常に単純な Xpage を作成しました。新しい単純な Xpage には、単一の editBox (「innerField」) のみが含まれ、他には何も含まれていません。結果は次のようになります。ダイアログをロードした後、カーソルは自動的に「outerField」に配置されます。「innerField」をクリックすると、カーソルはすぐに「outerField」に戻ります...
更新＃3：上でいくつかのことを試しました：
- Google Chrome は FF と同じように動作します
- iframeなどをホストするのとまったく同じカスタムコントロールを保持するXpageを作成しました。結果：独自のページでそれらを実行すると、すべて問題ありません。したがって、ここで問題を引き起こしているのは extlib ダイアログに違いありません
- 最後に iframe タグを使用してサンドボックス属性を試しましたが、目に見える違いはありませんでした