[Note] 来ちゃったね、iOS8 - The iOS8 came.

来ちゃったね、iOS8。

The iOS8 came.

まだ更新はしてませんが、いろいろ問題があるみたいですね。

I've already heard several troubles about new iOS, so I've not update it yet.

また仕事で大量に最新 iOS 対応案件が降ってくるのかな。

Does the iOS8 make many jobs on me again?

やりがいがありそうです。

I'm excited with expectation.

そういう仕事が来たら、また問題と解決方法を模索して、記事にしたいと思います。

If such a work comes, I grope for the issues and  solutions again and want to write an article about it.

タグ：IOS

[Note] iPad で $.ajax の失敗 - Failure of $.ajax in iPad

jQuery の $.ajax を使っている Web システムで、iPad だと特定の操作で特定のエラーメッセージが出現することが発覚しました。

I found that the Web system which used $.ajax of jQuery output specific error message by specific operation.

メッセージ文字列から追跡したところ、$.ajax を自作の JavaScript オブジェクトで隠ぺいし、エラーハンドラー内で決められた文字列を alert するようハード コーディングされていたため、この隠ぺいされた独自の Ajax が失敗すると、冒頭の特定のエラーメッセージが出ていたことがわかりました。

I traced the problem by the message string, then I found the concealed someone's own making code including $.ajax, and the code had a hardcoded error handler with "alert", so if the $.ajax failed the error handler output above specific error message.

また、ユーザーが値を入力できるほとんどのエレメントでフォーカス アウト系イベントをトラップし、無条件でこの独自の Ajax を実行していました。

And, most editable elements' focus out events were trapped to call the concealed own Ajax process unconditionally.

この時点で、こういう作り自体がナンセンスなんだけど。

I was sure that such a process is nothing but nonsense.

では、なぜ特定の操作で必ず $.ajax がエラーとなるのか。

Then, why did this system fail invariably with $.ajax by specific operation?

追調査した結果、$.ajax のリクエスト処理中にページのアンロードがかかると、xmlHttpRequest が status = 0 で失敗していました。

With more trace, if page unload occurred in the period of the $.ajax, the $.ajax failed with xmlHttpRequest status = 0.

ページのアンロードを誘発する遷移に関する操作が、この現象のトリガーでした。

Operation about the page transition to cause the page unload was the trigger of this problem.

ネットで調べてみたところ、ページのアンロード時に status = 0 になる現象は、特定のブラウザーと jQuery のバージョンの組み合わせで起きるようです（2.0.0 以降では起きないとか？？？）。

According to articles in the net, the problem that the $.ajax is fail with status = 0 at the time of page unload will be happened by the specific combination of the browser and the jQuery version(this problem fixed with 2.0.0?).

手元の環境では、iOS 6.x および iOS 7.0.x と、jQuery 1.8.2 の組み合わせで問題が起きていました。

In my case, the problem occurred by a combination of jQuery 1.8.2 and iOS 6.x or iOS 7.0.x.

とはいえ、以前記事にした通り、iPad では beforeunload を捕まえられないし、代わりのイベントの pagehide も発生条件が一定でないので、$.ajax を中断するにもキッカケがありません。

But, as I took an article the other day, iPad Safari Mobile doesn't fire beforeunload event, and the outbreak condition of pagehide event is not constant, so there is no opportunity to abort $.ajax.

本件のケースでは納期が迫っていたため、エラーメッセージの出力を抑制するフラグを仕込んで逃げました。

In this case, there was no enough time by the deadline, I evaded this problem by creating the flag which controlled the output of the error message.

ライブラリにはバグがあると思えということと、内部処理とプレゼンテーション処理は分離しろ、ということですね。

A library has a bug, and the processes should be separated in internal and presentation. 

タグ：iPad jQuery Ajax pagehide unload beforeunload

【Note】iPad の pagehide の厄介ごと - awkward "pagehide" in iPad

今回は、試しに英語の文章も併記します。間違えていたらごめんなさい、教えてください。

