Closed
Bug 20087
Opened 25 years ago
Closed 25 years ago
Data in nested table in form disappears
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
VERIFIED
FIXED
M14
People
(Reporter: rzach, Assigned: harishd)
References
()
Details
(Keywords: testcase, Whiteboard: [TESTCASE][PDT+] Expected Landing Date - 02/11/99)
Attachments
(1 file)
(deleted),
text/html
|
Details |
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.
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").
Reporter | ||
Comment 2•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Summary: Input and pop-up fields missing → Data in nested table in form disappears
Whiteboard: [TESTCASE]
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>
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.
Reporter | ||
Updated•25 years ago
|
Severity: normal → major
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?
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M14
Reporter | ||
Updated•25 years ago
|
Severity: major → critical
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.
Reporter | ||
Comment 10•25 years ago
|
||
*** Bug 22837 has been marked as a duplicate of this bug. ***
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
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.
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
Reporter | ||
Comment 14•25 years ago
|
||
The HTML in the dmoz edit screens has been fixed; Mozilla should now work for
editing there.
Comment 15•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Comment 16•25 years ago
|
||
Harish, in the attachment, the parser should be construcing a <td> for the text
"test".
Assignee: karnaze → harishd
Status: ASSIGNED → NEW
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.
Updated•25 years ago
|
Whiteboard: [TESTCASE] → [TESTCASE][PDT+]
Whiteboard: [TESTCASE][PDT+] → [TESTCASE][PDT+] Expected Landing Date - 02/11/99
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 20•25 years ago
|
||
Verified on Linux build 2000.02.13.09.
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•