Need to know that we are inside an DOM event




18 years ago
18 years ago


(Reporter: rods, Assigned: joki)


Windows NT

Firefox Tracking Flags

(Not tracked)




18 years ago
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

Comment 1

18 years ago
Please ignore half sentence at bottom of previous message.

adding nisheeth to cc' list
I am pretty sure Tom knows the answer to this...

Comment 3

18 years ago
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

Comment 5

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → INVALID

Comment 6

18 years ago
verifying per developer's coment
You need to log in before you can comment on or make changes to this bug.