Bug 1809115 Comment 11 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
> I think what you're seeing in that page is most likely bug 1901515.

I see it got a bit better with searchfox/IndexedDB  but the time needed to process it is still notable. Besides the block I am proposing to defer in bug 1902728, the other most notable pieces are:

- `mozilla::dom::Document::ClearStaleServoData` - sounds a bit like just memory clearing? Can we defer that, too?
- `nsFrameList::DestroyFrames` - unclear to me if that touches also things outside the frame tree? Probably yes?
- `nsIContent::UnbindFromTree` - running after `DestroyFrames` suggests it does not need its outcome? Would it be enough to just swap in an empty frame list?

From the names I can imagine we want `nsIContent::UnbindFromTree` to run sync, for the other two I do not know but it sounds a bit as if we could defer some of it.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
> I think what you're seeing in that page is most likely bug 1901515.

I see it got a bit better with searchfox/IndexedDB  but the time needed to process it is still notable. Besides the block I am proposing to defer in bug 1902728, the other most notable pieces are:

- `mozilla::dom::Document::ClearStaleServoData` - sounds a bit like just memory clearing? Can we defer that, too?
- `nsFrameList::DestroyFrames` - unclear to me if that touches also things outside the frame tree? Probably yes?
- `nsIContent::UnbindFromTree` - running after `DestroyFrames` suggests it does not need the frames? Would it be enough to just swap in an empty frame list?

From the names I can imagine we want `nsIContent::UnbindFromTree` to run sync, for the other two I do not know but it sounds a bit as if we could defer some of it.

Back to Bug 1809115 Comment 11