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)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
mozilla1.8beta3
People
(Reporter: camino-bugs, Assigned: mrbkap)
References
()
Details
(Keywords: dataloss, regression)
Attachments
(4 files, 1 obsolete file)
212.61 KB,
image/jpeg
|
Details | |
65.86 KB,
image/png
|
Details | |
111.63 KB,
image/png
|
Details | |
3.04 KB,
patch
|
jst
:
review+
jst
:
superreview+
dbaron
:
approval1.8b3+
|
Details | Diff | Splinter Review |
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•20 years ago
|
||
when did this regress?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Camino0.9
Reporter | ||
Comment 2•20 years ago
|
||
Confirmed that Firefox 1.0.4 and Safari 2.0 (412) work fine editing the document.
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•20 years ago
|
||
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•20 years ago
|
||
Just kidding!...
This happened first in the June 2 build.
To reproduce, you *must* have two windows open... weird.
Comment 7•20 years ago
|
||
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•20 years ago
|
||
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
Comment 9•20 years ago
|
||
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•20 years ago
|
||
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
Comment 12•20 years ago
|
||
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.
Updated•20 years ago
|
Flags: blocking1.8b3?
Comment 13•20 years ago
|
||
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.
Updated•20 years ago
|
Priority: -- → P1
Hardware: Macintosh → All
Comment 15•20 years ago
|
||
can someone isolate the date on which this started happening? then we can better
point the finger.
Flags: blocking-aviary1.1?
Comment 16•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
CCing a few people who had checkins during this time.
Comment 19•20 years ago
|
||
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
Assignee | ||
Comment 20•20 years ago
|
||
This is almost certainly a regression from bug 208869. Can somebody test to see
if the patch in bug 152329 fixes this?
Comment 21•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 23•20 years ago
|
||
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.
Comment 24•20 years ago
|
||
Adding better test URL.
Assignee | ||
Comment 25•20 years ago
|
||
My guess was wrong. I'm now poking around the HTML content sink to see if it's
the culprit for this.
Assignee | ||
Comment 26•20 years ago
|
||
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?
Assignee | ||
Updated•20 years ago
|
Attachment #186354 -
Flags: superreview?(brendan)
Attachment #186354 -
Flags: review?(jst)
Attachment #186354 -
Flags: approval1.8b3?
Assignee | ||
Comment 27•20 years ago
|
||
Attachment #186354 -
Attachment is obsolete: true
Attachment #186385 -
Flags: superreview?(brendan)
Attachment #186385 -
Flags: review?(jst)
Comment 28•20 years ago
|
||
I can verify that applying patch 2 fixes the problem on Camino (otherwise up to
date to today's CVS). Thanks Blake.
Comment 29•20 years ago
|
||
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+
Attachment #186385 -
Flags: approval1.8b3+
Comment 30•20 years ago
|
||
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.
Description
•