スキップしてメイン コンテンツに移動

Google ChromeでDOMContentLoadedが発生しないケースがある

タイトルのとおり

Google Chromeは大変速いブラウザですが、その速さ故か、たまにDOMContentLoadedが発生しないケースがあります。
以下のようなコードで再現確認できます。

HTML
<!DOCTYPE HTML>
<html lang="en">
<head>
 <meta charset="UTF-8">
 <title>domcontentloaded test</title>
</head>
<script type="text/javascript">
  (function(d){
   d.addEventListener('DOMContentLoaded', function(){ alert('nya-'); }, false );
   var s = d.createElement('script');
   s.src = 'hoge.js';
   s.charset="UTF-8";
   var h = d.getElementsByTagName('head')[0];
   h.insertBefore( s, h.firstChild );
   })(document);
</script>
<body>
  <h1>debug</h1> 
</body>
</html>

JavaScript(hoge.js)
document.addEventListener('DOMContentLoaded', function(){ alert('nya-2'); }, false );

解決策

window.onloadにイベントを割り当てましょう。
具体的には以下のコード
var isLoad = false;

document.addEventListener('DOMContentLoaded', function(){ isLoad = true; alert('nya-2'); }, false );

window.addEventListener('load', function(){ if( !isLoad ){ alert('nya-2'); } }, false );


最後に

この現象は、たまたま今日見つけたものです。
もしかしたら、僕の環境だけで発生するレア現象なのかもしれませんが、同様のケースで困った方がいらっしゃいましたら、何かの参考にして頂けたら幸いです。

コメント

  1. DOMContentLoadedが発生しないのではなく、後から追加したscript要素内でDOMContentLoadedに登録してもDOMContentLoadedの発生に間に合わないことがあるってことですよね。
    createElementして追加したscript要素の実行タイミングは保証されていないので、Chromeに限らず、DOMContentLoadedに間に合わない可能性はあります。(といいつつ、FirefoxとOperaの実装では実行タイミングを保証しています)。

    返信削除
  2. >os0xさん

    コメントありがとうございます。

    >DOMContentLoadedが発生しないのではなく、後から追加したscript要素内でDOMContentLoadedに登録してもDOMContentLoadedの発生に間に合わないことがあるってことですよね。

    って事です。
    難しいですね、日本語。

    返信削除
  3. とりあえず、hoge.js を以下のようにすると動作するようです。

    ---
    (function (loadedListener) {
     var doc, readyState;

     doc = document;
     readyState = doc.readyState;

     if (readyState === 'complete' || readyState === 'interactive') {
      loadedListener();
     } else {
      doc.addEventListener("DOMContentLoaded", loadedListener, false);
     }
    })(function () {
      alert('nya-2');
     });
    ---

    document.readyState === 'interactive' 以上が保証されれば、DOMContentLoaded 以降のタイミングのはずなので問題ないと思います。
    このままでは第一引数で event を受け取れないのがネックですが。

    返信削除
  4. >think49さん

    コメントありがとうございます。

    documentのreadyStateを使う方法は試したのですが、IE(憎き奴です)で上手く行かなかったので、諦めました。
    ただ、IEを無視するならば、その判定方法がスマートですね。

    返信削除

コメントを投稿

このブログの人気の投稿

EFIブートローダを移動した話

EFIブートローダを移動した HX90に環境を整え終わってから、アホな事をしたので、その記録を残す。 SSD: Cドライブ SSD: Dドライブ(データストレージ用) + ESP※ SSD: Eドライブ(データストレージ用) ※ESP(EFI System Partition) インストールした時、こんな構成だった。 ESPがDドライブにあるのが気持ち悪かったので、これを削除した。 そしたら、BIOS画面が出るだけになり、Windowsが起動しなくなった。 移動手順 この時の自分はMBRをふっ飛ばした時と同じ現象だと思ったので、MBRというキーワードで検索したが、今はEFIブートローダーと呼んでいるらしい。 【Win10】任意のディスクにEFIブートローダをインストールする 色々検索した結果この記事が参考になった。 Diskpartを使って、パーティションを新たに分割し、bcdbootを実行して、無事に事なきを得た。 パーティションの分割はこんな感じ Diskpart Select volume 0 shrink desired = 200 Select disk 0 Create partition EFI size=200 Format quick fs=fat32 label="ESP" Assign letter=P exit EFIブートローダーのインストールはこんな感じ bcdboot C:\Windows /s P: /f UEFI ちなみに、自分の環境だけの問題なのだが、コマンドラインで、「\」を入力するのができなかった。我が家のキーボードはHHKBだけなので、日本語配列を無理やり適用されると、バックスラッシュが入力できないという不具合が生じる。 結局、コマンドプロンプトからマウスで範囲選択してコピーして貼り付けるという荒業でクリアした。 普通の人は、何も考えずに、\を入力すれば良い。 最終的に SSD: Cドライブ + ESP※ SSD: Dドライブ(データストレージ用) SSD: Eドライブ(データストレージ用) ※ESP(EFI System Partition) という構成に切り替えることができた。

PlemolJP導入

PlemolJP を導入した 思い立つことがあり、 PlemolJP をインストールする事にした。 自分は、PowerLine を使っているので、PlemolJP Nerd Fonts 版である、PlemolJP_NF をダウンロードしてインストールした PlemolJP の releases から、PlemolJP_NF_vx.x.x.zip をダウンロードする。 zip を展開し、PlemolJPConsoleNF-Regular.ttf をインストールする set guifont=PlemolJP_Console_NF:h18 を gvimrc に書く(フォントサイズはお好きに) ちなみに、これは Windows 限定の設定なので、Mac や Linux などで導入する際には、別の方法をオススメする。 余談 gvimrc に指定するフォント名が微妙にわかりづらい。 普段は、 set guioptions-=m してメニューバーは出していないが、今回は :set guioptions+=m を実行して、編集 → フォント設定からフォントを選び、フォント名に入力されている文字列をコピペして、スペース部分をアンダースコアで置き換えた。 この辺のルールとかに詳しい人にぜひとも教えて欲しい所。 導入した感想 今までの Powerline フォントはいまいちなのが多かったが、PlemolJP の表示は非常に良い。 今後はこちらをメインで使って行きたい。 あと、僕はヱビス派です。