Closed Bug 2682 Opened 26 years ago Closed 25 years ago

<P> tags after headings are eaten by Composer

Categories

(Core :: DOM: Editor, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: paulmac, Assigned: akkzilla)

Details

Dup of 117501, moved to bugzilla for 5.0 tracking -------------------------------------------- Opening and saving an HTML file in Composer removes the <P> tag located right after heading or body tags. Steps to reproduce: 1. Using a text editor, create a file as follows and save it as mypage.html <HTML> <HEAD> <TITLE>mypage</TITLE> </HEAD> <BODY> <P>foo</P> <H1>First heading<H1> <P>foo1</P> <H2>Second heading<H2> <P>foo2</P> </BODY> </HTML> From navigator: 3. Select File|Open page and choose the file just created 4. Select Composer and press the Open button 5. Select File|Save As, type in mypage2.html and press the Save button 6. Type mypage.html and mypage2.html files from OS and compare contents /*original <P> tags are missing*/ ------- Additional Comments From brade 05/31/98 14:06 ------- The HTML above is not valid (Header tags aren't closed) and P tags are not strictly required in the case that the headers are closed properly. Moving bug to 5.0 (fix probably will have to wait for Raptor).
Setting all current Open/Normal to M4.
Status: NEW → ASSIGNED
the heck is this?
QA Contact: 4079
This was a bug filed against 4.x codebase, moved over to Bugzilla. Unclear if it's still relevant. Sujay assigned QA contact.
Component: Composer → Editor
Product: MozillaClassic → Browser
Target Milestone: M4 → M7
cc brade Is this relevant to ender? Kathy, I don't understand your comment on 05/31/98.
The comments from 5/31/98 are relevant to the old codebase (pre-gecko). The example above is a good test case of bad html which we should test with but I don't expect any particular problems with gecko / parser.
Target Milestone: M7 → M9
this is just a reminder of not doing bad things like we did in the old codebase. However since it is M7 and this bug is not really valid until we start outputting html to files ect. i am moving it to m9 (remind me in 4 weeks ect)
Target Milestone: M9 → M12
keep pushing off until this makes sense
Assignee: mjudge → akkana
Status: ASSIGNED → NEW
Priority: P1 → P3
this is a reminder about a 4.x output bug. reassigned to akkana, just to verify that we don't make this mistake. I expect you can just mark this worksforme and be done with it.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Well, we don't have this problem. We do have other problems on saving this file, which I'm working on (separate bugs filed).
Status: RESOLVED → VERIFIED
verified in 9/16 build.
Note also that the file is wrong -- it doesn't close its heading tags. So it's not surprising that parser or layout would have a problem with it.
You need to log in before you can comment on or make changes to this bug.