yet another. updated status to "[TESTCASE]..." standard.
Its not only for window.handleEvent. Its not yet implemented for any object. This method does not seem implemented for anyother objects also like button, checkbox, and so on...
Vidur, is this yours or joki's?
Sorry, Tom. Vidur says you probably have dups of these bugs already, so it shouldn't hurt _too_ much.
Moving 4.x event system features back to M13
Well the 4.x event stuff is done but its untested. Given that I had to make several changes to general event handling I think I'll take the conservative road this time and save this till the tree opens for M14.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Please give an example of a top100 page which uses this? Otherwise, we will mark [PDT-]
Info provided by desale via mail when asked WHY FOR BETA?: "Its not that beta would really suck without it, but its like one feature. Without it, we'll be totally missing the user defined ways of handling events. I mean, not lot of people use it, but there are some developers who use it. No its not blocking QA automation or anything. I just thought it would be better to have this one."
PDT- for b1
The function is implemented but we're still deciding how this will work in the new world. Pushing to a later milestone.
Adding nsbeta2 to keywords.
Putting on [nsbeta2+][6/01] radar. This work must be done by 06/01 or we may pull this for PR2.
joki, could you provide info on the following? 1) handleEvent() is part of the Nav4 DOM but not part of the W3C DOM? 2) handleEvent() duplicates functionality that exist already in a feature of the W3C DOM and provides no additional functionality the W3C DOM doesn't offer? 3) If we check in handleEvent(), do we expect to be able to provide full b.c. with the behavior of handleEvent() in Nav4, or will it be an inexact emulation of the old behavior that therefore appears buggy to the developer? 4) How much more work do you have to do to "finish" handleEvent() to the point of providing full b.c.? JS that used Nav4-specific features will typically need to be rewritten anyway. A "buggy" or "partial" emulation is probably worse than not doing it at all if equivalent functionality is available through the W3C DOM. If you have much work left to do on this, if b.c. will be less than complete, and/or if equivalent functionality is available through the W3C DOM, it's tempting to bite the bullet and drop this completely so you can focus on debugging our W3C DOM support and getting that right. I'd rather do whatever W3C DOM1/2 functionality we offer fully debugged than have partial, buggy support of both W3C DOM and Nav4 DOM features. Thoughts?
Changing from [6/01] to [6/15]
Per recent PDT triage, clearing [nsbeta2+][6/15] and closing as WONTFIX. handleEvent() was a proprietary Nav4 event handling method and is OUT for good. We will not attempt to provide b.c. with handleEvent() because the W3C DOM2 offers equivalent functionality through dispatchEvent(), which is already in. Will update http://home.netscape.com/browsers/future/standards.html to start informing developers how to do the upgrade. cc:ing dannyg as an FYI.
Sorry, marking WONTFIX for real this time.
As per Eric Krock's comments, Marking it Verified.