See bug 336682 comment 24 and the attached testcase. From comment 24: > Er, really? Does that break pages that try to have a |var ononline| or that > assign something like a number to a global ononline variable? See bug 336359 > comment 12. > > If it does, is that really what we want? The testcase here indicates that window.ononline/onoffline is treated like a handler when assigned a function, albeit with the quirkiness of bug 380538. I don't see how this breaks pages that assign numbers/booleans to global vars named ononline/onoffline, but I could have missed something.

If it doesn't break such pages (i.e. if the properties are replaceable), then I don't think we have a problem, really... Need to figure out whether it does break them or not, basically.

If there are other ways for authors to do this, do we really want to pollute the global namespace every time we add new events?

(In reply to comment #1) > If it doesn't break such pages (i.e. if the properties are replaceable) Well, what I did was doing var ononline = 1; directly in a <script> and then checking the value later in a load handler (after the testcase triggers the events, not that it should matter). Anything else needs to be checked? If you have a list of uses we shouldn't break with new window.on* handleres, they could be turned into a mochitest.

Jst will figure out what to do :)

content/events/test/test_bug336682.js has 'todo()'s because of this bug. However this bug is resolved, that test should be updated.

Setting to B1 per conversation with JST.

Per discussion with Chris Double and Dave Camp, we'll be removing the support for window.ononline and window.onoffline in favor of the standard and more flexible window.addEventListener() method of registering listeners for these new events. Patch coming up.

Fix checked in.

With this patch, did we stop supporting |body.ononline = function () {}| as well? If so, is that what we want to do?