Viewmanager hierarchy can change during a view update batch

NEW
Unassigned

Status

()

12 years ago
2 months ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---
Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
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....
Flags: blocking1.9?
A testcase here would be nice...
Flags: blocking1.9? → blocking1.9-
(Reporter)

Comment 2

12 years ago
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.
QA Contact: ian → layout.view-rendering
Assignee: roc → nobody
(Assignee)

Updated

2 months ago
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.