Closed Bug 3109 Opened 26 years ago Closed 25 years ago

XML documents are broken when veiwed with file:// protocol

Categories

(Core :: Layout: Form Controls, defect, P2)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: peterl-retired, Assigned: karnaze)

References

(
URL
)

Details

Apparently the frames rely on there not being any other nodes between them in the content model. This is not true in XML. Not only does the field set not layout propery (contents replaced by duplicate legend), but crashes on document close in DeleteFrames. If you remove all the whitespace between the <fieldset> and the <legend> it works fine. <?xml version="1.0"?> <body xmlns="http://www.w3.org/TR/REC-html40"> <form> <fieldset> <legend>legend</legend> test<br/>test </fieldset> </form> </body>
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
It works on my 3/1 NT debug build.
Status: RESOLVED → REOPENED
Sorry, but the bug still exhibits the same behavior (Windows build, 3/2/99) If you use the sample XML code, the text "legend" is displayed correctly inside a legend box, which is embeded in the top border the fieldset border. But "legend" in a bordered box is duplicated in the area inside the fieldset's border, and any other tags that are between the <fieldset> and </fiedlset> are ignored, so you don't see the text "test" If you delete the whitespace between the <fieldset> and <legend>, so it looks: <fieldset><legend>legend</legend> test<br/>test </fieldset> then it will display "test" correctly inside the fieldset box. Note that after displaying incorrectly, the layout engine seems to be in an unstable state -- if you try to reload the same URL or a different one, viewer.exe will crash at: nsFrameList::DeleteFrames(nsIPresContext & {...}) line 28 + 13 bytes nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x013a2d00, nsIPresContext & {...}) line 81 nsLineBox::DeleteLineList(nsIPresContext & {...}, nsLineBox * 0x0139f5a0) line 228 nsBlockFrame::DeleteFrame(nsBlockFrame * const 0x013a25c0, nsIPresContext & {...}) line 432 + 16 bytes nsAreaFrame::DeleteFrame(nsAreaFrame * const 0x013a25c0, nsIPresContext & {...}) line 102 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 30 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x013a2220, nsIPresContext & {...}) line 81 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 30 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x013a17a0, nsIPresContext & {...}) line 81 nsFrameList::DeleteFrames(nsIPresContext & {...}) line 30 nsContainerFrame::DeleteFrame(nsContainerFrame * const 0x013a15c0, nsIPresContext & {...}) line 81 ViewportFrame::DeleteFrame(ViewportFrame * const 0x013a15c0, nsIPresContext & {...}) line 112 PresShell::~PresShell() line 510
What I see is a bordered legend with content "legend" and inside the fieldset I see 2 lines of text, each one containing "test". Removing the whitespace between the <fieldset> and <legend> has the same behavior. Further, there is no bad behavior when reloading the test a 2nd or 3rd time. I'm using a 3/1 NT debug build. Are you by any chance using an optimized build?
Well this is weird. I only run the debug version I build with VC++ 5.0 I definitely see the bug as described with the latest build (11am, 3/3/99)
Be sure you test the sample in a file with ".xml", not ".html"
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
added urls: http://wetnap/seamonkey/bugs/bug3109.xml -- original testcase http://wetnap/seamonkey/bugs/bug3109a.xml -- whitespace removed for the record, i tried this on win95 and redhat 5.2 with the morning March 9, 1999 builds from sweetlou, and both worked fine. i'll try later on nt. so which is it? REOPENED, or RESOLVED WORKSFORME? (i.e. should i clear the resolution?)
Status: REOPENED → RESOLVED
Closed: 26 years ago → 26 years ago
ok, so i tried it on nt, and it worked fine there too. i'm resolving this works for me...
Status: RESOLVED → VERIFIED
... and verfiying it. i'll check for regressions later on...
Status: VERIFIED → REOPENED
This is not dead yet. And it is mysterious. I loaded the test URL and indeed it looks OK. But I get the bug when I display that same source from a local file: Here is the contents of http://wetnap/seamonkey/bugs/bug3109.xml: <?xml version="1.0"?> <body xmlns="http://www.w3.org/TR/REC-html40"> <form> <fieldset> <legend> legend </legend> test<br/>test </fieldset> </form> </body> Save this to a local file and load it into the view and you should see the layout error as described above.
looks like we have a new bug. layout works fine from http://, but file:// seems to be broken. i think this problem is new and different, and definitely not anything to do with the Widget Set, as the Component category above would have us believe. so we can either: 1. open that as a new bug or 2. let 3109 transmogrify into a new cross platform bug with the Component set to one of "Parser", "XML" or "Networking library", and the summary "XML broken with 'file://' protocol" what do you think is the right thing to do?
It seems simplest to reclassify this as necessary to keep current bug history.
OS: Windows NT → All
Hardware: PC → All
Resolution: WORKSFORME → ---
Summary: Fieldset & Ledgend don't work in XML documents → XML documents are broken when veiwed with file:// protocol
clearing resolution and updating summary, platform and OS
steps to reproduce (on any platform as of the build on March 10, 1999): 1. view the above url with seamonkey: http://wetnap/seamonkey/bugs/bug3109.xml 2. it should layout ok. (as described earlier in this report.) 3. save the .xml file to disk (using nova or dogbert) 4. view the same file in seamonkey but locally: file://c|/temp/bug3109.xml 5. observe the layout error (as described earlier in this report.) is this a problem with protocols, XML, or Parser? (cc'ing nisheeth@netscape.com, gagan@netscape.com, and rickg@netscape.com)
Status: REOPENED → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → FIXED
Fixed with latest checkin.
Status: RESOLVED → VERIFIED
verified on 1999-05-10-08 RedHat Linux 5.2 kernel 2.2.7 1999-05-10-08 WinNT 4.0 sp4 1999-05-10-08 MacOS 8.51
Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.
You need to log in before you can comment on or make changes to this bug.