Description taken from Robert O'Callahan's and Kevin McCluskey's comments in bug 36849 The problem here is that updating has two phases -- reflowing and repainting -- if we ever repaint while there are pending reflows, we display something that is not a valid rendering of any state of the content. In addition, DOM changes can result in a combination of simple visual changes and reflow changes. The simple visual changes result in changes in frame state that if there is repaint will potentially result in the visual changes being displayed independently of the reflow changes. One solution would be to have the target of an event decide if the display needs to synchronized before the target can perform it's processing. For example, if the target of a keyevent is a textfield then it wouldn't want the display to be synchronized. It needs to batch the keyevent's without updating the display. If the target of a keyevent is a javaScript event handler that manipulates the DOM to generate a single frame of animation driven by the keyboard then it would need the display to be synchronized to avoid flicker. Another solution would be to force the processing of the relevant pending reflows every time we repaint.

Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.

Setting milestone to future

QA contact updated