I am not sure who owns this bug.... There are times when we need to know that we are in the middle of processing a DOM event so we can delay the processing of actions. For example, When user clicks on the "Product" listbox on the Bugzilla Query page, the onclick (or similar event) gets fired and some script executes that sets a sibling listbox's option's length to zero and then dynamically adds a lot of items to the listbox. What this action does, is calls SetLength in the select element content node which then calls "Remove" once for every item being removed. The Remove call ends up calling RemoveChild, then eventually "RemoveOption" gets called on the listbox frame. When the frame gets the RemoveOption call it doesn't know if this is a single call or one of many items being removed. It is all basically the same for adding items, meaning we don't know if it is a single add or one of many. Because this is pretty much asynchronous, the Combobox/Listbox wants to update it curently selected item or "reset" itself, each time an item is added or removed. This causes a lot of ineffeciencies (meaning FlushPendingReflows gets called) and the CBX or LSTBX gets reflowed each time. So if there was someway to know during all the processing, that certains things could be skipped until the end, that would make everything more efficient. But it would need to be notified when the processing was over so it could do the necessary work at the end. Currently, in my tree I have a patch where the select frame implements a timer (guessing at the delay), and defers all the work until the timer finally fires after all the removes or adds have happened. The performance gain is huge. See Bug 53165 and Bug 27233 It would be very helpful in the frame
Please ignore half sentence at bottom of previous message. adding nisheeth to cc' list
I am pretty sure Tom knows the answer to this...
So currently for events that are passed through the PresShell, and hence the ESM, we could add an API to tell when we are processing an event. There is not one now. For events that do not pass through the PresShell and are dispatched directly to their content via HandleDOMEvent there isn't a way to tell if we are in an event. Its possible we could discern this from some of the state set in the ESM but it'd be more fragile. Currently we fire a mix of events, some though PresShell, some not. My initial thoughts on this would be to stick with a timer. You could make it of zero length (or for that matter just create a PR_Event) and it would be guaranteed not to fire until the current event finishes processing.
I'll let Tom deal with this one :-)
Assignee: jst → joki
I'm going to mark this invalid unless someone can tell me a reason my solution won't work. If I do provide a way to check if we're handling DOM events it would still not handle the setTimeout or inline script cases. The PR_Event solution would handle all.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
verifying per developer's coment
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.