Version: (using KDE Devel) Installed from: Compiled sources Compiler: g++4.0.3 Kubuntu dapper x86_64 OS: Linux When doing addEventListener("DOMContentLoaded", callback, null); callback should never be called, as khtml doesnt support this *nonstandard* event. But if you create another unsupported event like contextmenu event and dispatch it on document it calls the DOMContentLoaded callback.
Created attachment 17696 [details] testcase that demoes this
Doh, makes sense. We just do fixed name -> id mapping (see EventImpl::typeToId, EventImpl::idToType), while I guess we need to add a dictionary for non-standard stuff, and not just map it to UNKNOWN internally. Any website we mess up on due to this? [And I bet we'll be forced to support DOMContentLoaded at some point...)
>Any website we mess up on due to this? I found it when bug fixing http://archive.dojotoolkit.org/dojo-2006-09-10/tests/widget/test_Tooltip.html Dont know if it actually affects a live website somewhere, but odds are we do. (I posted it here so it wont be forgotten, while I read up on C++ and try to get up to speed on bug fixing khtml and my commit privs..) >[And I bet we'll be forced to support DOMContentLoaded at some point...) Yes it would be nice, perhaps for KDE4? / Fredrik
Maksim, do you think it's OK to support DOMContentLoaded right now? It seems at this point all other browsers (not necessarily stable version) have some sort of early callback mechanism. I have the patch ready if you will. Will attach here since if not really related, it would in effect fix the symptoms of this bug.
Created attachment 22041 [details] patch. Support for non-standard "DOMContentLoaded" event
I think it's not only OK but a good idea, assuming you figured out the right place to emit it. Since we may emit load event in the same spot, it's probably safe.. See also #137428
from the descriptions I've read, it's quite plain, it must just fire right after parsing, not waiting for any delayed content, so it's the best spot I can think of. I have these passing: http://weston.ruter.net/projects/pre-onload/?loadimage http://tests.novemberborn.net/browsers/domcontentloaded/domcontentloaded.html http://tests.novemberborn.net/browsers/domcontentloaded/readstyle-domcontentloaded.html > See also #137428 indeed, and yes, it appears to work fine with the patch
SVN commit 736409 by ggarand: support non-standard Mozilla event DOMContentLoaded for compatibility. It fires as soon as the main document has finished parsing. CCBUG: 133887 BUG: 137428 M +1 -0 khtml_part.cpp M +4 -0 xml/dom2_eventsimpl.cpp M +2 -1 xml/dom2_eventsimpl.h WebSVN link: http://websvn.kde.org/?view=rev&revision=736409
Funny how I go look for DOMContentLoaded support in Konqueror, and I find a link back to my own test case :) I'm not fully up to speed on Konqueror release schedules, will this be in 3.5.9 / 3.6?
It's inside 4.0-pre sources now... Probably not too much effort to include into 3.5.9 if that release were to take place..
SVN commit 800710 by orlovich: Fix handling of events with custom names, while proving some infrastructure that is likely to be useful along the line.. That piece is the IDString template which simplies string<->ID mapping when a chunk of IDs is pre-allocated, could potentially be used for ID_ and ATTR_ as well BUG:133887 M +2 -1 CMakeLists.txt M +5 -5 dom/dom_node.cpp M +2 -2 ecma/kjs_dom.cpp M +2 -2 ecma/kjs_window.cpp M +50 -179 xml/dom2_eventsimpl.cpp M +54 -50 xml/dom2_eventsimpl.h M +18 -8 xml/dom_docimpl.cpp M +10 -5 xml/dom_docimpl.h M +40 -33 xml/dom_nodeimpl.cpp M +24 -21 xml/dom_nodeimpl.h M +50 -1 xml/dom_stringimpl.cpp M +3 -0 xml/dom_stringimpl.h WebSVN link: http://websvn.kde.org/?view=rev&revision=800710
SVN commit 800719 by orlovich: Add regression test for #133887 CCBUG:133887 A baseline/events/custom-listeners.html-dom AM baseline/events/custom-listeners.html-dump.png A baseline/events/custom-listeners.html-render A tests/events/custom-listeners.html WebSVN link: http://websvn.kde.org/?view=rev&revision=800719