IE8以下でのaddEventListener、removeEventListenerへの対応について

Question

閲覧ありがとうございます。
自作ライブラリのIE8以下への対応に苦労しております。様々なメソッドがIE8以下には存在しませんがObject.keysなどについては自己解決しております。
今回知恵をお借りしたいのはaddEventListenerのIE8以下対応についてとなります。またそれにいくつかの条件があります。

第一にコードはFirefoxなどで動くコードから変更を加えず対応する予定です。

//参考コード(実際のコードはコンストラクタの中でObject管理しております)
function OutputConsole(){
    console.log("True");
}

document.getElementsByTagName("body")[0].addEventListener("click",OutputConsole,false);

このようなコードがIE8以下で動くようにしたいです。prototypeの拡張（汚染）なども今回は問題ありません。
（そのメソッドがないことを確認した後、代入するため）

第二にjQuery等外部ライブラリは使用しない方が好ましいです。理由として自作ライブラリが単独、または同じく自作の補助ライブラリで成立し動作することを目標としているからです。

第三に引数の使用も可能であればそれが望ましいです。

function OutputConsole (_String){
    console.log(_String);
}
//無名関数でのラップ
document.getElementsByTagName("body")[0].addEventListener("click",function (＿EventObject){OutputConsole(_EventObject.target);},false);

removeEventListenerについても同様の条件であると考えてください。
またIE6に存在するメモリリークに対応できていれば理想的です。

質問内容は以上となります。
一応の目標はIE6以上への対応です。
期待している回答としましては具体的なコード（または参考となるURL等）とその考察、思想などを示していただけるとありがたいです。また前述のとおり、prototypeの変更を含めて元から存在するObjectの拡張を行うつもりなのですがその処理についても記載していただけるとありがたいです。
具体的には以下のような部分になります。

//Object.keys
if(!("keys" in Object)){
    Object.keys=function (_Object){
        var _Keys=[];
        for(var key in _Object){
            _Keys[_Keys.length]=key;
        }
        return _Keys;
    }
}

よろしくお願いいたします。

Answer 1

正直、prototype拡張でDOM操作関数の追加は不可能だと思っていたのですが…

addEventListener polyfillと検索した所、素晴らしいコードを見つけました。
(なお、polyfillとは、古いブラウザなどでモダンブラウザと同等の機能を提供する手法を意味する用語です。個人的には、jQueryのような専用関数などでの対応ではなく、prototype拡張などで対応するライブラリを示す用語だという捉え方をしています。)

addEventListener polyfill for IE6+

IE5(F12開発者ツールのエミュレート)でテストしましたが、問題ないようです。

ただし、このコードはaddEventListenerのみに対応しています。
(その影響でjQueryと併用した場合に問題がおきるようですが…)

removeEventListenerを実装する場合、
このコードがpreventDefaultとstopPropagationを実装するため内部でattachEventに無名関数を設定している問題を考慮する必要が出てきます。

/* 以下のコードを想定する場合… */
function OutputConsole() {
    console.log("True");
}

document.body.addEventListener("click", OutputConsole, false);

/* 内部的には以下のように動作しているため、イベントを削除できない */
function OutputConsole() {
    console.log("True");
}

document.body.attachEvent("onclick", function (e) {
    var e = e || window.event;
    e.preventDefault = e.preventDefault || function () { e.returnValue = false }
    e.stopPropagation = e.stopPropagation || function () { e.cancelBubble = true }
    OutputConsole.call(document.body, e);
});

それを解決するため、少々お待ちください…

---

上記に対応したコードを書いてみました。
addEventListener polyfill for IE6+のコメント欄にも記載し、意見を求めている段階です。
Internet Explorer 11.0.9600.17501のF12開発者ツールでも検証しましたが、IE5,7,8の全てのエミュレートでイベントの追加・削除ができています。
(蛇足ですが、Event.preventDefaultとEvent.stopPropagationの他にEvent.target、Event.currentTarget、Event.timeStampにも対応させています。)

ただし、追加したリスナー(関数)の参照を維持するために配列を利用しており(変数listenersがこれにあたります)、
全てのDOM要素からリスナーを削除しても配列内に参照が残ってしまう弱点が存在します。
実機のIE6ではテストしていないので、メモリリークの問題については保証できかねますが…

addEventListener & removeEventListener polyfill 1.0 - Qiita

---

listeners_get,listeners_set関数の中身を改良してみました。
addEventListenerで追加したリスナーに対応する無名関数を、リスナーのx-ms-event-listenersプロパティとして設定しています。
(JavaScriptでは関数もオブジェクトなため、関数に連想配列のように値を設定できます)
これで、リスナーを完全に削除すれば無名関数への参照も消え、メモリリークのリスクをわずかに抑えられるかもしれません。

addEventListener & removeEventListener polyfill 1.1 - Qiita

Comments

[Cf_cwd]

回答ありがとうございます。エミュレートされたIE5での動作確認をいたしました。
なるほど、polyfillですか。クロスブラウザというワードでで情報収集をしていました。polyfillという言葉は聞いたことがありましたが具体的には何かということを考えたことはありませんでした。補足説明ありがとうございます。

自作しているライブラリがdivタグなどを生成し、ランダムなIDを設定して出力。クローズボタンでそれを削除でき、同時にイベントを削除する。という処理内容になっており、removeEventListenerができることは重要な要素になっております。そのため解決に期待しております。

あまり考えがまとまっておらず妙なことを言っているかもしれませんが無名関数への参照を残すような管理部を作る必要がありそうですね。

[sounisi5011]

回答の編集では通知が届かないかもしれませんので、一応コメントしておきます。

IE11のエミュレートでも動作するコードをとりあえず書けました。
Closure CompilerのAdvancedモードで圧縮できるよう、細かくコメントを追加しています。
ただ、IE6のメモリリーク問題については保証できかねます…

[Cf_cwd]

function等がObjectであることはもちろん知っております。
リスナーの削除と同時に配列の当該要素にnull代入で参照を切れば問題なさそうですね。
Objectにプロパティーとして値を持たせた場合はdelete演算子で削除するような形になりますかね。
IE11にはaddEventListenerがあるはずですが私の記憶違いでしょうか？もしくは細かい仕様の違いがあるのでしょうか？

[sounisi5011]

> IE11にはaddEventListenerがあるはずですが私の記憶違いでしょうか？もしくは細かい仕様の違いがあるのでしょうか？

IE11のF12開発者ツールで、エミュレートしたIE5,7,8でも動作するという意図で書きました。
誤解をするような表現を用いてしまい、申し訳ありません。

[Cf_cwd]

了解しました。こちらでも動作の確認をいたしました。こちらにコメントする際にコードを提示しようと回答の方からコピーしたところ誤って空の回答を投稿してしまったため、そちらに私が改変したコードを記載しました。問題点等指摘していただければ今後の参考にさせていただきたいと考えております。
（なぜlowerCamelCaseでないのかと疑問に感じると思います）

[Cf_cwd]

ご指摘ありがとうございます。まったくそのとおりであると思います。恐らく自分のテストで動いたコードと貼ったコードに違いがあるのが私の混乱の原因であると思われます。ご指摘を真摯に受けとめ、精進いたします。
具体的なコードの提示と改善案の提示なども判断に含め、ベストアンサーとさせていただきます。

Answer 2

　途中経過で書き込む事をお許し下さい。
IE8のエミュレートで以下のコードをテストすると動作しました。たぶん。ですが、IE7ではダメのようです。

Window.prototype.addEventListener = function(type, handler, f){
  var _self = this;
  this.attachEvent("on" + type, function(e){handler.call(_self,e)});
}
HTMLDocument.prototype.addEventListener = function(type, handler, f){
  var _self = this;
  this.attachEvent("on" + type, function(e){handler.call(_self,e)});
}
Element.prototype.addEventListener = function(type, handler, f){
  var _self = this;
  this.attachEvent("on" + type, function(e){handler.call(_self,e)});
}

