Last Comment Bug 25888 - inlines wrapping around floats only check top pixel of line for overlap (negative top margins or multiple floats)
: inlines wrapping around floats only check top pixel of line for overlap (nega...
Status: RESOLVED FIXED
[Hixie-P3][CSS1-5.5.25][CSS1-5.5.1] i...
: css1, testcase
Product: Core
Classification: Components
Component: Layout: Floats (show other bugs)
: Trunk
: All All
: P3 normal with 23 votes (vote)
: ---
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
:
Mentors:
http://en.wikipedia.org/wiki/Hurrican...
: 49067 117400 198800 222739 279466 300193 384376 386032 397167 408757 425754 (view as bug list)
Depends on: 191448 494089 494237 494332 494503 495451 496293
Blocks: float 93592 437920 css2.1-tests 41412 222739 271371 363307 428810 478834 500736 538194 641947
  Show dependency treegraph
 
Reported: 2000-01-31 09:10 PST by Daniel Lichtenberger
Modified: 2015-09-06 13:32 PDT (History)
46 users (show)
roc: blocking1.9-
dbaron: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
simple testcase showing the incorrect wrapping of the text (694 bytes, text/html)
2000-03-08 15:54 PST, Marc Attinasi
no flags Details
Test case - the text should not overlap the blue box (980 bytes, text/html)
2001-01-10 19:54 PST, Hixie (not reading bugmail)
no flags Details
testcase (12.86 KB, text/html)
2007-12-18 16:13 PST, Stellan Klebom
no flags Details
test-case showing several related problems (3.31 KB, text/html)
2008-06-22 16:00 PDT, Nick
no flags Details
patch 1: extend nsFloatManager to provide needed information (8.56 KB, patch)
2009-01-06 13:31 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
pre-patch 1: remove aState.IsImpactedByFloat() check in PrepareResizeReflow (1.21 KB, patch)
2009-01-06 13:32 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Review
patch 3: fix this bug for inlines wrapping around floats (18.82 KB, patch)
2009-01-06 13:33 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
patch 4: fix this bug for blocks wrapping around floats (19.66 KB, patch)
2009-01-06 13:34 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
stack explaining reason for hang (2.05 KB, text/plain)
2009-02-12 16:58 PST, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details
series of preparatory patches implementing comment 42 (95.75 KB, patch)
2009-03-09 17:29 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
series of preparatory patches implementing comment 42 (136.17 KB, patch)
2009-04-06 16:01 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
no flags Details | Diff | Review
series of preparatory patches implementing comment 42 (134.55 KB, patch)
2009-04-06 18:33 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Review
patch 1: extend nsFloatManager to provide needed information (8.85 KB, patch)
2009-05-14 10:44 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Review
patch 3: fix this bug for inlines wrapping around floats (37.20 KB, patch)
2009-05-14 10:48 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Review
pre-patch: remove InitFloat (6.45 KB, patch)
2009-05-18 10:21 PDT, David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
roc: review+
roc: superreview+
Details | Diff | Review

Description Daniel Lichtenberger 2000-01-31 09:10:53 PST
Look at the submitted page, it contains a table (containing an image) aligned to
the left, and to the right a text paragraph with a negative margin-top (in this
case, of 7px). The first line of the text paragraph overlaps with the table,
making the text unreadable (I'm using the default 96 dpi setting). This HTML
code works ok with both Internet Explorer and Netscape Communicator, and
according to w3c.org, negative margins are allowed.
You might also want to take a look at the pre- and reviews at
http://www.topofgames.de, this problem occurs in all articles.
Comment 1 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2000-02-12 08:37:15 PST
Right now the testcase in the URL field is not available (the document is
empty).

However, negative margins are allowed so that authors may suggest overlap.  It's
not a bug if they cause it, it's a feature.  There could be something wrong in
this case, but since I can't see the testcase and I don't see the problem on the
site mentioned, I can't tell.
Comment 2 Daniel Lichtenberger 2000-02-13 09:24:53 PST
I'm sorry, it seems the webserver was down yesterday. It should work now again.
Comment 3 Marc Attinasi 2000-03-07 14:04:01 PST
Taking over 1/3 of Pierre's NEW bugs to help reduce his doomage factor
Comment 4 Pierre Saslawsky 2000-03-07 14:36:35 PST
Reassigned back to me these bugs that shouldn't have left my list.
Comment 5 Marc Attinasi 2000-03-08 15:52:29 PST
It looks like there may be a layout bug here. The margin is not merely moving up 
by 7 pixels as the style rules says it should, it is also moving left by the 
width of the table.

Buster says this looks like a floater layout bug so I'll forward to him and then 
attach a simple testcase... 
Comment 6 Marc Attinasi 2000-03-08 15:54:49 PST
Created attachment 6301 [details]
simple testcase showing the incorrect wrapping of the text
Comment 7 buster 2000-03-13 16:17:09 PST
floaters in M15
Comment 8 rickg 2000-04-07 16:41:19 PDT
moving all buster m15 bugs to m16.
Comment 9 buster 2000-04-17 15:46:49 PDT
post-beta issue
Comment 10 buster 2000-06-01 14:21:09 PDT
redistributing bugs across future milestones, sorry for the spam
Comment 11 buster 2000-06-12 18:15:07 PDT
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 
Comment 12 Jesse Ruderman 2000-08-17 00:22:34 PDT
*** Bug 49067 has been marked as a duplicate of this bug. ***
Comment 13 Hixie (not reading bugmail) 2000-08-25 13:46:58 PDT
We need to examine this to work out exactly what is causing it and whether it
is wrong or not.
Comment 14 Hixie (not reading bugmail) 2001-01-10 19:53:33 PST
Yeah, this is a valid bug (simplified attachement coming up). Line boxes should
never overlap floats that are in their formatting context; in this case we are
seeing an element moved up using negative margins so that it's line boxes begin
higher than a float earlier in the flow, but we are not making the first line 
box wrap around the float.
Comment 15 Hixie (not reading bugmail) 2001-01-10 19:54:27 PST
Created attachment 22328 [details]
Test case - the text should not overlap the blue box
Comment 16 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2001-09-17 13:58:52 PDT
I think this has the same cause as bug 41412 -- see my 2001-09-17 13:56
comment on bug 86947.
Comment 17 Kevin McCluskey (gone) 2001-10-04 16:33:58 PDT
Build reassigning Buster's bugs to Marc.
Comment 18 Madhur Bhatia 2002-03-15 17:43:49 PST
any progress with this bug ?
Comment 19 Greg K. 2002-07-11 00:24:56 PDT
Confirmed using FizzillaCFM/2002070913. Setting All/All.
Comment 20 Christopher Hoess (gone) 2003-06-07 17:46:38 PDT
->Layout: Floats
Comment 21 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-06-08 11:53:34 PDT
Comment on attachment 22328 [details]
Test case - the text should not overlap the blue box

This testcase doesn't show the bug anymore, but the original one does.
Comment 22 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-06-08 11:54:28 PDT
*** Bug 198800 has been marked as a duplicate of this bug. ***
Comment 23 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-06-08 11:55:14 PDT
*** Bug 117400 has been marked as a duplicate of this bug. ***
Comment 24 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-10-17 22:23:43 PDT
*** Bug 222739 has been marked as a duplicate of this bug. ***
Comment 25 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-07-09 10:05:04 PDT
*** Bug 300193 has been marked as a duplicate of this bug. ***
Comment 27 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-02-13 18:28:44 PST
I just checked in a bunch of reftests for this.
Comment 28 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-02-13 18:40:35 PST
Given an easier-to-work-with space manager (or a replacement for it), this would be pretty simple to fix.  We'd just need to do the following:

* store a line available space height on the stack (maybe in nsBlockReflowState), and initialize it to zero in nsBlockFrame::ReflowInlineFrames inside the loop over bands (but outside the loop over no-pull redos).

* at the end of nsBlockFrame::DoReflowInlineFrames, check that the height the line got doesn't run into another band that's narrower than the band at its top.  (Note that we have to check all bands, not just the bottom one.)  If so, return LINE_REFLOW_REDO_NO_PULL and initialize the line available space height to the height of the line (after asserting that it's currently zero, maybe, although I'm not sure how this interacts with the other uses of NO_PULL).

* at the beginning of nsBlockFrame::DoReflowInlineFrames, initialize the available space rect based on the line available space height.

We'd need to check the interaction with the other causes of NO_PULL redoes, though.  The idea is that the line available space height would be zero for the first try of a line at a position and potentially increase (once) to a larger amount, but would never decrease until we move to the next band.
Comment 29 Ray Kiddy 2007-03-05 12:22:08 PST
Note that it appears that automated tests are in for this bug:

layout/reftests/bugs/25888-1l-notref.html
layout/reftests/bugs/25888-1l-ref.html
layout/reftests/bugs/25888-1l.html
layout/reftests/bugs/25888-1r-notref.html
layout/reftests/bugs/25888-1r-ref.html
layout/reftests/bugs/25888-1r.html
layout/reftests/bugs/25888-2l-ref.html
layout/reftests/bugs/25888-2l.html
layout/reftests/bugs/25888-2r-ref.html
layout/reftests/bugs/25888-2r.html
layout/reftests/bugs/25888-3l-ref.html
layout/reftests/bugs/25888-3l.html
layout/reftests/bugs/25888-3r-ref.html
layout/reftests/bugs/25888-3r.html

Right now, we have no tag to state whether a test is automated. The in-testsuite flag does not speak to this.
Comment 30 Eli Friedman 2007-05-26 21:05:20 PDT
I can't tell if any of the testcases cover the following situation, so I thought I'd throw it out:
<div style="width: 200px; font-size: 0">
<div style="float:left; height: 10px; width: 50px"></div>
<div style="float:left; clear: left; height: 10px; width: 100px"></div>
<span style="display: inline-block; width: 10px; height:5px;"></span>
<span style="display: inline-block; width: 100px; height:15px;"></span>
</div>

Here, the second inline-block only fits below both floats; the issue here, though, is making sure that the first span is next to the first float, not the second.
Comment 31 Adam Guthrie 2007-06-13 22:34:48 PDT
*** Bug 384376 has been marked as a duplicate of this bug. ***
Comment 32 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-09-22 10:58:11 PDT
*** Bug 397167 has been marked as a duplicate of this bug. ***
Comment 33 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2007-12-18 15:16:45 PST
*** Bug 408757 has been marked as a duplicate of this bug. ***
Comment 34 Stellan Klebom 2007-12-18 16:13:49 PST
Created attachment 293771 [details]
testcase


Another testcase can be found at http://klebom.se/stellan/css/textboxclearing/
Comment 35 Nick 2008-06-22 16:00:16 PDT
Created attachment 326213 [details]
test-case showing several related problems

See description at end of attachment.

Illustrates incorrect wrapping of lists and paragraphs around floated blocks.

Shows different possibilities when you hover on different parts, as per instructions.
Comment 36 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2008-12-07 13:20:01 PST
*** Bug 386032 has been marked as a duplicate of this bug. ***
Comment 37 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-01-06 13:31:52 PST
Created attachment 355639 [details] [diff] [review]
patch 1: extend nsFloatManager to provide needed information
Comment 38 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-01-06 13:32:45 PST
Created attachment 355640 [details] [diff] [review]
pre-patch 1: remove aState.IsImpactedByFloat() check in PrepareResizeReflow

I don't think this check should be needed anymore.  But if it is, it needs to be extended.
Comment 39 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-01-06 13:33:23 PST
Created attachment 355641 [details] [diff] [review]
patch 3: fix this bug for inlines wrapping around floats

Full reftests pass with patches 1-3.
Comment 40 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-01-06 13:34:04 PST
Created attachment 355642 [details] [diff] [review]
patch 4: fix this bug for blocks wrapping around floats

Full reftests pass with patches 1-4, but I'm still not happy with this patch (see comments within).
Comment 41 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-01-06 13:34:25 PST
A patch 5 is still needed to fix list item markers/bullets.
Comment 42 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-02-12 16:58:21 PST
Created attachment 362152 [details]
stack explaining reason for hang

So (with the updated patches in my patch queue at http://hg.mozilla.org/users/dbaron_mozilla.com/patches/ ) I'm seeing a hang loading http://www.flightaware.com/ and I wrote what I think is in an equivalent testcase at 25888-2.html in the crashtests in the patches.

This stack explains why it's a problem:  it shows where my assumptions about mAvailSpaceRect not being updated during reflow are being violated.

I think the way to move forward here (which would also fix the issues that I have comments about regarding when mAvailSpaceRect is valid) is to pull mAvailSpaceRect out of nsBlockReflowState.  Instead, we should hold one avail space rect in nsBlockFrame::ReflowInlineFrames, one in nsBlockReflowState::FlowAndPlaceFloat, and one (or more) for bullet reflow (which might be a little more complicated, but could also be a little less efficient).  This would likely solve the "when is mAvailSpaceRect" valid, and also fix this hang (infinite loop in ReflowInlineFrames), which results from the things I'm trying to do with mAvailSpaceRect in PlaceLine/DoReflowInlineFrames/ReflowInlineFrames invalid.
Comment 43 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-02-21 14:01:57 PST
I've made a good bit of progress on the above in my patch queue.  However, I explicitly stopped dealing with floats inside the line, which means I'm no longer fixing the case in bug 345369.  I need to figure out how to deal with that.
Comment 44 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-02-24 13:15:48 PST
So I locally reverted the change that I'd made that I expected made this not fix bug 345369 anymore.  Reverting it actually doesn't fix that bug... I haven't investigated that problem yet.

But it does reintroduce an infinite loop (broken by the spins == 1000 test) on layout/base/crashtests/266360-1.html .  And that points to a bigger problem, which is that our use of aAvailableWidth in nsBlockReflowState::AddFloat presumes this bug.  We actually do need to place floats there if they push below part of the line, but not all of it, since when we redo lines for "more floats", some of those additional floats could actually be in the line, and we don't want to skip placing them in the redo pass.  For example, given:

  <!-- narrow float above that intrudes only a few pixels into div below -->
  <div>
    <div id="B" style="float:left;clear:left;width:99%"></div>
    hello
  </div>

we should determine on the first pass that hello intersects the "B" div and that we need to reflow again, but on the second pass we still need to place the "B" div.

And if "B" is after "hello", it's even messier, since we then need to push "hello" on the second pass, which in turn pushes the float, which means we need a third pass to actually place "hello", but for that third pass we need to remember that we have to push the float that we pushed on the second pass below the line even though it looks like there was room for it.

So there's actually some messy interaction with bug 50630 here that I hadn't observed before.
Comment 45 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-03-09 17:22:56 PDT
Comment on attachment 355640 [details] [diff] [review]
pre-patch 1: remove aState.IsImpactedByFloat() check in PrepareResizeReflow

Removing this check should make the rest of this bug a good bit easier, and I think it's valid.  I may as well get this part out of my tree (and land it separately from the rest to allow separating regressions).
Comment 46 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-03-09 17:29:51 PDT
Created attachment 366439 [details] [diff] [review]
series of preparatory patches implementing comment 42

Here's a series of preparatory patches for this bug that I think I'd rather get out of my tree sooner rather than later.  This is in the format of the output of "hg out -p", but it's really a rather long sequence of patches that I'd rather keep separate (but I don't see a strong need to upload 8 separate attachments to bugzilla).

The point of these patches is described primarily in comment 42.  We already have a bit of existing confusion about when mAvailSpaceRect and mBandHasFloats are valid.  Since the patches for this bug will make their meaning more complicated (i.e., it relates to a good bit more current state than just a single vertical coordinate), this series of patches just moves mAvailSpaceRect out of nsBlockReflowState.  There's one patch to start things off, then one patch for each of the areas of code in which we track available space, and then one patch to remove the old bits of nsBlockReflowState.

Most of the patches are relatively straightforward, but the bullet one is not.  It also rewrites the hacky fix to bug 427370 in a better way that simultaneously fixes bug 428810.  The new fix involves the ability to compute available space using a saved space manager state, which is what we want in this case.  (I think this ability will also turn out useful for other patches in this bug, although I'm not entirely sure; see comment 44.)
Comment 47 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-03-11 10:16:00 PDT
Landed pre-patch 1: http://hg.mozilla.org/mozilla-central/rev/98d7db017563
Comment 48 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-03-11 15:32:55 PDT
+        aResult->mTop = kidPosition.mTop + offset;
+        aResult->mBaseline = kidPosition.mBaseline + offset;
+        aResult->mBottom = kidPosition.mBottom + offset;

Worth declaring an operator+ on LinePosition? Or a method "LinePosition MoveBy(nscoord)"? There are two or three places you could use it.

+    // Note: mAvailSpaceRect.x is relative to the content box and never

You mean floatAvailSpace.x?

 nsBlockReflowState::ComputeBlockAvailSpace(nsIFrame* aFrame,
                                            const nsStyleDisplay* aDisplay,
+                                           PRBool aBandHasFloats,
+                                           const nsRect& aFloatAvailableSpace,
                                            PRBool aBlockAvoidsFloats,
                                            nsRect& aResult)

As soon as we have more than one boolean parameter I reckon we should define a flags word. It's a little more efficient and much easier to read.

Do you think it might be worth defining a struct that contains an nsRect and a boolean to indicate whether there are any floats in the band, that GeGetFloatAvailableSpace and friends can return directly, and that we can pass around references to?
Comment 49 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-04-06 15:58:09 PDT
(In reply to comment #48)
> Do you think it might be worth defining a struct that contains an nsRect and a
> boolean to indicate whether there are any floats in the band, that
> GeGetFloatAvailableSpace and friends can return directly, and that we can pass
> around references to?

Yeah... I'd sort of been thinking that for a while.  So I went ahead and did it, but as a patch that applies on top of the other patches in the series.  (And thus I ignored the comment immediately before the one quoted, since that function now takes the new struct rather than having an additional boolean.)
Comment 50 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-04-06 16:01:51 PDT
Created attachment 371326 [details] [diff] [review]
series of preparatory patches implementing comment 42

This fixes the issues in comment 48 (except the ComputeBlockAvailSpace one, since that's no longer needed due to the change addressing the last comment).
Comment 51 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-04-06 18:33:42 PDT
Created attachment 371363 [details] [diff] [review]
series of preparatory patches implementing comment 42

A few things that I'd changed in the previous patch can still be just nsRect, actually.
Comment 52 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-04-07 20:24:00 PDT
Comment on attachment 371363 [details] [diff] [review]
series of preparatory patches implementing comment 42

+    LinePosition operator+(nscoord aOffset) {

Make it const
Comment 54 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-05-13 13:41:36 PDT
(In reply to comment #43)
> I've made a good bit of progress on the above in my patch queue.  However, I
> explicitly stopped dealing with floats inside the line, which means I'm no
> longer fixing the case in bug 345369.  I need to figure out how to deal with
> that.

(In reply to comment #44)
> So I locally reverted the change that I'd made that I expected made this not
> fix bug 345369 anymore.  Reverting it actually doesn't fix that bug... I
> haven't investigated that problem yet.

I've been thinking that maybe I could un-revert that change, but then make certain types of line-redo get the available width for the call to AddFloat from a band rather than a position.  Or maybe it's more that I need to rethink the interaction between the different types of line-redo operations, e.g., by preserving the REDO_NO_PULL state (forceBreakInContent, etc.) when we get a REDO_MORE_FLOATS.
Comment 55 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-05-14 10:44:12 PDT
Created attachment 377448 [details] [diff] [review]
patch 1: extend nsFloatManager to provide needed information
Comment 56 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-05-14 10:48:43 PDT
Created attachment 377450 [details] [diff] [review]
patch 3: fix this bug for inlines wrapping around floats

This leaves a bunch of issues I was hoping to fix still unfixed, but does fix the most common cases.  I'd like to get this in soon and then come back to the other parts later.

(It leaves unfixed a bunch of issues dealing with a line wrapping around floats that are in the line itself.  Right now nsLineLayout::UpdateBand and its caller only handle those cases when such floats intersect the top of the line.  Getting all these issues really right would probably be easiest if we deferred float placement until we hit a break opportunity (unless we're already at one) and if we did vertical alignment and line height calculations as we reflowed the line rather than in a separate pass at the end.)
Comment 57 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2009-05-18 03:20:52 PDT
Comment on attachment 377450 [details] [diff] [review]
patch 3: fix this bug for inlines wrapping around floats

This seems OK.
Comment 58 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-05-18 10:21:39 PDT
Created attachment 378076 [details] [diff] [review]
pre-patch: remove InitFloat

I had another (more recent) preparatory patch lying around:  I don't see any need to have similar methods InitFloat and AddFloat.
Comment 60 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2009-08-10 20:18:39 PDT
Bug 179596 comment 26 has some thoughts relevant to fixing this for horizontal positioning of bullets (intended to be patch 5 in the series above, but which I've never started on).
Comment 61 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-01-07 05:57:52 PST
I landed the tests from patch 4 in
http://hg.mozilla.org/mozilla-central/rev/ec3bca6461a5
Comment 62 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2015-07-29 16:04:31 PDT
I'm going to move the work of patch 4 to bug 538194 and patch 5 to bug 416732.

This bugs summary has always covered just what was already fixed by patches 1 through 3.  Thus I'm going to mark it as fixed, which it really has been for years.  (In milestone 1.9.2a1.)
Comment 63 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2015-08-06 22:16:56 PDT
*** Bug 279466 has been marked as a duplicate of this bug. ***
Comment 64 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2015-08-06 22:23:06 PDT
*** Bug 425754 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.