From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 ppc; en-US; m15) BuildID: 2000041919 When you have an <H3> tag inside a <LI> tag the text is displayed on the next line eg: <LI><H3>This text should be displayed on the same line as the bullet point but it isn't</H3></LI> Netscape 4.7 displays it correctly on the same machine. The above URL is on my home computer which isn't up all the time so I am attaching the same file below.

Reassigning to buster because it's a block problem

seen also on 2000042208, win98. confirming and removing "(and possibly others)" from summary so it's visible in its entirety from the Bugzilla list...so just keep in mind that this might also be occurring with tags other than <H3>. Also changing OS and Platform to ALL (the former combination of Macintosh and Linux didn't make much sense anyways :)...

not quite...actually I run linux on my G3 powermac so it makes more sense than you would think :). In this case setting it as Linux on macintosh is the closest I can get (which you see from the "ppc" in the User-Agent).

Well, you learn something new every day. Sorry 'bout that :) In any case, it's still on all platforms/OS's

redistributing bugs across future milestones, sorry for the spam

This actually seems to be a major CSS1 compliance issue, because of the way we implement LI that are not within UL. If 'list-style-position' is 'inside' we are supposed to put the list marker inside the first inline box of the box with display list-item. I assume this means that we should not generate an inline box unless there are none - that the inline box may be within a child. (This is the way it works for 'list-style-position:outside'. What's happening here is that we're creating a line-box for just the bullet. Ian: Is everything I said correct?

David: I don't know, CSS2 says "inside: The marker box IS the first inline box in the principal block box, after which the element's content flows." (emphasis mine) -- This could be interpreted both ways?

I know it can be interpreted both ways (create a line box in the 'list-item' block vs. use the first line box that exists). However, one of them (the first) breaks lots of existing pages, so therefore it must be the second. That's my first rule for resolving blatant ambiguities in CSS...

cc eric...

David: Yeah, but the other one means we don't have to change anything, thus we ship sooner... that's my first criteria. ;-) However, our current behaviour has no other advantages. Thus I agree that it is a bug.

No, it means we have to change everything for 'list-style-position: outside'.

Denied beta3: not our most critical problem at this time...

This bug only effects <LI> that are not immediate children of a list <UL> or <OL> for example. So this is not a P1. Downgrading to P2. The author has a straightforward workaround: wrap the proper list type around the list items. Supporting malformed documents isn't a top priority for the next few weeks, and the risk to fix would be moderate, so marking Future.

*** Bug 59863 has been marked as a duplicate of this bug. ***

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that do not have the "testcase" keyword and yet have an attachement with the word "test" in the description field. Apologies for any mistakes.

Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...

Build reassigning Buster's bugs to Marc.

.

There is a description in a CSS 2.0 recommendation: http://www.w3.org/TR/CSS2/generate.html#q11 which tell us that Gecko behaviour is faulty. "Most block-level elements in CSS generate one principal block box. In this section, we discuss two CSS mechanisms that cause an element to generate two boxes: one principal block box (for the element's content) and one separate marker box (for decoration such as a bullet, image, or number). The marker box may be positioned inside or outside the principal box. Unlike :before and :after content, the marker box does not affect the position of the principal box, whatever the positioning scheme."

