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)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: rzach, Assigned: harishd)

References

()

Details

(Keywords: testcase, Whiteboard: [TESTCASE][PDT+] Expected Landing Date - 02/11/99)

Attachments

(1 file)

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.
On the 1999112508 Linux build, Mozilla hangs when trying to render the page, after drawing the first three rows of the table (till "Description").
Summary: Input and pop-up fields missing → Data in nested table in form disappears
Whiteboard: [TESTCASE]
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>
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.
Severity: normal → major
The crash might be related to the issue reported in bug 18480.
QA Contact update.
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?
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.
Status: NEW → ASSIGNED
Target Milestone: M14
Severity: major → critical
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.
*** Bug 22837 has been marked as a duplicate of this bug. ***
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
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.
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
The HTML in the dmoz edit screens has been fixed; Mozilla should now work for editing there.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Harish, in the attachment, the parser should be construcing a <td> for the text "test".
Assignee: karnaze → harishd
Status: ASSIGNED → NEW
Marking beta1.
Keywords: beta1
In reference to comment 1999-11-27 14:23 For the second test case, one with INPUT, refer to bug 1399.
Whiteboard: [TESTCASE] → [TESTCASE][PDT+]
Whiteboard: [TESTCASE][PDT+] → [TESTCASE][PDT+] Expected Landing Date - 02/11/99
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
Verified on Linux build 2000.02.13.09.
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: