Bug 1579953 Comment 1 Edit History

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

The testcase contains a multicol `<details>` with `details::first-letter` style.  When trying to insert elements into the multicol `<details>`,  we suppose to reframe the `<details>` upon reaching [`WipeInsertionParent.`](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7192) However, early in `ContentRangeInserted`, [GetInsertionPrevSibling](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7144-7145) alters `insertion.mParentFrame`, which becomes a `Letter` frame inside the `DetailsFrame`. As a result, `WipeInsertionParent` fails to reframe the `<details>`.  Later on, some logic handling first letter [removes letter frame and calls `GetInsertionPrevSibling`](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7247-7254), tweaking `insertion.mParentFrame` back to the `DetailsFrame`. Hence, it triggers the assertion in `WipeContainingBlock` that asserts `DetailsFrame` should have been reframed.

I think we should call `WipeInsertionParent` before `GetInsertionPrevSibling` because there no point to find the precise insert point if we need to wipe the insertion parent frame, and it also prevents `GetInsertionPrevSibling` from digging into the insertion parent frame that needs to be reframed.
The testcase contains a multicol `<details>` with `details::first-letter` style.  When trying to insert elements into the multicol `<details>`,  we suppose to reframe the `<details>` upon reaching [`WipeInsertionParent.`](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7192) However, early in `ContentRangeInserted`, [GetInsertionPrevSibling](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7144-7145) alters `insertion.mParentFrame`, which becomes a `Letter` frame inside the `DetailsFrame`. As a result, `WipeInsertionParent` fails to reframe the `<details>`.  Later on, some logic handling first letter [removes letter frame and calls `GetInsertionPrevSibling`](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7247-7254), tweaking `insertion.mParentFrame` back to the `DetailsFrame`. Hence, it triggers the assertion in `WipeContainingBlock` that asserts `DetailsFrame` should have been reframed.

I think we should call `WipeInsertionParent` before `GetInsertionPrevSibling` because there's no point to find the precise insert point if we need to wipe the insertion parent frame, and it also prevents `GetInsertionPrevSibling` from digging into the insertion parent frame that needs to be reframed.
The testcase contains a multicol `<details>` with `details::first-letter` style.  When trying to insert elements into the multicol `<details>`,  we suppose to reframe the `<details>` upon reaching [`WipeInsertionParent.`](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7192) However, early in `ContentRangeInserted`, [GetInsertionPrevSibling](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7144-7145) alters `insertion.mParentFrame`, which becomes a `Letter` frame inside the `DetailsFrame`. As a result, `WipeInsertionParent` fails to reframe the `<details>`.  Later on, some logic handling first letter [removes letter frame and calls `GetInsertionPrevSibling`](https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/layout/base/nsCSSFrameConstructor.cpp#7247-7254), tweaking `insertion.mParentFrame` back to the `DetailsFrame`. Hence, it triggers the assertion in `WipeContainingBlock` that asserts `DetailsFrame` should have been reframed.

Back to Bug 1579953 Comment 1