If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Remove nsDocument's image tracking in favor of letting content and frames manage the same state themselves

Assigned to



2 years ago
2 years ago


(Reporter: seth, Assigned: seth)


(Depends on: 3 bugs)

Firefox Tracking Flags

(Not tracked)




2 years ago
After bug 1259281, bug 1261554, and bug 1218990 land, there will no longer be any reason to track images in nsDocument, and indeed doing so adds an unnecessary layer of additional complexity. The replacement mechanisms are as follows:

- Increments and decrements of animation consumers for content images will be handled in nsImageLoadingContent::OnVisibilityChange() and for CSS images in nsFrame::OnVisibilityChange(). The policy we should have is that images get an animation consumer and register with the refresh driver if they're both animated and within the displayport (i.e. their visibility state is IN_DISPLAYPORT). When they transition out of that state, we decrement their animation consumer count and unregister them with the refresh driver.

- Increments and decrements of the lock count for content images will be handled, again, in nsImageLoadingContent::OnVisibilityChange() for content images and nsFrame::OnVisibilityChange() for CSS images. Images should be locked if their visibility state is MAY_BECOME_VISIBLE or IN_DISPLAYPORT, and unlocked otherwise.

- Enabling and disabling image animation globally for the document should just be handled with a flag on the refresh driver; this makes drastically more sense than the current approach.
You need to log in before you can comment on or make changes to this bug.