formのonSubmitにfalseを指定しても画面全更新が発生する場合がある

Question

やりたいこと

・submitで画面遷移（画面更新）せずに、onSubmitで指定した関数を呼びたい

起きている問題

・onSubmitでreturn falseしているのに、画面全更新が行われる場合がある。

・A～Dの4画面に同じ処理があるが、Dの画面だけで必ず毎回起きる。
・A~CとDの違いは、onSubmitで呼ぶ関数の中で、ページ内のiframeをリロードするかどうか。
・Dは、リロードしない（リロードするiframeがないため）。

・対策として、Dのformタグに action="#"を入れると起きなくなった。

・その後、現象を再現させるために変更前に戻すと、現象が再現しなくなった（submit＝画面全更新が行われなくなった）。

知りたいこと

「onSubmitでsubmitを行わせない＝画面全更新をしないようにさせる方法は、
onSubmitに指定する内容が"return false;"であること。
つまり、下記３つのどの書き方でもOK」
という認識が、正しいかどうか。
もし認識が間違っているのであれば、どのように書くのがベストか。

<form onSubmit="return false;">
<form onSubmit="onOkButton();return false;">
<form onSubmit="return onOkButton();">※onOkButton()の最後にfalseを返却

今のコード

jsfiddle

<form action="#" onSubmit="onOkButton();return false;">
<input value="" type="number" step="0.01" min="-99.99" max="99.99" required>
<button type="submit">OK</button>
</form>

		var reqTimeout = 10000;
		var reqURL = 'XXX/XXX'

		function onOkButton() {
		  set();
		}

		function set() {
		  var setWL1;
		  var input_WL_Lv1 = document.getElementById('input_WL_Lv1');

		  if (input_WL_Lv1) setWL1 = Number.parseFloat(input_WL_Lv1.value);
		  postData2Server(reqURL, {
		      "WL_Lv1": setWL1
		    },
		    reqTimeout, {
		      'onSuccess': function(resp) {
		        var iframe = document.getElementById("iframe");
		        if (iframe) {
		          iframe.contentWindow.location.reload();
		        }
		      },
		      'onError': function() {
		        console.log("Error");
		      },
		      'onTimeout': function() {
		        console.log("Timeout");
		      }
		    });
		}

		function postData2Server(reqURL, data, timeout, callback) {
		  if (document.baseURI.startsWith('file://')) {
		    return;
		  }
		  var req = new XMLHttpRequest();
		  req.timeout = timeout;
		  req.ontimeout = callback.onTimeout;
		  req.onreadystatechange = function() {
		    if (req.readyState === 4) {
		      if (req.status === 200) {
		        if (req.responseText === 'OK') {
		          callback.onSuccess();
		        } else {
		          console.log('Error: req.responseText is not OK');
		          callback.onError();
		        }
		      } else {
		        console.log('Error: req.status is not 200');
		        callback.onError();
		      }
		    }
		    delete req;
		  }
		  req.open('POST', reqURL, true);
		  req.setRequestHeader('content-type', 'application/json');
		  req.send(JSON.stringify(data));
		}

最後になりますが、ご助力よろしくお願いいたします。

Comments

[think49]

下記HTMLで挙動に変化が現れるか確認すべきかと思います。
<form onsubmit="return false;">
<form onsubmit="event.preventDefault();">

[yamekodev]

それら2パターンで挙動の変化を確認すべきとおっしゃられている意図は何でしょうか？
（onsubmitのキャンセルがそもそも効いているかどうかの確認を先にしたほうがよい、との意味でしょうか？）

ABCDの4画面で、
<form onsubmit="return false;">にした場合→リロード発生なし
<form onsubmit="event.preventDefault();">にした場合→リロード発生なし
で、挙動に変化はありませんでした。

[think49]

「リロード発生なし」という事は

A. submitイベントのデフォルトアクションがリロードを発生させている
B. onOkButton();がリロードを発生させている

のどちらかの可能性に限定出来ます。

[think49]

A.なら、Lhankor_Mhy さんの回答で解決できるでしょう。
yambejpさんが懸念されたようになんらかのエラーで後続処理が実行されていない可能性があるので、onOkButton();のコードをよく確認すべきですが。

B.はA.を含みますが、「デフォルトアクション以外の手段でリロードを発生させている可能性」が否定出来ません。

[think49]

