it goes to a infinite loop if the event is a bubble_event and while bubbling if one of the ancestor node calls the same event on the target node which originated the event suggestion for fixing is that don't call the event : 1) if the event phase is BUBBLING_PHASE 2) and if the current event's target element(the originator of the event) is the same as the node on which the event is going to be invoked 3) and if the event types(id such as click,focus etc) of the above two nodes are same. Please suggest any drawbacks to this fix or if there is a better fix. The test page is: <html> <head/> <body> <form> <div onclick="JavaScript:alert('div element');JavaScript:document.getElementById('segment116985839').click();"> <input name="segment1" id="segment116985839" value="test" type="radio" onclick="javascript:alert('input element');"> </div> </input> </form> </body> </html>
Created attachment 8650 [details] test case
Created attachment 8935 [details] patch for fixing the bug
Created attachment 8936 [details] patch for fixing the bug
Comment on attachment 8935 [details] patch for fixing the bug Duplicate copy of patch. Removing it.
Comment on attachment 8936 [details] patch for fixing the bug This patch won't work, because it's got DOM:: and Undefined() in it. Those are long-renaemed things that don't exist in our current tip of tree. It's also not formatted based on the style guildlines. In addition, I don't think this fix is correct. It checks for one of the many different ways an infiite loop could happen, and it could prevent legitimate code that loops once from working. There are all sorts of other similar infinite loops that this code change would not prevent, for example, one involving two different events that each dispatched the other. What we need to diagnose this is a test page that works in other browsers and fails in WebKit so we can figure out what behavior is wrong. I'm absolutely certain this isn't it. Infinite loops can happen, and the way to handle that is to allow you to interrupt the script.
We should figure out what's different that prevents this from being an infinite loop in Firefox. It's possible that the click() function in Firefox is a no op if you're already inside another invocation of click(), which could explain why Firefox goes through the loop twice, but not more than twice.
This appears to work correctly in r25813.