A block element is (incorrectly ) nested inside an inline element: e.g. <a href=""><h5>text</h5></a>. The text doesn't wrap in the presence of right floated elements In the example URL, scroll down a little and watch the left column, under 'sports'. (testcase coming) Other example url: http://justworldnews.org/ the big fat numbers belong to the right column. Regression: Ok with Camino Version 2006111605 (1.2+) Fails Version 2006111622 (1.2+) Fails in Minefield: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061116 Minefield/3.0a1 ID:2006111612
Attachment #245866 - Attachment mime type: image/jpeg → image/png
I can see this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061117 Minefield/3.0a1 ID:2006111704 [cairo]
Yeah, this looks like bug 354600. It seems that I don't have as good an idea of what space managers do as I thought... In this case, having its own space manager causes the block to ignore floats that are outside it. The problem, of course, is that when the block is initially created it has an inline parent. It's only when we get back into ConstructInline that we backtrack and put it in a different place. I suppose we could keep track of whether we set these flags in this code, either in a member or in more block state flags (I think there are some free ones like 0x10000000 and 0x80000000), and unset the flags as needed when the parent changes, per that XXX comment. Or we could just back out bug 354600, I guess. :( roc, dbaron, thoughts?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Mac OS X 10.3 → All
Hardware: Macintosh → All
Another option is to undo 354600 and instead, replace all checks of the space manager and margin-root flags with wrapper functions that return true when the flag is set OR the parent is not a block.
Hmm.... True. That might work better, though it'll be a bit more expensive. Are any of those checks particularly perf-sensitive?
It happens on most article from www.smh.com.au too Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061118 Minefield/3.0a1 ID:2006111804 [cairo]
(In reply to comment #7) > Hmm.... True. That might work better, though it'll be a bit more expensive. > Are any of those checks particularly perf-sensitive? I don't think so. We can do them just once per nsBlockFrame::Reflow and store the results in the nsBlockReflowState, using that elsewhere.
Fixed by backing out bug 354600. I'll make sure to test that testcase before landing again.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Flags: blocking1.9? → in-testsuite?
Resolution: --- → FIXED
I checked in those tests.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.