Closed Bug 656311 Opened 11 years ago Closed 9 years ago
Remove XML Events, or improve the implementation
Since XForms hasn't really gained support, I think we could remove support for XML Events from the core. The implementation doesn't seem to handle all the dynamic changes properly (blame me) and once parentNode and ownerDocument become strong, all the XML Events code should be carefully audited to not cause leaks. One could implement XML Events in XTF. The question is that should there be XML Events extension before removing the support from core. Aaron, Surkov, any comments?
(In reply to comment #0) > The question is that should there be XML Events extension before removing > the support from core. this is really desirable I think, otherwise we make extra work for guys who still (or going to) do some xforms work. Having an extension is a friendly way.
I personally think that any technology that Mozilla supports that distinguishes itself from webkit or IE is a good thing. Especially one that costs Mozilla next to nothing in size, speed, memory or developer cycles. There are still mozilla xforms users out there, I believe, and I think they use it to do real work. I don't think that this should be pulled unless there is an extension to replace it or until the xforms users are at least notified and offered a chance to comment. Addons says that there have been 300K+ downloads of xforms, afterall (the accuracy of that is, of course, up for debate :-)
Other option is that I'll just (1) fix XML Events implementation to not leak when parentNode/ownerDocument is strong . And also (2) make it handle dynamic modifications better. (1) is pretty easy.
Assignee: nobody → Olli.Pettay
Summary: Remove XML Events → Remove XML Events, or improve the implementation
I actually think it's a bad thing when we have a feature in the tree exposed to the web that other browsers don't and don't intend to add. Differences between browsers is bad for the web. It's also not free to keep the code in the tree. Both because it needs to be maintained (such as in this case when our memory model changes slightly), and because it adds complexity to the code which makes it harder to understand and approach for beginners. I say lets deprecate the code the way we normally do it, by putting a warning message in the error console whenever it's used saying that it'll get removed soon, to give people a chance to find a replacement, and then remove it in a few releases. However I'd be fine with leaving it in a warning state a bit longer than usual to give people a chance to write a replacement.
(In reply to comment #4) > I actually think it's a bad thing when we have a feature in the tree exposed > to the web that other browsers don't and don't intend to add. Differences > between browsers is bad for the web. Ugh, you sound like a Home Owners Association! :-)
(In reply to comment #4) > I actually think it's a bad thing when we have a feature in the tree exposed > to the web that other browsers don't and don't intend to add. Differences > between browsers is bad for the web. I came here to say just that. Thanks, Jonas :)
If we do bug 749448, there isn't really any use for XML Events either. Any objections if I just remove both features. They will be still in ESR17 until the end of 2013, IIRC.
Same as in bug 749448, I don't see a future for Mozilla XForms, and if that's the only user, let's remove it.
Attachment #681505 - Flags: review?(bzbarsky)
Comment on attachment 681505 [details] [diff] [review] patch r=me
Attachment #681505 - Flags: review?(bzbarsky) → review+
You need to log in before you can comment on or make changes to this bug.