Dreamweaver CC 2017.1の[リアルタイムプレビュー]を使うと、<body>要素のonload属性もwindow.onloadハンドラハンドラも呼び出されなくなりました。Dreamweaver CC 2015.2や、ローカルからブラウザで開けば正しく動きます。少し調べてみました。
ローカルサーバーを開くとき悪さをしているらしい
Dreamweaver CC 2017から[リアルタイムプレビュー]が採り入れられ、ページがローカルサーバーで開かれるようになりました。状況証拠から判断して、ローカルサーバーを開くための処理がもっとも怪しい容疑者です。
あとの検証から、ほぼ間違いないという裏づけが採れました。Dreamweaver CC 2017の[リアルタイムプレビュー]の問題を避けるには、イベントloadやDOMContentLoadedにリスナーとして処理を加えるのがよいでしょう。
window.onloadのハンドラは上書きされる
Dreamweaver CC 2017の[リアルタイムプレビュー]が何をやっているのか気になります。そこで、つぎのようなテスト用のコードを書きました。
window.onload = function() {
alert('window');
}
window.onmousedown = function() {
var body = document.body;
console.log('widdow:', window.onload);
console.log('body:', body.getAttribute('onload'));
}
<body onLoad="alert('body')">
ウィンドウの中をクリックしてたしかめると、[リアルタイムプレビュー]で読み込まれるdeviceClientScript.jsがwindow.onloadのハンドラを書き替えているようです(図001)。
図001■JavaScriptコンソールの出力
window.onloadと<body>要素のonload属性
<body>要素のonload属性はどこにいったのでしょう。テスト用コードでは、属性値は残っていることが�確かめられました(前掲図001参照)。また、問題について検索していたとき、window.onloadと<body>要素のonload属性にいて「window, document, body のonload,onreadyイベントのそれぞれの違いの解説」につぎのような記述をみつけました。
最近のブラウザで実験してみたところ、二つが同時に使われる場合には、body.onloadのみが起動されます。body.onloadが存在しなければwindow.onloadが起動されます（現在Chrome 41及びFirefox 36で確認済み）。
でしたら、たとえwindow.onloadが上書きされても、<body>要素のonloadハンドラは呼び出されてよいはずです。そこで、[リアルタイムプレビュー]は使わず、ローカルからファイルをブラウザで開きました。
すると、なんということでしょう。たしかに、<body>要素のonloadハンドラの記述にしたがって警告ダイアログが開きました。けれども、コンソールの出力を見ると、window.onloadハンドラの処理が書き替わっています(図002)。window.onloadイベントで、<body>要素のonloadハンドラのJavaScriptコードが実行されているようです。
図002■JavaScriptコンソールの出力 ー ローカル
筆者の環境では、Chrome/Firefox/Safariとも同じ結果です。あいにく、その仕様はみつけられませんでした。<body>要素のonload属性は「ブラウザによって処理が異なる」ことがあるという説明も見かけました(「ページ読み込み後に処理を行う方法」)。現在であれば、はじめに述べたとおりイベントリスナーを用いるのがよさそうです。