50261 - Nested list items are not functional

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect, P2)

Description

[bijals (gone)]

Steps:
1) Launch Seamonkey
2) Go to following internal URL:
http://blues/users/bijals/publish/shrimp/shrimpcookieproblem.htm
3) Click edit document menu item in File menu

Actual Results: The numbered bullets are not sub bullets of the last regular bullet.

Expected Results: Numbered bullets are sub bullets of last regular bullet

Build Date/Platform: 2000082408 on NT

Comment 1

[rubydoo123]

this is a fundamental issue that is causing this to happen. Each list item has 
Previous summary: "Bullets in Composer created document appear different in 
Seamonkey"

the closing list item marker, the nested list (when select indent). What should 
happen, is when the indent is triggered, the previous list item (parent list 
item) should drop the closing list element marker.

assigning this to jfrancis, setting to P1 and nsbeta3

Comment 2

[Joe Francis]

i can't understand either of you.  :-(

Bij, it sounds like you never actually edit, you just open the doc in the editor 
and things are immediately wrong?  If that's true then it's a parser problem (or 
perhaps a layout problem).

Beth, I can't make hide nor hair out of what you are saying.  Care to try again?

Comment 3

[Joe Francis]

i just looked at this in the mozilla browser, and see the same thing bijal
reports.  This is a parser issue.  I'm not even sure it's a bug.  <ol>'s aren't
supposed to be able to go into <ul>s, so closing the ul sounds legit.  On the
other hand, if it's supposed to be a quirk for compatibilty with 4.x, then
perhaps the ul should not be closed.  harish, I'm handing this over to you -
just close it out if it's not a bug.

Comment 4

[bijals (gone)]

Sorry for the late reply.  Beth is correct that I did not edit the document at
all.  This is a parser issue and possibly a compatibility problem with 4.x
created pages.

Comment 5

[Hixie (not reading bugmail)]

This is a compat issue. The markup goes like this:

   <ul>
     <li></li>
     <ol></ol>
   </ul>

...and we treat is as:

   <ul>
      <li></li>
   </ul>
   <ol></ol>

What we do seems sensible to me. INVALID/WONTFIX? The fix in the document is 
simple -- remove the </li> before the <ol>.

Comment 6

[rickg]

Actually, the document is legal, and we get it wrong. I think this is a must 
fix. Taking it from harishd.

Comment 7

[harishd]

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

Comment 8

[harishd]

"Actually, the document is legal, and we get it wrong"

Rickg, is this based on Ian's comment?  AFAIK, <UL> cannot contain <OL>
and <OL> can have only a block parent ( UL is not ). That would make this 
document illegal. So,the way we handle this document,currently, is correct.

Btw, I agree with Ian in marking this WONTFIX. :-)

Comment 9

[harishd]

Rickg, could you please mark this bug a dup of 45464 and mark it beta3+?
Looks like bug 50261 is not visible outside netscape!  Thanx.

Comment 10

[Phil Peterson]

PDT thinks this is a P2. Changing priority and leaving [PDTP2] in the status
whiteboard

Comment 11

[Hixie (not reading bugmail)]

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

Comment 12

[Hixie (not reading bugmail)]

Making bug visible outside Netscape -- this bug is certainly not a Netscape
Confidential bug.

IMHO this bug could be marked nsbeta3-, WONTFIX or INVALID. This is a compat
issue and we are not doing the wrong thing, we just happen not to do what other
browsers are doing. But Rick says he has a fix, so let's just check it in and 
move on to more important things. :-)

Comment 13

[rickg]

The problem with this is that <UL><li></li><OL> is *extremely* common. I have 
the fix in my tree.

Comment 14

[rickg]

Fixed by changes to element table. This is an EXTREMELY common case. 

Comment 15

[sujay]

verified in 9/12 build.