diff options
| author | bors-servo <lbergstrom+bors@mozilla.com> | 2019-12-09 08:23:10 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-12-09 08:23:10 -0500 |
| commit | e8d677ad264876838d297bd6843d0b02cc488dd9 (patch) | |
| tree | d0ff07cc61336adf6f24bdcf509e42d48760f089 /python | |
| parent | 013bb662cb663b2e7d252a7d47595eb279bd1eea (diff) | |
| parent | 6dad51f57032cbf8410fa38a60a5315fd0fc7da9 (diff) | |
| download | servo-e8d677ad264876838d297bd6843d0b02cc488dd9.tar.gz servo-e8d677ad264876838d297bd6843d0b02cc488dd9.zip | |
Auto merge of #25158 - jdm:wr-spatial-panic, r=SimonSapin
Fix "Tried to use SpatialId before it was defined" layout panic
In the case where an element uses `text-overflow: ellipsis` and causes overflow, we create a TruncatedFragment that wraps the original overflowing fragment. When collecting stacking contexts for the truncated fragment, https://github.com/servo/servo/pull/18510 addressed the case where the wrapped fragment wouldn't be processed, but neglected the case where that fragment ends up creating a new stacking context. When that happens, the TruncatedFragment would be stuck with the updated scrolling/clipping information based on the new stacking context, but it would be a child of the parent stacking context. Since the new scrolling/clipping nodes do not exist in the display list until the new stacking context display item is created, this led to the observed panic.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix #24895 and fix #19281 and fix #22826.
- [x] There are tests for these changes
Diffstat (limited to 'python')
0 files changed, 0 insertions, 0 deletions