extra ">" added to unclosed tags.

RESOLVED DUPLICATE of bug 70918

Status

()

Core
HTML: Parser
P3
normal
RESOLVED DUPLICATE of bug 70918
18 years ago
15 years ago

People

(Reporter: Jens-Uwe, Assigned: harishd)

Tracking

({testcase})

Trunk
Future
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; m18) Gecko/20000814
BuildID:    2000081420

the web page looks like garbage
it seems the width of some frames is too small.


Reproducible: Always
Steps to Reproduce:
1.go to www.handyshop.de and wait a moment.
2.look at the screen
3.

Actual Results:  looks strange

Expected Results:  should look good

the html code of the page seems to be messy

Comment 1

18 years ago
Just CC'ing myself cos I want to see comments on the frameset html ;) Frankly
I'm astounded that NS4.7 renders it as well as it does. It must be making some
pretty lucky guesses.

Comment 2

18 years ago
the page has three things that look like this:

<FRAME src="blue_01.htm"
       <FRAMESET cols="*,100,*" rows="*" frameborder="no" border="0" 
framespacing="0" scrolling="no">

closing the FRAMEs and removing the FRAMESETs makes both browsers display it 
like ie 5 (looks nice), and just closing the FRAMEs makes both browsers display 
it like moz (looks ugly).  i don't know which behavior is more correct for the 
original page.
OS: Linux → All
Hardware: PC → All

Comment 3

18 years ago
Created attachment 13188 [details]
demonstration of what seems to be a parser problem: <b homer=""<i> donuts

Comment 4

18 years ago
confirming and sending to parser.

moz 2000081908 on win98 makes the donuts bold and italic in the above testcase, 
whereas ie 5.5 and netscape 4.75 just make them bold.

when i view-source in moz, i see a > where there isn't one.  should this be a 
separate bug?
Status: UNCONFIRMED → NEW
Component: Layout → Parser
Ever confirmed: true
Summary: incorrect width of frames → unclosed (unfinished?) tags handled in a strange way

Comment 5

18 years ago
if you fix the frames and then look at the page with mozilla, bug 37656 is 
visible in the center frame.  (completely unrelated to this bug, just saying 
this to avoid getting a dup report of bug 37656)
Dividing up claytons bugs to triage.
Assignee: clayton → rods

Comment 7

18 years ago
sounds like a parser bug/content sink bug - reassigning
Assignee: rods → harishd
(Assignee)

Comment 8

18 years ago
This is total wackyness in the document.  I think this bug is a "nice to fix"
but not a "must fix".  Marking it FUTURE.
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Comment 9

18 years ago
Yes, it's wacky, but I think it's important that at least the view-source part 
of this bug be fixed.  Clearing "future" milestone.
Target Milestone: Future → ---
(Assignee)

Comment 10

18 years ago
Nope, not a high priority at this stage of the project. We have more important 
things to fix. Sorry. Have to mark this bug FUTURE.
Target Milestone: --- → Future

Updated

18 years ago
Blocks: 57724
(Reporter)

Comment 11

18 years ago
seems to work fine with the build 20001022 for Linux.
Can someone mark this as FIXED?

Comment 12

18 years ago
http://www.handyshop.de/ has fixed the problem, but Mozilla still screws up 
when viewing and view-sourcing the testcase.

By the way, should the view-source thing be a separate bug?
the view source bug here is also bug 70918.  If that is dupped against this,
please change the summary of this to reflect the fact that it is a view source bug.
No longer blocks: 57724

*** This bug has been marked as a duplicate of 57724 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
Reopening 57724 dependencies for independent resolution.
Status: RESOLVED → REOPENED
Depends on: 57724
Keywords: testcase
Resolution: DUPLICATE → ---

*** This bug has been marked as a duplicate of 70918 ***
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → DUPLICATE
Summary: unclosed (unfinished?) tags handled in a strange way → extra ">" added to unclosed tags.

Updated

15 years ago
No longer depends on: 57724
You need to log in before you can comment on or make changes to this bug.