window.addEventListener('load',function(e){console.log(this,e);})
document.addEventListener('click',function(e){console.log(this,e);})
document.getElementsByTagName('div')[0].addEventListener('click',function(e){console.log(this,e);})

　Element が定義されてなかったりするようなので、ちょっと限界を感じました。
他の回答を質問者と一緒に待ちたいと思います。

Comments

[Cf_cwd]

お早い回答ありがとうございます。同じくエミュレートされたIE8での動作を確認いたしました。無名関数でも動作するのでIE8にこれで対応できたといえるでしょう。私も限界を感じたため、初めてここで質問してみることにいたしました。回答をクリスマスプレゼントとして待つことにしましょう。

Answer 3

間違えて投稿されてしまいました。
コードに関しましては後程、Objectを主体にして作成できるか試してみることとします。

指摘いただきありがとうございました。問題点が多く自分でも疑問に思う点が多いためコードを削除させていただきます。

Comments

[sounisi5011]

16行目、addEventListenerメソッドの対応判定ですが、
"addEventListenerListener" になっています。
正しくは "addEventListener" です。

70行目、addEventListener関数内の無名関数内でthisが利用されていますが、
attachEventメソッドのthisはwindowオブジェクトになってしまうので、attachEventメソッドの中でthisは利用するべきではありません。

また、59行目と78行目、addEventListener関数とremoveEventListener関数にて、
第二引数が関数でない場合に return ""; としていますが、仕様でaddEventListener,removeEventListenerは undefined を返すよう定められています。
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Registration-interfaces
return; とした方がいいでしょう。
(まあ、そもそも返り値が利用されることは無いためどうでもいい話ではありますが…)

さらに…これは私のミスでもあるのですが…
69行目、addEventListener関数内にて、
Event.timeStamp で Date.now がある場合に利用するよう判定を行っていますが、
Date.now はIE9以降でサポートされたためこの判定は意味をなしていません。
Qiitaの記事では修正を行いました。

EventObject.timeStamp=EventObject.timeStamp || (Date.now ? Date.now() : (new Date().getTime()));
↓
EventObject.timeStamp=EventObject.timeStamp || (new Date()).getTime();

あと、136行目、最後の部分に以下のコードがありますが

InsertEventListener(window,document);

こうではないでしょうか?

InsertEventListener([window,document]);

InsertEventListener関数は第二引数の指定を想定していません。
DOMノードやwindow,Documentオブジェクト、またはそれらで構成される配列やNodeListオブジェクトを想定したコードです。
なお、この部分を以下のようにするのは誤りです。

InsertEventListener(window);
InsertEventListener(document);

windowオブジェクトにlengthプロパティがあったはずなので、配列と誤認識してしまいます。
わざわざ配列にして実行しているのはこれを防ぐためと思われます。

最後に、これは単なるコードの書き方の問題でもあるのでしょうが…
101行目から140行目にかけての最後の条件分岐、
XB_EventListenerManage オブジェクトを定義し実装していますが、
普通にif文のコードではダメでしょうか?
関数がより多く実行され、thisも利用され、オブジェクトのためのメモリが確保される分、IE6などで重くなりそうですけれど…

[Cf_cwd]

文字列置換した時の間違ったソースを貼ってしまったようです。申し訳ない。訂正いたしました。

またいくつか疑問があるので提示させていただきます。
まずaaEventListener(==addEvent)関数の処理についてですが

var self=this//==window
以上よりthisがwindowを指すことに関して問題ないと考えます。attachEventに使用している無名関数もthisはwindowを指すため、self==this==windowとなり等価であると考えますがいかがでしょうか？
```lang-javascript
(function (){
function OutputConsole(){
console.log(this);
}
OutputConsole();//window:IE5-IE11
(function (){
console.log(this);
}());//window:IE5-11
}());
```

