Mozilla not showing URL in right way

RESOLVED WORKSFORME

Status

()

Core
HTML: Parser
P3
normal
RESOLVED WORKSFORME
17 years ago
15 years ago

People

(Reporter: anubis, Assigned: harishd)

Tracking

({compat, testcase})

Trunk
Future
compat, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Fix in hand, URL)

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001111
BuildID:    200011121

All Netscape versions, all Internet Explorer versions are showing
http://www.BanjaLuka.NET but Mozilla fails...


Reproducible: Always
Steps to Reproduce:
go to http://www.banjaluka.net and see tables are broken


Actual Results:  broken tables


Expected Results:  corect result

Comment 1

17 years ago
Confirming for Build 2000111108 under Win98.

Comment 2

17 years ago
Also seeing this on win2000.

I haven't tested extensively, but I'm not really surprised this page doesn't 
render correctly in Mozilla, considering the rather large amount of incorrect 
HTML code. 
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.banjaluka.net shows a LOT of 
problems with tables.

Comment 3

17 years ago
Created attachment 19142 [details]
Testcase

Comment 4

17 years ago
Reassigning to Parser based on testcase:

<TABLE BORDER=1>
<TR>
    <TD>r1c1 <!-- missing TD end-tag here -->
</TR>        <!-- extra TR end-tag here -->
    <TD>r1c2</TD>
    <TD>r1c3</TD>
</TR>
</TABLE>
Assignee: karnaze → harishd
Severity: blocker → normal
Status: UNCONFIRMED → NEW
Component: HTMLTables → Parser
Ever confirmed: true
Keywords: 4xp, testcase
QA Contact: chrisd → janc
(Assignee)

Comment 5

17 years ago
Created attachment 20489 [details] [diff] [review]
Proposed patch v1.1
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Whiteboard: Fix in hand
(Assignee)

Updated

17 years ago
Target Milestone: --- → mozilla0.9
Indentation looks weird, please check that. r=heikki.

Comment 7

17 years ago
I'm concerned about the scope of this fix - the new code path applies to more
than this specific case. I'm not convinced that the new logic will correctly
handle other similar cases - is the TR case described here the exception or the
rule?

I'll defer to Harish in determining the safety of this checkin (he has run the
parser regression tests and some number of the top 100). However, without seeing
a large number of DUPs for this bug, I do question the importance of fixing this
single edge case.
So if we don't fix this now, we could move this to future but leave the Fix in
hand in the status whiteboard (also add patch keyword) and see if we get
duplicates. Looking at the bug number this was also found relatively late...
(Assignee)

Comment 9

17 years ago
I agree with Vidur, in holding off my checkin, until it's proved that a lot many 
pages are affected by this problem. For now marking LATER.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
(Assignee)

Comment 10

17 years ago
or rather FUTURE.
Status: RESOLVED → REOPENED
(Assignee)

Comment 11

17 years ago
Setting to FUTURE.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9 → Future
Keywords: patch
And adding the patch keyword...

Comment 13

17 years ago
updated qa contact.
QA Contact: janc → bsharma
The URL looks fine now.  Given that nothing's been duped into this, maybe this
should be WONTFIXED.

Updated

16 years ago
QA Contact: bsharma → moied
Keywords: compat

Comment 15

16 years ago
that site is using nuke of some kind.
tables seem ok for me. WFM 2002052306 win2k

Comment 16

15 years ago
HONK!
WFM, then.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.