Originally I filled this on Chromium (http://code.google.com/p/chromium/issues/detail?id=110464) but it is a WebKit issue. NULL deref on Webkit at bool Document::setFocusedNode(PassRefPtr<Node> prpNewFocusedNode) Root cause is here: Problem is the second dispatch without checking m_focusedNode == NULL 3435 m_focusedNode->dispatchFocusInEvent(eventNames().focusinEvent, oldFocusedNode); // DOM level 3 bubbling focus event. 3436 // FIXME: We should remove firing DOMFocusInEvent event when we are sure no content depends 3437 // on it, probably when <rdar://problem/8503958> is m. 3438 m_focusedNode->dispatchFocusInEvent(eventNames().DOMFocusInEvent, oldFocusedNode); // DOM level 2 for compatibility. Proof of concept: <html> <head> <title></title> <script language="JavaScript"> function run() { document.getElementById("h6_00").addEventListener('focusin', function () { try { this.parentNode.removeChild(this); } catch(e) {} } , false); document.getElementById("h6_00").focus(); } </script> </head> <body onload="javascript: run();"> <h1 tabindex="0" id="h6_00" ></h1> </body> </html>
Confirmed. I can reproduce it. It'd be great that we have a spec which tells us what should be done in this case. Let me investigate.
Created attachment 123281 [details] fix crash
Although I couldn't find any backing spec yet, it might be better to fix this by using similar check login in the local context than leaving crash.
typo: check login -> check logic. (In reply to comment #3) > Although I couldn't find any backing spec yet, it might be better to fix this by using similar check login in the local context than leaving crash.
Comment on attachment 123281 [details] fix crash ok. The whole function looks ugly, but it's not your fault.
Comment on attachment 123281 [details] fix crash Clearing flags on attachment: 123281 Committed r105665: <http://trac.webkit.org/changeset/105665>
All reviewed patches have been landed. Closing bug.
Mass moving XML DOM bugs to the "DOM" Component.