次にInsertEventListener(addListen)関数についてなのですがwindowがグローバルスコープであるため、結果的にwindow.documentでdocumentにもaddEventListenerが追加されていたということでいいのでしょうか？

条件分岐に関してですがwhileを回して代入するなどの処理がある以上重くなるのは想定したうえでの記述であると考えております。
(単純なif文との比較で少なくともIE8や9では恐らく0.1ms未満の差しか出ないと考えます。現行ブラウザでconsole.time、console.timeEndを用いて確認した限りでは大きな差はありませんでした(0.05-0.1以内どちらが早いともいえない結果に)。確かにIE6などでどう動くかは心配ではありますが……)

またスコープを限定した定義ですから即時関数の実行後XB_EventListenerManageは未定義になるため、メモリを圧迫することはないと考えていたのですが何か認識不足の点があるのでしょうか？
(当方IE6などの仕様についてはそこまで深く知らないため)

[sounisi5011]

> var self=this//==window
> 以上よりthisがwindowを指すことに関して問題ないと考えます。attachEventに使用している無名関数もthisはwindowを指すため、self==this==windowとなり等価であると考えますがいかがでしょうか？

var self=this;

この時のthisはwindowオブジェクトではありません。
addEventListener(addEvent)関数はDOMオブジェクトのprototypeに指定するのでthisはDOMオブジェクトになります。
attachEventメソッドに指定した無名関数では、thisがwindowオブジェクトになります。
このため、無名関数の外でthis(DOMオブジェクト)を変数selfに確保し、無名関数内でそれを参照させるのが望ましいでしょう。

addEventListenerメソッドのリスナーでは、thisは設定したDOMオブジェクトを示します。
が、attachEventメソッドのthisはwindowオブジェクトを示してしまいます。
この違いを解決するため、第二引数のリスナーに対してわざわざ call メソッドを実行しています。
self==this==window であるならば、わざわざ call メソッドを利用する必要はありません。

> 次にInsertEventListener(addListen)関数についてなのですがwindowがグローバルスコープであるため、結果的にwindow.documentでdocumentにもaddEventListenerが追加されていたということでいいのでしょうか？

windowオブジェクトに関しては、prototypeではなくwindowオブジェクトそのものに直接addEventListenerメソッドを追加しています。
このため、windowオブジェクトが変更されてもdocumentには反映されません。
実際、テストした際、ここのミスで私のコードは動作しませんでした。

> 条件分岐に関してですがwhileを回して代入するなどの処理がある以上重くなるのは想定したうえでの記述であると考えております。
> (単純なif文との比較で少なくともIE8や9では恐らく0.1ms未満の差しか出ないと考えます。現行ブラウザでconsole.time、console.timeEndを用いて確認した限りでは大きな差はありませんでした(0.05-0.1以内どちらが早いともいえない結果に)。確かにIE6などでどう動くかは心配ではありますが……)
>
> またスコープを限定した定義ですから即時関数の実行後XB_EventListenerManageは未定義になるため、メモリを圧迫することはないと考えていたのですが何か認識不足の点があるのでしょうか？
> (当方IE6などの仕様についてはそこまで深く知らないため)

whileは必要不可欠なループです。
document.allにある全ての要素に対して処理を行う必要があるためです。

しかし、XB_EventListenerManageオブジェクト回りの無名関数は助長です。
例えすぐに開放されるとはいえ、一時的にでもメモリを確保することに間違いはないですし、
そもそもwhileで重いのだから他で更に重くする必要は無いのではないでしょうか。

また、IE6は非力なので、IE8,9でパフォーマンステストを行うことに意味はありません。
実行速度やパフォーマンスについて、実機テストでしか評価する事はできません。
残念ながら私の手元にIE6は無いので、検証できない以上単純化できる箇所は単純化しています。

私からすれば、if文で書けばいい処理を複雑化しているこの箇所の意図が不明です。