いずれにしても、onOkButton()のコードが開示されない以上、こちらが出来るのは「切り分け手段の掲示」だけです。
yamekodevさんはyambejpさんへのコメントで十分に説明したつもりかもしれませんが、十分にコードを把握していたのなら、この問題は発生しませんでした。
「yamekodevさんが認識出来なかった場所」に問題があるのは間違いありません。

他に何も手がかりがないのなら、breakpointを一行ずつ指定して、リロードが発生するちょくぜのコードを確かめる事をしてもいいぐらいだと私は思います。

[yamekodev]

onOkButtonのコードを追加しました。

[yamekodev]

onOkButton内で画面全体にリロードを行うようなことはしていないつもりなので、お手数ではございますが見ていただければと思います。

[think49]

再現しません。
https://jsfiddle.net/mvan01zs/2/

[think49]

再現可能な短いサンプルコードの書き方 - ヘルプ センター - スタック・オーバーフロー
https://ja.stackoverflow.com/help/minimal-reproducible-example

[yamekodev]

onokbuttonを一応修正しました。
https://jsfiddle.net/0yzerw29/

ただ、コードをのせた理由は、そのままjsfiddleのようなサイトで動かすためではなく、
「onokbuttonの中でデフォルトアクション以外の手段でリロードを発生させている可能性」があるかどうかを、机上で見ていただくためです。

yambejpさんへの回答に返信させていただきましたが、onokbutton内ではサーバへのPOSTを行っているため、コードだけで状況を再現することはできません。
また、これも質問に書きましたが、現象が出ていたはずの画面Dで、対策として入れたformタグのaction="#"を外して元のコードに戻しても、現象が再現しなくなっている状態です。

したがいまして、仮にオンラインでコードを実行できる環境を整えられたとしても、現象が100%再現するとは限りません。

[think49]

やはり、再現しません。
再現しないコードを調査するのは確実性がありません。
確実に問題があると分かっているコードでなければ、問題がないコードを調査する事にもなります。
「現象が100%再現するとは限りません」のであれば、無意味かもしれない調査を回答者に強いる事になります。

[think49]

ところで、質問がクローズされているようですので、yamekodevさんの中で結論が出ているものと思います。
調査結果を教えてください。
breakpointを設置して、ページ遷移が発生する直前のコードは特定できましたか？

[yamekodev]

>やはり、再現しません。
>再現しないコードを調査するのは確実性がありません。
>確実に問題があると分かっているコードでなければ、問題がないコードを調査する事にもなります。
>「現象が100%再現するとは限りません」のであれば、無意味かもしれない調査を回答者に強いる事になります。

ですので、現象が100%再現するとは限らない不安定な状況（最初は問題が発生したが、少しコード変えたあと、コードを戻すと再現しなくなった。今は現象が出ない）になっているのが問題であると、質問の「問題」に最初から書いております。

それに対して、think49さんが、
A. submitイベントのデフォルトアクションがリロードを発生させている
B. onOkButton();がリロードを発生させている
の、Bの可能性が否定できないからコードを開示してもらう必要がある、とコメントされたので、開示しただけです。

現象が再現しなくなっていることは最初から書いているのに、コード開示後の段階になって「100%再現できないなら、無意味かもしれない調査を回答者に強いることになる」と言うのは、前提の認識がずれていると思います。

[think49]

それは失礼しました。
「・その後、現象を再現させるために変更前に戻すと、現象が再現しなくなった（submit＝画面全更新が行われなくなった）。」の追記にきが付いていませんでした。
言い訳させて頂くと、
https://teratail.com/questions/history-questions/300066
の「2」で更新されていますが、緑背景ではないので、追記箇所が追うのが難しいです…。

[think49]

ただ、「現象が再現しなくなったコードを掲示して、問題を特定させる」のが無駄という見解は私としては変わりありません。

・この状況で、yamekodevさんがどういうロジックで私が特定できると考えたのか。
・復旧済コードがあるのに、どういう基準でLhankor_Mhyさんの回答がベストアンサーだと思ったのか

いろいろと分からない事がありました。

[yamekodev]

今は再現しなくなっていることを、最初から書いていたと勘違いしておりました。
こちらこそ申し訳ございませんでした・・・。

