Nested list items are not functional

VERIFIED FIXED in M18

Status

()

Core
HTML: Parser
P2
major
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: bijals (gone), Assigned: rickg)

Tracking

({compat})

Trunk
x86
Windows NT
compat
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3+][p:1][PDTP2])

(Reporter)

Description

18 years ago
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

Updated

18 years ago
Assignee: beppe → jfrancis
Severity: normal → major
Keywords: correctness, nsbeta3
Priority: P3 → P1
Summary: Bullets in Composer created document appear different in Seamonkey → Nested list items are not functional
Whiteboard: [nsbeta3+][p:1]
Target Milestone: --- → M18

Comment 1

18 years ago
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

18 years ago
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

18 years ago
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.
Assignee: jfrancis → harishd
Component: Editor → Parser
(Reporter)

Comment 4

18 years ago
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.
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>.
Keywords: correctness → compat
Whiteboard: [nsbeta3+][p:1] → [nsbeta3+][p:1] INVALID/WONTFIX ?
(Assignee)

Comment 6

18 years ago
Actually, the document is legal, and we get it wrong. I think this is a must 
fix. Taking it from harishd.
Assignee: harishd → rickg
Whiteboard: [nsbeta3+][p:1] INVALID/WONTFIX ? → [nsbeta3+][p:1]

Comment 7

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

Comment 8

18 years ago
"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

18 years ago
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

18 years ago
PDT thinks this is a P2. Changing priority and leaving [PDTP2] in the status
whiteboard
Priority: P1 → P2
Whiteboard: [nsbeta3+][p:1] → [nsbeta3+][p:1][PDTP2]
*** Bug 45464 has been marked as a duplicate of this bug. ***
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. :-)
Group: netscapeconfidential?
(Assignee)

Comment 13

18 years ago
The problem with this is that <UL><li></li><OL> is *extremely* common. I have 
the fix in my tree.
Status: NEW → ASSIGNED
(Assignee)

Comment 14

18 years ago
Fixed by changes to element table. This is an EXTREMELY common case. 
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 15

18 years ago
verified in 9/12 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.