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

Status: RESOLVED FIXED

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

Description

[Steve Jacobs (irc: encro)]

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.

Comment 1

[Mike Pinkerton (not reading bugmail)]

when did this regress?

Comment 2

[Steve Jacobs (irc: encro)]

Confirmed that Firefox 1.0.4 and Safari 2.0 (412) work fine editing the document.

Comment 3

[Mike Pinkerton (not reading bugmail)]

i assume this works in 0.8.x?

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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).

Comment 5

[Samuel Sidler (old account; do not CC)]

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.

Comment 6

[Samuel Sidler (old account; do not CC)]

Just kidding!...

This happened first in the June 2 build.

To reproduce, you *must* have two windows open... weird.

Comment 7

[Samuel Sidler (old account; do not CC)]

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?

Comment 8

[Samuel Sidler (old account; do not CC)]

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.

Comment 9

[Samuel Sidler (old account; do not CC)]

Attachment: Screenshot of behavior in Firefox nightly 6/2.

Again, this does *not* appear in the 6/1 builds of Firefox or the 5/31 one of
Camino (there was no 6/1).

Comment 10

[Echidnae]

Attachment: messed up text in Camino

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.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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).

Comment 12

[Samuel Sidler (old account; do not CC)]

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.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: Screenshot of the same problem in Win XP

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.

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

changed os to "all"

Comment 15

[Mike Pinkerton (not reading bugmail)]

can someone isolate the date on which this started happening? then we can better
point the finger. 

Comment 16

[Samuel Sidler (old account; do not CC)]

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.

Comment 17

[Samuel Sidler (old account; do not CC)]

Per bsmedberg, adding the bonsai query for easier searching:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-01&maxdate=2005-06-03&cvsroot=%2Fcvsroot

Comment 18

[Samuel Sidler (old account; do not CC)]

CCing a few people who had checkins during this time.

Comment 19

[Benjamin Smedberg]

Smoketest blocker, I would consider closing the tree for this.

Comment 20

[Blake Kaplan (:mrbkap) (inactive)]

This is almost certainly a regression from bug 208869. Can somebody test to see
if the patch in bug 152329 fixes this?

Comment 21

[Bruce Davidson]

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.

Comment 22

[Asa Dotzler [:asa]]

->blake.

Comment 23

[Blake Kaplan (:mrbkap) (inactive)]

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.

Comment 24

[Samuel Sidler (old account; do not CC)]

Adding better test URL.

Comment 25

[Blake Kaplan (:mrbkap) (inactive)]

My guess was wrong. I'm now poking around the HTML content sink to see if it's
the culprit for this.

Comment 26

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v1

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.

Comment 27

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: patch v2

Comment 28

[Bruce Davidson]

I can verify that applying patch 2 fixes the problem on Camino (otherwise up to
date to today's CVS). Thanks Blake.

Comment 29

[Johnny Stenback (:jst)]

Comment on attachment 186385 [details] [diff] [review]
patch v2

r+sr=jst

Comment 30

[Josh Aas]

landed on trunk