Bug 1935728 Comment 8 Edit History

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

Original comment by
on 
(In reply to Bugmon [:jkratzer for issues] from comment #6)
> A pernosco session for this bug can be found [here](https://pernos.co/debug/BZsPuaF5WbUd3Ty1FG6P6w/index.html).

This pernosco session seems to be lacking sources; I emailed jkratzer to see if that's a known issue (don't want to start a side conversation here).   That makes the pernosco session a bit trickier to debug but not impossible.

Stepping back a bit, we've got some notes on why this assertion is important (and why we expect it should hold) here:
https://searchfox.org/mozilla-central/rev/5ad94327fc03d0e5bc6aa81c0d7d113c2dccf947/layout/base/nsPresContext.h#1268-1275
```cpp
// This is a non-owning pointer. May be null. If non-null, it's guaranteed to
// be pointing to an element that's still alive, because we'll reset it in
// UpdateViewportScrollStylesOverride() as part of the cleanup code when
// this element is removed from the document. (For <body> and the root
// element, this call happens in nsCSSFrameConstructor::ContentRemoved(). For
// fullscreen elements, it happens in the fullscreen-specific cleanup invoked
// by Element::UnbindFromTree().)
mozilla::dom::Element* MOZ_NON_OWNING_REF mViewportScrollOverrideElement;
```

In this case, the element does seem to be the `body` element -- the innermost `UnbindFromTree` call (the one that makes the assertion) has `this` being of type `HTMLBodyElement`.  The code-comment quoted above says that I should look at `nsCSSFrameConstructor::ContentRemoved` to see where `mViewportScrollOverrideElement` should have been cleared in this case... but it seems `nsCSSFrameConstructor::ContentRemoved` was recently removed (or renamed-and-morphed) in bug 1931301, the regressing bug that bugmon + RyanVM identified in comment 5 and comment 7.
Revision 1 by
on 
(In reply to Bugmon [:jkratzer for issues] from comment #6)
> A pernosco session for this bug can be found [here](https://pernos.co/debug/BZsPuaF5WbUd3Ty1FG6P6w/index.html).

This pernosco session seems to be lacking sources; I emailed jkratzer to see if that's a known issue (don't want to start a side conversation here).   That makes the pernosco session a bit trickier to debug but not impossible.

Stepping back a bit, we've got some notes on why this assertion is important (and why we expect it should hold) here:
https://searchfox.org/mozilla-central/rev/5ad94327fc03d0e5bc6aa81c0d7d113c2dccf947/layout/base/nsPresContext.h#1268-1275
```cpp
// This is a non-owning pointer. May be null. If non-null, it's guaranteed to
// be pointing to an element that's still alive, because we'll reset it in
// UpdateViewportScrollStylesOverride() as part of the cleanup code when
// this element is removed from the document. (For <body> and the root
// element, this call happens in nsCSSFrameConstructor::ContentRemoved(). For
// fullscreen elements, it happens in the fullscreen-specific cleanup invoked
// by Element::UnbindFromTree().)
mozilla::dom::Element* MOZ_NON_OWNING_REF mViewportScrollOverrideElement;
```

In this case, the element does seem to be the `body` element -- the innermost `UnbindFromTree` call (the one that makes the assertion) has `this` being of type `HTMLBodyElement`.  The code-comment quoted above says that I should look at `nsCSSFrameConstructor::ContentRemoved` to see where `mViewportScrollOverrideElement` should have been cleared in this case... but it seems `nsCSSFrameConstructor::ContentRemoved` was recently removed (or renamed-and-morphed) in bug 1931301, the regressing bug that bugmon + RyanVM identified in comment 5 and comment 7.  It was replaced with a function called `ContentWillBeRemoved`.
Revision 2 by
on 
(In reply to Bugmon [:jkratzer for issues] from comment #6)
> A pernosco session for this bug can be found [here](https://pernos.co/debug/BZsPuaF5WbUd3Ty1FG6P6w/index.html).

This pernosco session seems to be lacking sources; I emailed jkratzer to see if that's a known issue (don't want to start a side conversation here).   That makes the pernosco session a bit trickier to debug but not impossible.

Stepping back a bit, we've got some notes on why this assertion is important (and why we expect it should hold) here:
https://searchfox.org/mozilla-central/rev/5ad94327fc03d0e5bc6aa81c0d7d113c2dccf947/layout/base/nsPresContext.h#1268-1275
```cpp
// This is a non-owning pointer. May be null. If non-null, it's guaranteed to
// be pointing to an element that's still alive, because we'll reset it in
// UpdateViewportScrollStylesOverride() as part of the cleanup code when
// this element is removed from the document. (For <body> and the root
// element, this call happens in nsCSSFrameConstructor::ContentRemoved(). For
// fullscreen elements, it happens in the fullscreen-specific cleanup invoked
// by Element::UnbindFromTree().)
mozilla::dom::Element* MOZ_NON_OWNING_REF mViewportScrollOverrideElement;
```

In this case, the element does seem to be the `body` element -- the innermost `UnbindFromTree` call (the one that makes the assertion) has `this` being of type `HTMLBodyElement`.  The code-comment quoted above says that I should look at `nsCSSFrameConstructor::ContentRemoved` to see where `mViewportScrollOverrideElement` should have been cleared in this case... but it seems `nsCSSFrameConstructor::ContentRemoved` was recently removed (or renamed-and-morphed) in bug 1931301, the regressing bug that bugmon + RyanVM identified in comment 5 and comment 7.  It was replaced with a function called `nsCSSFrameConstructor::ContentWillBeRemoved`.

Back to Bug 1935728 Comment 8