I ran into this problem today using Firefox 18.0.2 when I discovered that menus (using A tags set to display:block inside LI tags) which worked as I expected in Chrome 24.0.1312.57 did not display the same way in Firefox 18.0.2. After some searching, I found a Stack Overflow question (http://stackoverflow.com/questions/1142314/css-rendering-inconsistency-on-ul-with-firefox-being-the-odd-ball-out) that pointed me to this bug report. I've created a detailed testcase with explanations and sections that are labeled in an effort to clearly demonstrate the behavior described in this bug report. Is this at all helpful? Regarding the whiteboard note "Should double check with CSS WG??", it's a shame we couldn't get Daniel Glazman or someone else to check during the recent CSS WG meeting from Feb 4-6.

I've just run across this same problem developing for a new website. The Stack Overflow question that Ryan Foster showed is exactly the kind of issue I'm having right now. Hasn't it been solved since 2000?

Still not solved...

Still there in 29.0.1. That’s sad.

What is needed to prioritize this issue?

14 and a half years... comment 21 mentioned CSS2, here's (I think) the final wording: http://www.w3.org/TR/CSS2/generate.html#propdef-list-style-position Note the attached image. Firefox doesn't look like this one bit with "list-style-position:inside" when heading-tags are involved. "outside" is fine. Another realworld-example: http://www.cindori.org/trim-enabler-and-yosemite/ Scroll down to "TL;DR?"

Not sure why I've been ni?'d here; this isn't something I've worked on, or particularly know about. Clearing flag. (If there's a specific question for me, ask it; but I don't see one here.)

Echoing comment 28

I think that summary should be something similar to "inside list items containing block elements add new lines". BTW, shouldn’t the product be CSS? The problem can be shown with this sample: <html> <style type="text/css"> ul li { list-style: inside disc; } ul.x li { list-style-position: inside; } ul.y li { list-style-position: inside; list-style-type: disc; } ul.z li { list-style: inside; list-style-type: disc; } ul.a li { list-style: inside; list-style: disc; } ul.b li { list-style-position: inside; list-style: disc; } </style> <body> <ul> <li><p>Not working.</p></li> </ul> <ul class="x"> <li><p>Not working.</p></li> </ul> <ul class="y"> <li><p>Not working.</p></li> </ul> <ul class="z"> <li><p>Not working.</p></li> </ul> <ul class="a"> <li><p>Working.</p></li> </ul> <ul class="b"> <li><p>Working.</p></li> </ul> </body> </html> For some strange reason, when list-style or list-style-position contains the "inside" value, Firefox needs a different list-style attribution with one of the values from list-style-type defined in list-style. These values in list-style-type will not work. Would it be possible to update the product and the summary with a more accurate description, so that this bug could be fixed soon? Many thanks for your help, Pablo

Hi there, this report is almost 15 years old. It has P1 priority. Sorry, I’m not sure whether this is the highest, but nobody is working on it. It is not related to CSS1 only. It is related to CSS2 also (and I guess CSS3 [I haven’t checked it]). Sorry, I cannot code. So I cannot contribute myself a patch (programming code is all Greek to me). I think the bug pattern is clear (see the sample above). Would it be possible that this bug could be fixed before its report turns 15yo? Many thanks for your work and best wishes for 2015!

Just ran into this problem today. It's allmost 15 years since this problem was reported. My mind is boggled on how such a ting can still remain a bug after all these years. Mozilla, this is more important than all your webRTC, HTML5 compliance and Flash replacement stuff. Fix it! It will make headlines when you do!

I ran into this today as well! I would like to take a crack at fixing this bug with the limited open time in my schedule. If someone could please point me in the right direction at least in code then I would greatly appreciate it! Otherwise wish me luck!

We currently construct the bullet in nsBlockFrame::SetInitialChildList (in layout/generic/nsBlockFrame.cpp). In order to fix this, we'd need to end up putting the bullet in an entirely different frame (but only when one is available), but still displaying it as though it were related to the 'display: list-item' frame. Getting the tree construction right requires adding logic to deal with what happens if that child goes away, for example. (It might move to a different child or back to the parent.) It also needs to deal with content being inserted in the parent that means the bullet should now be in a line of the parent. Getting this all right is a decent amount of work, and at risk of causing crashes or even security bugs if it's done wrong. Dealing with styling probably isn't that hard, though, although I might be missing something.

Hey David! Great to talk with you! Sounds like an awesome problem! :) Thanks so much for the code files and help, someone with the kind of experience that you have on this is exactly what I need. I didn't think this was going to be a small project, if it was I would guess that it would have been cleared up earlier than now. That being said I don't think it's something impossible, especially with correct CSS specification behavior in other browsers. That being said I can understand wanting to avoid something that could cause problems, as you mentioned, so if Mozilla wants to leave the behavior of bullets as is, I won't be the one to cause headaches. That being said if the issue remains open, I would like to at least take a stab at a bug fix.

You're welcome to work on it; I'd recommend against doing tons of work without checking in and asking whether your approach so far is good. One other thought about handling the messy dynamic change cases -- one way to handle those, since they're likely rare, is to just conditionally destroy and rebuild more stuff than "needed" (i.e., reconstruct frames for the list-item (and thus for all of its descendants)), because the code to do that is far simpler, and the condition under which it happens is rare. The trick is then just making sure that we don't hit that codepath too often.