I write contents by English jointly for trial in this time. If I'm wrong, please tell me by comment.

IPad Safari Mobile でページのアンロードを扱う方法については、以前記事にしました。

The other day I wrote an article about how to handle the "page unload" in "iPad Safari Mobile".

ページのアンロードを処理のトリガーにする Web システムを iPad に対応させたい場合は、pagehide イベントしか使えません。

Only "pagehide" event is usable to start some kind of processing in "page unload" in iPad.

しかしこの pagehide、iOS のバージョンによって発生条件が違ったりします。

However, outbreak condition of "pagehide" depends on iOS version.

例えば、複数のタブがあり、タブ A がアクティブでタブ B が非アクティブだとします。

Please imagine, there are 2 tabs, tab A is active and tab B is not.

ユーザーがタブ B を見ようとして、タブ B をタッチした瞬間に…

Then a user touches tab B to watch it, and an active tab is changed; ...

• iOS 6 ではタブ A の pagehide が発生しません。
• iOS 7 ではタブ A の pagehide が発生します。

• "pagehide" of tab A does NOT occur in iOS 6.
• "pagehide" of tab A occurs in iOS 7.

・・・なんてことに（あれ？ 逆だったかな？）。

... awkward(It may be reverse ?)

他のイベントでも、バージョンや環境に依存して挙動が違うものがあるのかもしれませんが。

Similarly, there may be the event that a condition changes under the influence of a version or environment.

ページのアンロード系を処理のトリガーにするのは、やっぱり最初の考え方が間違っているんじゃないかなあ。

I think that it is wrong to start some kind of processing in "page unload".

タグ：pagehide iPad unload Page IOS

【Tips】iPad で select.onchange 中に alert や confirm でフリーズする問題を回避

iOS 7.0.2 に見られた厄介な不具合の回避方法です。

iOS 7.0.2 Safari Mobile では、select タグの onchange イベントハンドラー内で JavaScript の alert や confirm を実行すると、ユーザーが応答した瞬間にフリーズします。

この問題を回避するには、alert や confirm を select.onchange イベントの期間の後で実行します。

まず select.onchange イベントハンドラーでタイマーだけを仕掛けてイベントから抜けておき、タイマーイベントで alert や confirm を実行したい処理を起動するようにします。

$(function() {
    $("select[id='id']").bind("change", null, function() {
        setTimeout(function() {
            if (confirm(message)) {
                ...
            }
            else {
                ...
            }
        }, 100);
    });
});

タイマーイベントが発生する前のなんらかのコンテキストをタイマーイベントハンドラー内の処理で取得したい場合には、クロージャを活用すると便利です。

なお、この不具合は iOS 7.0.3 でフィックスされたそうです。

 

タグ：JavaScript IOS iPad jQuery Select CHANGE onchange alert confirm

【Tips】iPad でポップアップの window.onunload 代替え処理を実装

個人的には Web システムで window クローズ系イベントをトリガーとする処理は実装しない方がよいと思いますが、仕事上で改修の必要に迫られたので調べてみました。

iPad に搭載されている Safari Mobile では、window.onload や window.onunload イベントが発生しません。

ロード時には代替えイベントがあるし、ポップアップ（window.open で開いたウィンドウ）でなければアンロード時の代替え方法もあるんだけど、ポップアップのアンロードではちょっとハマりかけました。

window.onpagehide は来るタイミングが遅いし、body.onunload は来ませんでした。

JavaScript でクローズ処理が書けるなら、以下の方法が使えるようです。

$(window).bind("pagehide", null, function() { /* イベント処理 */ });
   ・・・
window.open("about:blank", "_self").close();

ブランクで window のアンロードを発生させることで、期待通りのタイミングで onpagehide イベントを発生させる…という流れですね。

しかし残念なことに、Safari Mobile タブ上の × ボタンでクローズされると、この実装は役に立ちません。 

タグ：JavaScript IOS iPad jQuery unload onunload pagehide onpagehide