7

更新パネルといくつかのボタンを使用する Asp.Net 4.0 Web サイト/コントロール インターフェイスがあります。更新パネルは、5 秒ごとに実行されるタイマーに接続されているため、部分的なポストバックが発生します。ボタンはいくつかの設定を切り替えてから、次のような呼び出しによって更新パネルの更新を強制します。

var prm = Sys.WebForms.PageRequestManager.getInstance();
prm._doPostBack('<%= UpdatePanel.ClientID %>', '');
return true;

サイトは IE/Firefox および Safari モバイル デバイス (IPhone/IPad) では正常に動作しますが、モバイル デバイスでは、ポストバックがランダムにサイレントに停止します。これはバッテリーの節約に関係している可能性があり、サファリはアイドル時に部分的なポストバックをシャットダウンすると考えています。問題は、ユーザーがサイトに戻ったときにポストバックが完全に遮断され、タイマーもボタンもポストバックを引き起こさなくなることです。(これを確認するために、サーバー上のネットワーク トラフィックを監視しました)。ユーザーが Web サイトを (複数回) 更新しても、部分的なポストバックが再び発生します。サーバーへのデータの投稿を停止するだけです。その後、突然、特に理由もなく、ポストバックが再び機能し始めます。多くの場合、ダウンタイムは最大 10 分であり、これにより、私の Web サイトはその目的のために完全に役に立たなくなります。

ポストバックが再び開始されるまでに非常に長い時間がかかることを考えると、クライアント側または IIS で操作する設定があるのではないでしょうか?

ウェブサイトは私の顧客のデバイスでのみ実行され、公開されていないため、クライアントで再生する設定があれば、私はそれを受け入れます.

私はこれについて本当に混乱しており、「バグ」を引き起こす方法を見つけていません。時々起こるだけです。アドバイスやヒントは大歓迎です。

アップデート：

いくつかのエラー処理を追加し、ポストバックが失敗したときに次のメッセージを (一貫してではなく) 受け取りました。

ページは非同期ポストバックを実行していますが、ScriptManager.SupportParialRendering プロパティが false に設定されています。ポストバック中にプロパティが true に設定されていることを確認します。

奇妙なことに、このプロパティは最初のインスタンスで明らかにデバイスに当てはまります。そうでない場合、ポストバックは機能しません。

更新 2: web.config の browserCap 設定を変更することを提案する次のブログ投稿を見つけました。今これを試しています。報告します。他の提案は大歓迎です。 ASP.NET 4 BrowserCaps (または: 彼らは何を考えていた?)

上記は、フルスクリーンモード（ホーム画面から実行）のサファリモバイルでjavascriptを無効にします。次の記事では、この問題の修正を提案しています。 落とし穴: iPad と ASP.NET の比較

4

1 に答える 1

6

私の質問の「更新 2」の下にある調査結果は、問題を解決します。どうやら Safari UserAgents は、次のブログ投稿で特定されているように、Mozilla 0.0 として時々認識されていたようです: ASP.NET 4 BrowserCaps (or: what were they think?) :

最初の WTF は、BrowserCaps によると非同期ポストバックをサポートしていないブラウザーからの非同期ポストバックを検出すると、.NET フレームワークが実際に例外をスローすることです。反対の圧倒的な証拠があっても、誰が非同期ポストバックを実行できるかを彼らが一番よく知っていると思っているかのようです…</p>

次の WTF を見つけるのはかなり困難でした。Safari UserAgent が時々 Mozilla 0.0 として認識されるのはなぜですか? また、例外からコピーしたばかりの UserAgent 文字列を使用しても問題を再現できなかったのはなぜですか?

答えは

<browserCaps userAgentCacheKeyLength="64" />

ユーザー エージェント キャッシュ キーの長さのデフォルト設定では、UserAgent 文字列の最初の 64 文字が使用されます。...

さらにページの下に：

userAgentCacheKeyLength を 256 に設定すると問題が解決しましたが、Mozilla 0.0 として識別される UserAgent 文字列がまだ存在します。少なくとも今は一貫しています。

したがって、<browserCaps userAgentCacheKeyLength="256" />Web.Config を入れることで問題が解決します。

残念ながら、Safari ブラウザーをフルスクリーン モードで使用すると、別の問題が発生します (ホーム画面にリンクが保存されます)。全画面表示モードでは、Safari は別の HTTP ユーザー エージェント文字列を使用し、ASP.NET はブラウザーを Safari として認識しなくなり、代わりに機能のない汎用ブラウザーとして認識し、たとえば JavaScript や JQuery が機能しなくなります。これは、 Gotcha: iPad vs ASP.NETでさらに詳しく説明されています。解決策は、各 Web サイトの Page_Init に次を配置することです。あまりエレガントではありませんが、上記と一緒に動作します:

protected void Page_PreInit(object sender, EventArgs e)
{
   if (Request.UserAgent != null && Request.UserAgent.IndexOf("AppleWebKit", StringComparison.CurrentCultureIgnoreCase) > -1)
   {
      this.ClientTarget = "uplevel";
   }
}
于 2012-06-19T06:24:19.987 に答える