Closed Bug 26347 Opened 25 years ago Closed 23 years ago

Some tags lead to incorrect parsing. <b>..<i>..</b>..</i>

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: biswapesh_chatterjee, Assigned: harishd)

References

Details

(Keywords: compat, Whiteboard: [fix in hand] {RS} -- This happens on approx 20% of top 100.)

Attachments

(5 files)

System: Checked on M13, latest builds on Linux, WinNT
Overview: If an unknown tag is present inside another tag, even if the tag is 
closed later, the parser is unable to detect it.
Test Case: Open the attached document.
Expected result: The second para should not be bold. The text after the link 
should not show as a link.
Actual result: The reverse.
Other into: Works fine in NS4.x, IE
I have a feeling that this is a specific case of a more generic problem of 
nested tags. Basically, lines like these:
<X>blah blah<Y>blah blah</X> (where X and Y are any tags)
seem to confuse the parser in quite a few cases. I am builing a more complete 
set of test cases showing as many of the scenarios as possible. I think this 
needs some attention ASAP.
Seems legit.
Status: NEW → ASSIGNED
Target Milestone: M15
Reduced test case:
<B>Bold <unknown> tag</B> not bold.
This has nothing to do with unknown tags. It's the other part of residual style 
that has not yet been resolved. The malformed case <A>...<B>...</A>...</B> in 
general needs to be handled. The plan is to buffer the content until we hit the 
matching end tag (for inlines). We'll respond differently if the model is well 
formed or not.
Whiteboard: {RS}
*** Bug 28562 has been marked as a duplicate of this bug. ***
In the bug marked duplicate, the case was for mismatched phrase and style tags.
A combination like <STRONG><I>...</STRONG></I> will work, but
<I><STRONG>...</I></STRONG> won't.  Moving the testcase over.
Moving to m16
Target Milestone: M15 → M16
*** Bug 30293 has been marked as a duplicate of this bug. ***
M16 has been out for a while now, these bugs target milestones need to be 
updated.
Moving to my list since Rickg is on sabbatical.
Assignee: rickg → harishd
Status: ASSIGNED → NEW
Changed summary to reflect the actual behavior.

Nominating for nsbeta3.  This is certainly a compatibility issue.
Status: NEW → ASSIGNED
Keywords: nsbeta3
Summary: Unknown tags lead to incorrect parsing. → Sme tags lead to incorrect parsing.
Whiteboard: {RS} → {RS},Compatibility
Keywords: compat
Whiteboard: {RS},Compatibility → {RS}
Target Milestone: M16 → M18
Okay, I'm inclined to mark this bug FUTURE.  Please let me know your concerns.  
Thanx.
Keywords: nsbeta3
Target Milestone: M18 → Future
Harish: Why Future?

QA: We need to find how many sites are affected by this.
Keywords: qawanted
Summary: Sme tags lead to incorrect parsing. → Some tags lead to incorrect parsing. <b>..<i>..</b>..</i>
Whiteboard: {RS} → {RS} -- We need to find how many sites have this problem
Ian, the problem is in finding those sites ( I appreciate your concern though ).
If you can point me to any of the top 100 sites, with this problem, then I'll be 
glad to nominate the bug for beta3.
Taking this back. It's not just that it's a compatibility problem, it's that it 
can break the dom. This is a priority fix. 
Assignee: harishd → rickg
Status: ASSIGNED → NEW
Target Milestone: Future → M18
Marking nsbeta3; this is the most important bug I have to fix.
Status: NEW → ASSIGNED
Keywords: nsbeta3
Whiteboard: {RS} -- We need to find how many sites have this problem → nsbeta3 {RS} -- This happens on approx 20% of top 100.
*** Bug 51113 has been marked as a duplicate of this bug. ***
marking for nsbeta3+, since it's a prolific problem with a fix in hand.
Whiteboard: nsbeta3 {RS} -- This happens on approx 20% of top 100. → [nsbeta3+] {RS} -- This happens on approx 20% of top 100.
*** Bug 50710 has been marked as a duplicate of this bug. ***
Fix landed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Priority: P3 → P2
Resolution: --- → FIXED
Verified fixed on Build 2000091508 on WinNT4 SP6
Status: RESOLVED → VERIFIED
Testing on the following builds:

Win: 09_28_09_mn6
Mac: 09_29_11_mn6
Linux: 09_29_09_mn6

Attached is a testcase with 12 examples: mismatched 'bold' and 'anchor' tags in 
a paragraph and mismatched 'bold' and 'anchor' tags in a table cell. Problem is 
still evident in the table cell example. 

Also, using the previous testcase (2/22) provided, I don't see where all the 
examples are fixed. 

Reopening bug.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** Bug 54427 has been marked as a duplicate of this bug. ***
*** Bug 55000 has been marked as a duplicate of this bug. ***
Based on Rick's comments and the fact that this was nsbeta3+ previously, 
nominate for rtm.
Keywords: rtm
marking future
Status: REOPENED → ASSIGNED
Keywords: rtm
Whiteboard: [nsbeta3+] {RS} -- This happens on approx 20% of top 100. → {RS} -- This happens on approx 20% of top 100.
Target Milestone: M18 → Future
*** Bug 61836 has been marked as a duplicate of this bug. ***
Bug 60806 is related with additional problems (<PRE> after <B><I></B>).
*** Bug 63932 has been marked as a duplicate of this bug. ***
Blocks: 60806
*** Bug 68674 has been marked as a duplicate of this bug. ***
updated qa contact.
QA Contact: janc → bsharma
*** Bug 67765 has been marked as a duplicate of this bug. ***
10% of top 100? Oh dear... rickg: any chance of de-futuring this?

The testcase from bug 68674 shows exactly where the problem still lies. Are all 
the problematic tags in some group which is treated differently? 

Gerv
Cc Harish; not sure why this is still assigned to Rick, and if it's a mostfreq
and occurs in 10% of top 100 pages someone ought to at least look at it to see
if it might be easily fixable.
Keywords: nsCatFood
what needs to happen to get this bug moving again. is there someone else that
can look into it.  cc:'ing brendan 
Re-assigning bug to Harish and tentatively setting the target milestone to 0.9.1 
because this bug is a "mostfreq".
Assignee: rickg → harishd
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla0.9.1
Testcase 1 ( id=4861 ) and testcase 3 ( id=16010 ) work for me. Testcase 2 ( 
id=5592 ) and Testcase 4 ( id=25517 ) are partially correct. The tags that seem 
to be problematic are ABBR,STRONG,CODE,VAR,CITE,KBD,SAMP,DFN. I doubt that 20% 
of the top 100 sites are using these tags ( I may be wrong ).
Status: NEW → ASSIGNED
Testcase 2 boils down to

<html>
 <body>
  <b></i>Should this be bold?
 </body>
</html>

IE & N6 exhibit the same behavior.
data:text/html,<html><body><b></z>this is bold in nc4</body></html>
data:text/html,<html><body><b></i>this not bold in nc4</body></html>
neat stuff..
Whiteboard: {RS} -- This happens on approx 20% of top 100. → [fix in hand] {RS} -- This happens on approx 20% of top 100.
heikki says r=heikki
Keywords: nsbeta1nsbeta1-
sr=jst
Fix is in. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
Verified on
build: 2001-05-29-20-Trunk
platform: Win NT

The results are as expected.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: