Richard Zach Reporter
	Description • 25 years ago

I saved an edit screen from dmoz.org at
http://www.math.berkeley.edu/~zach/edit.html

Next to "Move to another category" there should be a pop-up selection field and
a text entry field.  Neither are displayed on my Linux 1999111520 build.  Also,
the text entry fields "Description" and "ODP Note" should not have horizontal
scroll bars.

	Richard Zach Reporter
	Comment 1 • 25 years ago

On the 1999112508 Linux build, Mozilla hangs when trying to render the page,
after drawing the first three rows of the table (till "Description").

	Richard Zach Reporter
	Comment 3 • 25 years ago

I've attached an HTML fragment where the problem occurs:  This produces no
output, the text "test" is swallowed.

<form>
<table><tr><td>
<table><tr>
test
</tr></table>
</td></tr></table>
</form>

1. It works if the <form> tag is removed
2. It works if the outer <td> tag is removed
3. It works if a <td> tag is inserted after the second <tr>

In the following slightly modified case, (2) will show "test" but not the input
field:

<form>
<table><tr><td>
<table><tr>
test
<input name="text" size=50>
</tr></table>
</td></tr></table>
</form>

	Richard Zach Reporter
	Comment 4 • 25 years ago

The original page (but not the testcase fragment) still crashes Mozilla
(1999112808 Linux).  If the file is saved to disk and then opened using File |
Open File, it doesn't crash, but the two fields are still missing.

	Richard Zach Reporter
	Comment 5 • 25 years ago

The crash might be related to the issue reported in bug 18480.

	gerardok
	Comment 6 • 25 years ago

QA Contact update.

	Sean Richardson
	Comment 7 • 25 years ago

Tested with current binary on NT. As reported on Linux, the URL does not show
anything beside "Move to another category", and hangs the browser.

The text entry fields "Description" and "ODP Note" do not have horizontal
scroll bars, but these <textarea>s redisplay several times, first, wider
than expected to the left, then apparently the normal width overlaid the
overwide <textarea>, with a thick black line at the left of the normal
width, then normal width. Judging by the scrollbar, none of the page below
"Date:" is displayed before the browser hangs. At that point, near-100% cpu
usage is seen until the mozilla task is killed. All of this happens whether
the page is fetched from an http:// or a file:// URL.

Viewing the attached testcase, the word "test" is never seen, instead, the
entire canvas flashes black before redrawing white, at which point the [Stop]
button greys and the browser is responsive.

Tested with: 1999-12-14-08-M12 nightly binary on Windows NT 4.0sp3

zach@math.berkeley.edu, do you see any changes on Linux with a current build?

	Richard Zach Reporter
	Comment 8 • 25 years ago

On 1999.12.14.08 Linux:

The original edit screens at dmoz.org don't hang the browser, but the "Move to
another category" fields are still missing.

http://www.math.berkeley.edu/~zach/edit.html hangs the browser after trying to
render some textinput boxes; no other text appears.

The testcase fragment does not hang the browser, but still no text.

	Richard Zach Reporter
	Comment 9 • 25 years ago

With 2000.01.02.09 Linux build, Mozilla crashes outright with segmentation fault
on http://www.math.berkeley.edu/~zach/edit.html and the dmoz.org edit screens.

	Richard Zach Reporter
	Comment 10 • 25 years ago

*** Bug 22837 has been marked as a duplicate of this bug. ***

	smalllinux
	Comment 11 • 25 years ago

When I run mozilla from:
/usr/local/package/mozilla
mozilla crashes with segfault.

When I run the mozilla-bin with ltrace,
mozilla does not crash, but the data in the bottom of the form is invisble.
here is my ltrace output:

_._8nsString(0x08735af0, 3, 0x2b87b06c, 0x0858a5f8, 0x0858a6d0) = 0
_._8nsString(0x086b16b8, 3, 0x2b87b06c, 0x0858a5f8, 0x0858a6d0) = 0
_._8nsString(0x08675088, 3, 0x2aea4da8, 0x2aea42e0, 0x7ffff208) = 0
Document
http://www.dmoz.org/editors/editurl.cgi?url=http%3a//www.onelist.com/myonelist&cat=Bookmarks/S/superant&ref=onelist.com%25myonelist
loaded successfully
Document: Done (5.182 secs)
_._8nsString(0x086ad4e8, 3, 0x2b87b06c, 2, 0x7ffff144) = 0
_._8nsString(0x086ad4e8, 3, 0x2b87b06c, 2, 0x7ffff144) = 0
_._8nsString(0x086ad4e8, 3, 0x2b87b06c, 2, 0x7ffff144) = 0
_._8nsString(0x086ad4e8, 3, 0x2b87b06c, 2, 0x7ffff144) = 0

	smalllinux
	Comment 12 • 25 years ago

I suspect as mentioned in http://bugzilla.mozilla.org/show_bug.cgi?id=18480
we are seeing a "blowing the stack during frame construction"
The edit page at dmoz is three tables deep within a form where it blows up.
And before the blow up it has numberous badly formed and unclosed td and tr
pairs. I guess we need to enter this bug in the dmoz bug system.

	Richard Zach Reporter
	Comment 13 • 25 years ago

Filed bug 11/29/99 in the dmoz Bugs&Features forum.  I'll send email to
staff@dmoz.org
http://dmoz.org/forum/threaddisplay.cgi?t=Forum21/HTML/000991.html

	Richard Zach Reporter
	Comment 14 • 25 years ago

The HTML in the dmoz edit screens has been fixed; Mozilla should now work for
editing there.

	ekrock's old account (dead)
	Comment 15 • 25 years ago

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

	karnaze (gone)
	Comment 16 • 25 years ago

Harish, in the attachment, the parser should be construcing a <td> for the text 
"test".

	ckritzer (gone)
	Comment 17 • 25 years ago

Marking beta1.   

	harishd Assignee
	Comment 18 • 25 years ago

In reference to comment 1999-11-27 14:23 

For the second test case, one with INPUT, refer to bug 1399.

	harishd Assignee
	Comment 19 • 25 years ago

Bug was caused due to the FORM that was behaving as a container in the sink and 
as anon-container in parser.  this caused the stack to be different in the sink 
and parser.  FIXED now.

	Richard Zach Reporter
	Comment 20 • 25 years ago

Verified on Linux build 2000.02.13.09.