＞「現象が再現しなくなったコードを掲示して、問題を特定させる」のが無駄という見解
私見ですが、一概に無駄ではないと思います。
あるコードが、今は現象を再現しなくなったとしても、まったく同じコードで過去に現象が出ていたとすれば、
それは同じに見えても何か問題が潜んでいる可能性はあると考えます。
そしてそれを第三者の目として回答者の方に見ていただくことは、必ずしも無駄ではないと思います。
ただ、これはあくまで私見です。
think49さんが「今現象が起きなくなっているコードを見るのは無駄」とお考えになることを否定はしません。

>・この状況で、yamekodevさんがどういうロジックで私が特定できると考えたのか。

当初私が、think49さんなら問題を特定できると考えたのは、
>いずれにしても、onOkButton()のコードが開示されない以上、こちらが出来るのは「切り分け手段の掲示」だけです。
とコメントされた後、
>「yamekodevさんが認識出来なかった場所」に問題があるのは間違いありません。
と言い切ったからです。
ではコードを開示すれば、think49さんが、私の盲点になっている問題を見つけられるのだろうと考えました。

ただ、現在は、think49さんに問題の特定をお願いすることは考えておりません。
現状のコードが現象を100%再現するコードではなく、think49さんが見る意味があると考えるコードとは違うためです。

＞・復旧済コードがあるのに、どういう基準でLhankor_Mhyさんの回答がベストアンサーだと思ったのか

復旧済みコードとは、どのコードのことを指していますでしょうか？

Answer 1

こんにちは。

「onSubmitでsubmitを行わせない＝画面全更新をしないようにさせる方法は、

onSubmitに指定する内容が"return false;"であること。
つまり、下記３つのどの書き方でもOK」
という認識が、正しいかどうか。

おそらく、onSubmit="event.preventDefault();onOkButton();"がいいんじゃないかと思います。

---

推測というか想像ですが、動作にブレがあったのは、ブラウザがアンロード処理をする前に false を返すことができるかどうか、ということだと思います。
iframe 読み込みがある画面がページ移動しなかったのは、読み込みによってアンロード処理を遅延させるからではないでしょうか。

---

上記の想像が妥当か否かにかかわらず、イベントの処理の後に false を返してキャンセルするよりも、イベントの処理の前にpreventDefault()でキャンセルしてしまった方が、動作は安定するのではないかな、と思います。

Comments

[yamekodev]

iframe更新の有無によって動作が違う＝なんらかのタイミングの問題？というもやもやがあったのですが、
それを言葉にしてくださったように感じました。
また、限られた情報から、想像、推測をしてまで対策を提案していただき、本当にありがとうございます。

＞イベントの処理の後に false を返してキャンセルするよりも、イベントの処理の前にpreventDefault()でキャンセルしてしまった方が、動作は安定する

この方法を採用させていただきます。
今回は本当にありがとうございました。
非常に助かりました。

（以下自分用のメモです）
イベントのキャンセル preventDefault stopPropagation の違い - JavaScript プログラミング
https://www.ipentec.com/document/javascript-difference-preventevent-and-stoppropergation

【JavaScript入門】イベント処理のキャンセル方法 | kitanote
https://kita-note.com/js-cancel-event

JavaScriptでのイベントキャンセルの落とし穴 - Linkers Tech Blog
https://linkers.hatenablog.com/entry/2019/10/25/154301

addEventListener() のリスナーでreturn falseしてもイベントはキャンセルできない
http://igrc.hatenablog.com/entry/2018/07/27/145655

JavaScriptでイベントリスナーの処理をキャンセルしたい時に扱うメソッドの使い分け | Tech dig
https://tech-dig.jp/javascript_event_cancel/

Answer 2

onOkButton()の内容によります

Comments

[yamekodev]

onOkButton()でやっていることは下記２点です。
最後は何もreturnしません。
・formタグ内のinputの文字を取得・整形してサーバにPOST
・POST成功時のみ、ページ内にiframeがあればリロード

[yambejp]

内容次第なので具体的に提示できないならこれ以上のアドバイスは難しいです
変な話onOKButton自体に文法エラーなどあればreturn falseは評価されません

[yamekodev]

onOkButtonのソースコードを追加しました。

[yamekodev]

onOKButton自体に文法エラーはないと思っておりますが、もしお気づきの点がありましたらご指摘いただけますと幸いです。

[yamekodev]

onOKButtonは、jsfiddleなどで直接実行できるコードではありませんので、机上での確認のみでお願いいたします。