Closed Bug 297338 Opened 20 years ago Closed 20 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: 20 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: