スマホ(ドロワー)グローバルナビからの変遷し、戻った際の挙動について
グロナビから変遷した先から、スワイプで戻ると、ドロワーが開いた状態の前ページに戻ってしまいます。テキストでは難しいのでキャプチャしました。
僕の管理しているサイト複数で確認でき、サポトピアでも同じ症状が出ております。
僕は android14 pixel 8 pro で、戻る物理ボタンやブラウザに戻るUIがないので(あるのかわからないので)スワイプで行いました。
相方は iphone ◯ (そこまで古くないず)ですが、スワイプじゃない指の動きしてたようにも見えます。(ブラウザバック?)
JSのキャッシュが残ってる感じですかね?🤔
ご確認お願いいたします。
43 Replies
横レス失礼します。そうなんですね、戻るボタン使わないので全然気づかなかったです。私のGalaxy S10(Android12)の戻るボタンでやってみたら、たしかにドロワーの開いている画面に戻りました。
あ、やっぱそうなんですね。
ゲームのデバッガーの気分になりましたw
ありがとうございます。これって他のテーマというか、Nishiki Pro 以外で作られたサイトでも似たような挙動になるんでしょうかね?
なるみたいっすね!少々お待ちを。
ColorfulBox カラフルボックス
レンタルサーバー ColorfulBox(カラフルボックス)| 30日間無料お試し
レンタルサーバー「カラフルボックス」は、プランの移動ができる柔軟性や初心者向けのコンパネ、そして、災害・トラブルに強い次世代のバックアップ機能を導入した高品質レンタルサーバーです。
cocoonはならないっぽいっすね。swellは一部あり。ただし、バージョンはわかりませんが。
多分ヒントと言うか、違いあるかもです。
「右上ボタンで右から開く」もしくは「右から開く」が怪しいっすね。
↑秒で違いましたw
swell左上メニュー・左から開く
https://blog-bootcamp.jp
ブログブートキャンプ
ブログブートキャンプ | ブログスキルを短期間で鍛え上げる完全ガイド
ブログブートキャンプは、ブログスキルを短期間で鍛え上げるためのノウハウをお届けする情報メディアです。WordPressの始め方、記事の書き方、アフィリエイト収入の稼ぎ方などをやさしく解説しています。
ちなみに寝ログは右上メニュー・アコーディオン?
で、ひらきっぱっすね。
なるほど、これはBFCacheという機能のようですねー。
でざなり
SafariでブラウザバックするとJSなどが解除されていない問題【bfcache】
ある日仕事でWebサイトを作っていたのですが、iPhone実機のiOS Safariでハンバーガーメニューのリンクからページ遷移した後ブラウザバックをすると、メニューが開きっぱなしになっているなどの現象が起きてました。PCでスマホ表示を確認
chromeでもなるみたいです。
で、キャッシュされる時としない時があるそうですw
ドロワー部分のキャッシュだけkillみたいなのってできるんですかね?
それともブラウザキャッシュ全部逝っちゃんですかね🤔
部分的にはできなさそうですね。
でもこれ、スマホファーストで考えたらえらいヤバいやつっすね。
個人的には速さより安定の方が重要な気がします。
高速化って、他の要因がほとんどなので、ブラウザバックにそこまでリスク負って早さもとめるのはどうかなーって。
bfcacheを無効にする設定を追加する方向で進めますね!
この件調べているんですけど、確実に対処できる方法がなさそうです。
実装しても効かないとか。
で、割と見かける実装方法で、bfcacheを検知したらページをリロードするJSを動かすってのがあるようですが、リロードの実装でいいのかどうか・・・?という感じなんですよねー。どう思いますか?
リロードというのはつまり再読み込みですよね?となると2回読み込む、みたいない感じのニュアンスなのでしょうか🤔
僕も調べてみたんですが、挙動は少し似てるというか、今村さんもこれを指しているかもしれませんが、 onpageshow が期待する動きなのかな?と思っていました。
「onpageshow」は「ブラウザバックなどによる表示(キャッシュ/ページの再解析を行わない)において処理」
の組み合わせでドロワーのみ対象とすることができればなーと思いました。
よく考えたらこれ、例でも出してますがアコーディオンも開きっぱなしってことですよねw
まぁそこは開きっぱでもさほど問題ないかと思うのですがー。
「onpageshow」は古いやり方で、「pageshow」が一般的なんですね。
それが、イベントリスナーのpageshowは効かないことがあるそうなんですよね。効かないことがあるってどういうことだ・・・?と思うんですがw
そういえば開いてるドロワーを閉じるJSを書けばいい、っていう話をしていましたね!
この実装に関する巷の情報が結構曖昧で、頭整理しきれてませんでしたw
可能であればこちらが一番固い施策かなと思います!
いろいろ試行錯誤して下のJSに落ち着いたんですが、このコードをテスト用の環境などで読み込んで試してもらうことは可能ですか?
手元のiPhoneでは動作しましたが、複数の動作事例が欲しいなと思っています。
if文の中が空でも動くみたいです。
想定する動きになりました!
あ。
一旦サイトのキャッシュパージしてから試したほうが良いっすね。
うーん、Pixel 8 pro(android14)だめっぽいっすねー。
iPhoneのsafariでは動いたんですけどねー。巷の情報が少なすぎるんで何をどうすればいいのかもあまりわからない・・・
android14で使っているブラウザはChromeですかね?
これやればやるほど「本来の動き(展開したまま)が正しくないか?」ってなるのは自分だけでしょうか・・・
あとできることは、metaを入れるくらいですね。
参考
https://www.tagindex.com/html_tag/page/meta_pragma.html
手軽に確認するには、Nishiki Pro の一般設定のスクリプト追加でヘッダーにスクリプトを追加の箇所に下のコードを入れてみて検証できます。
android 実機が今ないので試せませんが、chrome のデベロッパーツールでbfcacheが効いてるかどうかを確認する方法があって、それで試した限りだとmetaを入れることで効いてる感じです。
なるほどっすねー。やっぱり明確な打ち手は無いってことですかね。
ブラウザキャッシュを全体的に切ってしまうのは高速化上できないので…
ちなみに、入れてみましたがやっぱり効いてないので難易度が高い件なのかもしれないですね。
これやればやるほど「本来の動き(展開したまま)が正しくないか?」ってなるのは自分だけでしょうか・・・これも非常にわかるのですが、僕的にはどちらかと言えばリセットCSS肯定派なので(結局はクライアントのしたいことに近づけなければならないし、「これがブラウザの仕様です」で通用しづらい)ところがあるので、各々個別解決ってとこでしょうか。最悪「遅くなるけどいいですか?それでもなお聞かないかもしれないですが」で終わらせろってとこかもですけどw 多分大多数のwebブラウジングにとってbfキャッシュは有効、と思って開発されているのかとも思いますし、やっぱり現段階では「この動きが正しい」になるんだと思います。 どう対策しても「おまじない」的な要素までしかできない気もしますし… ちなみに僕も独自でちょこちょこやってみましたが、今のところこれと言って成果はありませんでした😭 あとは「.panel-openが付いていたら削除する」方法を探してみるかなーって感じです。 ここだけで話しても仕方ない事かもしれないので、アンケートとかで聴いてみたいっすねw それこそ個人対応オナシャス案件かもしれないのでw で、bfCache推進派のyahooさんは、余裕のメニュー開きっぱでしたw
惜しいところまで行ってそうなんですが、明確な対応方法さえあれば実装全然やるんですけどねー。
SafariとFirefoxではけっこう前から有効になってて、後追いでChromeでも有効がデフォルトになったという歴史があるようで、bfcacheは基本的に有効にしておく流れなんだろうなーという理解はしています。
次の勉強会で時間があったら話題にしてみますね。
さっきyoutube試してみたんですが、メニュー閉じますねw
Chrome公式ドキュメント発見しました
https://developer.chrome.com/docs/devtools/application/back-forward-cache?hl=ja
Chrome for Developers
バックフォワード キャッシュをテストする | DevTools | Chrome for Developers
ページがバックフォワード キャッシュ向けに最適化されていることを確認します。
パネルを閉じるコードを書いてみました。これに差し替えるとどうですか?
考慮すべき箇所はパネルだけではないのでこれで完成、というわけではないんですが。動けば条件分岐は合ってるってことで一旦は切り分けられそうです。
試してみましたが「前より施策が効いてる気がする」感じで、完全に制御できてない感じです。
どんな時にキャッシュが効いてて、どんな時に施策が当たってるのかわからないというか...
検証の仕方を明確にさせた方がいいですね。
念のためandroidのchromeのキャッシュを全削除
↓
シークレットタブで開く
↓
メニューを展開してページ遷移
↓
chromeの戻るボタンまたはスワイプで戻る
という感じでしょうか。
今同じ環境で検証してるんですが、施策が効いてますね。
ただ、バックした瞬間にはメニューが開いていたのがわかる(変遷した後、あったのが消える)って感じですね。
遷移してから発火するイベントなので、そういうもののような気がしますけどねー。
コードの内容からすると、こうなりますよね、当然。
だと思います。なので、やるやらないは置いといてですがチラッと見えるのですら嫌ならmetaでキャッシュ無効にするくらいじゃないですかね。
これどんなですかね?まっさらにわりと近づいたような…(時間設定部分をカットしてclass外し特化)
/** Bfcache Disabled */
function nishikiProDisableBfcache() {
window.addEventListener('pageshow', function(event) {
if (event.persisted || performance.getEntriesByType("navigation")[0].type === 'back_forward') {
// パネル全て閉じる処理
document.querySelectorAll('.panel-open').forEach(function(panel) {
panel.classList.remove('panel-open');
});
}
});
}
nishikiProDisableBfcache();
僕の場合、中にある例のタブメニューがたまに消え遅れちゃうんですがw
settimeoutの時間と連動するようにしてメニューの展開も閉じているので正しい動きではあります。
これでどうですか。
タイムラグが出ちゃいますねー。
そして…見つけたくなかったんですが…
閉じた後にもメニューが見えないクリッカブルなものとして残っている可能性が…
(どちらのスクリプトでも発生)
ここまで来るともう神が手を出すなと言っているような気がしているような気がしなくもないです😭
手元にandroid実機がない上にchromeのシミュレーターだと再現されないので開発効率落ちるんですよねー。
そもそもやらなくていい施策だと僕は思っていますw
操作の様子を録画できませんか?
シークレットだと真っ黒画面になるかもです。(撮ったけどなった)
閉じた後にもメニューが見えないクリッカブルなものとして残っている可能性が…再現できなくなりました… この件は一旦保留でも良いかもしれないですね。 とりあえず僕は自前のやつで微対応しておくので。
そもそもやらなくていい施策だと僕は思っていますw確かになんですが、Nishiki Proはドロワーが全画面に広がる前提なので画面の変遷等の体感が利用者にわかり辛いと厄介ではあると思うんですよね。 一番気になるのは利用者の体験を妨げなければ、BFCacheは悪いものではない(むしろ良い)ですけど、作り手もそこ意識しなきゃと思うので… むずいっすねー😩
僕は全画面にドロワーでも構わないですし、むしろ戻る操作をしたら自分が操作したそのままの状態が保たれているのは便利だと思う利用者なので、考え方はそれぞれだなあと思います。
実装難しいので、戻る操作があったらシンプルにリロードする、でいい気がします。
一般のHTMLキャッシュとは違うとはどこかで読んだので(BFCacheはスクショ)、リロードで良いのかもしれないっすね!
スーパーリロードがかかるイメージでしたが違うみたいなので表示速度も気にしなくて良いかもしれないですし。
リロードがベストだとは思いませんけど、確実に再現できる方法を取るのがいいでしょうね。
テーマ側としての対応は今のところ見送りたいと思います。
了解しました!見送りがいいと思います!
僕もちょこちょこリアルの反応見ながら再考したいと思います。