Closed Bug 26347 Opened 25 years ago Closed 24 years ago

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

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
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)

Test Case for B and A tags.
324 bytes, text/html
Details
Testcase for phrase and style tags
290 bytes, text/html
Details
testcase to demonstrate problem
512 bytes, text/html
Details
Testcase from bug 68674
2.30 KB, text/html
Details
patch v1.1 [ fix testcase 4 ]
827 bytes, patch
Details | Diff | Splinter Review
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
Keywords: mozilla0.9, mozilla0.9.1
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: nsbeta1 → nsbeta1-
sr=jst
Fix is in. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 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

Creator:
Created:
Updated:
Size: