Closed Bug 297338 Opened 19 years ago Closed 19 years ago

HTML Editform TextView (textarea) appears to truncate at 4096 characters.

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta3

People

(Reporter: camino-bugs, Assigned: mrbkap)

References

()

Details

(Keywords: dataloss, regression)

Attachments

(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050609 Camino/0.9a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050609 Camino/0.9a1

Editing in a form textview does not retain the entire contents of a long file
resulting in the loss of data. This issue was noticed on the Camino documentaion
wiki.

Reproducible: Always

Steps to Reproduce:

Actual Results:  
Data was lost. It appears to truncate after 4096 characters, perhaps a hardcoded
value?

Expected Results:  
Textview should display entire contents of file and not truncate so that the
complete content is saved.
when did this regress?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Camino0.9
Confirmed that Firefox 1.0.4 and Safari 2.0 (412) work fine editing the document.
i assume this works in 0.8.x?
Keywords: dataloss, regression
Ah, this sounds like the problem I was having on NeoWiki, but I wrote it off to
network conditions because it only appeared to happen when I was on dialup and
vanished on high-speed connections (and on dialup a reload or hard reload would
fill the textarea will all the existing page data).

If indeed it's the same thing, it regressed in the June 2nd nightly, I think
(+/- a day).
I can't confirm this. I've tested it (with Julian) in 5/31 through 6/9 (minus
6/6) and had no problems.

Is this OS specific?

Can someone give a better listing of what exactly was done: OS version, Camino
nightly version, etc.
Just kidding!...

This happened first in the June 2 build.

To reproduce, you *must* have two windows open... weird.
Three possible causes (checkins) happened on 6/1... I'd rule out the build on
10.4 one. The one regarding bug 296001 doesn't seem to have anything to do with
this either. The only other Camino-specific checkin related to font prefs and
was bug 185750.

Really, I have no clue what could have done this. The "closest" thing is the
font pref checkin, but that seems far out. Are we *sure* this doesn't happen in
Firefox with two windows open?
I can reproduce this on the Firefox nightlies. To do so, you'll need to
continually open windows until one does it, but it *will* do it.

I'll be attaching a screenshot of what it looks like in Firefox (someone else
will attach Camino), and moving this to Core.
Component: HTML Form Controls → Layout: Form Controls
Product: Camino → Core
Target Milestone: Camino0.9 → ---
Version: unspecified → Trunk
Again, this does *not* appear in the 6/1 builds of Firefox or the 5/31 one of
Camino (there was no 6/1).
Yeah, this bug is a pain to reproduce.	Here's a screenshot of what the top
text looks like in Camino when the problem happens.
BTW, I don't need to have multiple windows open to see this; I do usually have
multiple tabs open, though.

I also don't always see the "overprinting" when text is truncated (I do on very
long pages, but shorter pages just truncate).
Assignee: pinkerton → nobody
Status: ASSIGNED → NEW
QA Contact: layout.form-controls
Tested in Firefox Windows nightly from 6/2 and don't see this (running Windows
2003). This appears to be Mac only, but someone should check it further in
Windows and/or Linux.
Summary: HTML Editform TextView appears to truncate at 4096characters. → HTML Editform TextView appears to truncate at 4096 characters.
Flags: blocking1.8b3?
Confirmed in Win XP with Deer Park (20050610 build).

To see it, I opened a bunch of windows (not tabs) and loaded the text edit
widget from that url in each. The fourth window with a text edit showed the
error; subsequent windows did *not* show the error. Not quite sure what the
pattern is here.
changed os to "all"
OS: MacOS X → All
Priority: -- → P1
Hardware: Macintosh → All
can someone isolate the date on which this started happening? then we can better
point the finger. 
Flags: blocking-aviary1.1?
As mentioned in comment 9, it started in the 6/2 builds of both Firefox and
Camino and was not present in the 6/1 build of Firefox or the 5/31 build of Camino.
CCing a few people who had checkins during this time.
Smoketest blocker, I would consider closing the tree for this.
Severity: critical → blocker
Flags: blocking1.8b3?
Flags: blocking1.8b3+
Flags: blocking-aviary1.1?
Target Milestone: --- → mozilla1.8beta3
This is almost certainly a regression from bug 208869. Can somebody test to see
if the patch in bug 152329 fixes this?
Applying the patch from bug 152329 to my build of Camino (updated to CVS
13/06/2005 18:20 UTC) doesn't fix this problem. It might fix the "overtyping"
effect on the first line, but the text is still truncated.
->blake.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
I can't reproduce this, but here is my guess as to what's happening: In
nsHTMLContentSink.cpp, we split large text nodes into more than one text node
(where large is defined as 4096 characters). I'm assuming that we're splitting
the text node and flushing the first 4095 into the textarea, but when we return
from HTMLContentSink::AddText(), we interrupt the parser, which allows other
things to happen. Then (and here's where my comment stops being backed up by
real code) something causes us to think that the textarea has been edited, so
adding and flushing the second is a no-op (see
nsHTMLTextAreaElement::AppendChildTo).

BruceD is kindly testing a potential patch of mine to allow us to reset the text
control frame if we never finished adding children to the textarea.
Summary: HTML Editform TextView appears to truncate at 4096 characters. → HTML Editform TextView (textarea) appears to truncate at 4096 characters.
My guess was wrong. I'm now poking around the HTML content sink to see if it's
the culprit for this.
Attached patch patch v1 (obsolete) — Splinter Review
The problem here is that the textarea element was relying on a call to
AppendChildTo() in order to update its text frame. This wasn't right because of
the case in SinkContext::FlushText(), where it simply appends the new text to
the existing text node (if the new size didn't exceed a given amount). This
patch makes sure that the text area refreshes its frame after all of the
children are added, avoiding the problem.
Attachment #186354 - Flags: superreview?(brendan)
Attachment #186354 - Flags: review?(jst)
Attachment #186354 - Flags: approval1.8b3?
Attachment #186354 - Flags: superreview?(brendan)
Attachment #186354 - Flags: review?(jst)
Attachment #186354 - Flags: approval1.8b3?
Attached patch patch v2Splinter Review
Attachment #186354 - Attachment is obsolete: true
Attachment #186385 - Flags: superreview?(brendan)
Attachment #186385 - Flags: review?(jst)
I can verify that applying patch 2 fixes the problem on Camino (otherwise up to
date to today's CVS). Thanks Blake.
Comment on attachment 186385 [details] [diff] [review]
patch v2

r+sr=jst
Attachment #186385 - Flags: superreview?(brendan)
Attachment #186385 - Flags: superreview+
Attachment #186385 - Flags: review?(jst)
Attachment #186385 - Flags: review+
landed on trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: