Consider the following code (PresShell::FlushPendingNotifications): mViewManager->BeginViewUpdateBatch(); // Stuff that can change the viewmanager hierarchy mViewManager->EndViewUpdateBatch(); The issue is that processing restyles can cause XBL constructors to run, so the viewmanager hierarchy can get rearranged. At the end of the method, mViewManager may no longer have the same root, so we end up with a "stuck" view update batch....
A testcase here would be nice...
My XBL fu is a little weak to write one easily, but the basic idea would be to have a document with a subframe (probably iframe). In the subframe, we make sure some XBL binding is loaded (so it can be applied sych), then trigger a restyle that applies that binding to a node and immediately flush notifications (e.g. get document.body.offsetWidth). Then make sure the constructor of the binding removes that iframe from the DOM.... That should kill painting for the parent document.
Assignee: roc → nobody
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.