Closed
Bug 638937
Opened 12 years ago
Closed 11 years ago
Crash when mixing columns, first-letter & float
Categories
(Core :: Layout: Floats, defect)
Core
Layout: Floats
Tracking
()
RESOLVED
FIXED
mozilla13
People
(Reporter: neil, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: crash, testcase, Whiteboard: [inbound])
Attachments
(4 files, 1 obsolete file)
If you style a first letter with a float style, and the paragraph starts at the bottom of a column, there is no room for the letter, and it "floats" to the next column. However the rest of the paragraph is then displayed in the bottom line! The browser can subsequently abort; I found that altering the column rules was most likely to trigger the abort. ###!!! ASSERTION: aForFrame not found in block, someone lied to us: 'isValid', file nsTextFrameThebes.cpp, line 1175 ###!!! ABORT: comparing iterators over different lists: 'mListLink == aOther.mListLink', file nsLineBox.h, line 722
![]() |
||
Comment 1•12 years ago
|
||
roc, this seems like your sort of thing...
Comment 2•12 years ago
|
||
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → matspal
Severity: major → critical
OS: Windows XP → All
Hardware: x86 → All
Assignee | ||
Comment 3•11 years ago
|
||
(scroll about 60% down to see the interesting frames) We're trying to build a text run for the text frame "N" (red) which is the child frame of a float first-letter. nsFirstLetterFrame::CanContinueTextRun() returns 'true' so FindLineContainer() walks up the ancestor to 0x7fffdcf083b8 (green), which isn't the line container for the text frame. This should be easily fixed by returning 'false' in CanContinueTextRun() for a floating first-letter. Still, there's something odd about the frame tree -- why has the float been pushed into a different block from the text is supposed to be the first letter for? (namely 0x7fffdcd08f68 (yellow)) That seems wrong, but maybe we're not done reflowing yet?
Assignee | ||
Comment 4•11 years ago
|
||
Try results pending: https://tbpl.mozilla.org/?tree=Try&rev=6f52d96cba0f
Assignee | ||
Comment 5•11 years ago
|
||
Hmm, it appears text-transform:capitalize assumes that the start of a text run is also the start of a word? https://tbpl.mozilla.org/?tree=Try&rev=6f52d96cba0f (Reftest layout/reftests/bugs/431341-1.html)
Assignee | ||
Comment 6•11 years ago
|
||
Looking at the text-run / line-breaker code it looks hard to get things right when a word is broken into two text-runs. I'll see if I can make BuildTextRuns deal instead.
Assignee | ||
Comment 7•11 years ago
|
||
For floating first-letter text, I think the correct line-container to use for the line iterators here is the parent of the placeholder frame. We've just assumed that the floating first-letter parent is the same as the placeholder parent. I think that's actually a bug when it's not, but let's fix this crash first and then file a second bug on that. The last two hunks fixes compile warnings - an unused variable and a signed/unsigned int comparison. The assert(18) are all "Computed overflow area must contain frame bounds" due to the "margin: -562949953421311em;" in the test causing nscoord overflows. I'm not worried about that.
Attachment #598372 -
Attachment is obsolete: true
Attachment #598531 -
Flags: review?(roc)
Assignee | ||
Comment 8•11 years ago
|
||
The Try run: https://tbpl.mozilla.org/?tree=Try&rev=78f2975c3fa5
Attachment #598531 -
Flags: review?(roc) → review+
Assignee | ||
Comment 9•11 years ago
|
||
Filed bug 729352 to follow-up on the misplaced float first-letter frame.
Assignee | ||
Comment 10•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/0edd2447ab9b
Flags: in-testsuite+
Whiteboard: [inbound]
Target Milestone: --- → mozilla13
Comment 11•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0edd2447ab9b
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•