Closed
Bug 74383
Opened 23 years ago
Closed 23 years ago
nsBoxToBlockAdaptor::Reflow() prevents TextArea contents from being reflowed
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla0.9.7
People
(Reporter: rh0209ms, Assigned: kinmoz)
References
Details
(Whiteboard: [EDITORBASE] CANDIDATE_094, fixed on trunk and 0.9.4 branch)
Attachments
(9 files, 1 obsolete file)
478 bytes,
image/png
|
Details | |
275 bytes,
text/html
|
Details | |
1.98 KB,
image/png
|
Details | |
1.62 KB,
image/png
|
Details | |
1.18 KB,
image/png
|
Details | |
997 bytes,
text/html
|
Details | |
288 bytes,
text/html
|
Details | |
2.01 KB,
text/html
|
Details | |
1.13 KB,
patch
|
kinmoz
:
review+
attinasi
:
superreview+
|
Details | Diff | Splinter Review |
During longer editing (*) of a textarea input form I suddenly got garbage in the text box (garbage = something which looked like a dump of random memory instead of a human-readable ASCII/ISO-string) and large parts of my text were screwed. My attempts to fix this by cutting out the garbage ended first with a series of very slow responses from Mozilla and then with a complete lock-up. (*) a few minutes of editing with del/backspace and cut'n'paste with either mouse-select or shift-up/down/del/insert I'm using the Red Hat Linux 7.0 compiled Mozilla 0.8: http://people.redhat.com/blizzard/software/RH7/RPMS/i386/
Reporter | ||
Comment 1•23 years ago
|
||
Same with Mozilla 0.8.1-0 from the site mentioned earlier. I have not yet managed to find a way to reproduce that bug. It just happens now and then. This time, mouse cut'n'paste was _not_ involved. All of a sudden I got two lines of garbage at the end of the text area when I cut off the last two lines and inserted them at the top. Interestingly, this time I managed to work-around the garbage by scrolling carefully and copying the whole text into an editor's window. It seemed to me that the text box widget and the internal text strings were out-of-sync.
Reporter | ||
Comment 2•23 years ago
|
||
Comment 4•23 years ago
|
||
could this be related to 22684
Comment 5•23 years ago
|
||
I've never seen this, using daily builds on RH7. I use mozilla or netscape internal builds, though, not the RPM builds. Is it possible that something got corrupted in the rpm builds? Reporter, can you try a build downloaded from mozilla (I use the net installer builds, myself) and see if you still see this? It would help greatly to have a reproducible case.
Reporter | ||
Comment 6•23 years ago
|
||
Well, I'd try Mozilla's own tar.gz releases, provided that they would work on RH 7.0 at all. Previous releases (0.7, 0.8) simply segfaulted on startup. That's why I've been pointed to Christopher Blizzard's builds for RH 7.0. So far, these have worked satisfactory. A few minutes ago I've downloaded the 0.8.1 "x86 tar.gz format" release. When running "mozilla" it prints the environment variables, but doesn't start: ./run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/var/tmp/mozilla LD_LIBRARY_PATH=/var/tmp/mozilla:/home/ms/.kde/lib:/usr/lib LIBRARY_PATH=/var/tmp/mozilla:/var/tmp/mozilla/components SHLIB_PATH=/var/tmp/mozilla LIBPATH=/var/tmp/mozilla ADDON_PATH=/var/tmp/mozilla MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= ms 1769 0.3 0.8 2092 1032 pts/3 S 12:41 0:00 sh /var/tmp/mozilla/run-mozilla.sh ./mozilla-bin ms 1774 7.5 10.5 31016 13480 pts/3 R 12:41 0:00 ./mozilla-bin ms 1776 0.0 10.5 31016 13480 pts/3 S 12:41 0:00 ./mozilla-bin ms 1777 0.0 10.5 31016 13480 pts/3 S 12:41 0:00 ./mozilla-bin ms 1778 0.0 10.5 31016 13480 pts/3 S 12:41 0:00 ./mozilla-bin ms 1779 0.0 10.5 31016 13480 pts/3 S 12:41 0:00 ./mozilla-bin ... rt_sigprocmask(SIG_SETMASK, [RT_0], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [RT_0], 8) = 0 rt_sigaction(SIGINT, {0x806f120, [], 0x4000000}, {SIG_DFL}, 8) = 0 wait4(-1, Any suggestions? Reading bug #22684, I can only repeat that the symptoms of this bug look as if the text box widget is updated with an out-of-date list of text strings after the cut'n'paste operation. Scrolling a bit carefully using the scrollbar at the right or the cursor keys seems to fix the text box contents. But not always (see initial bug report). Hence I have the feeling that more than just a display bug is involved.
Reporter | ||
Comment 7•23 years ago
|
||
With a different user and a "chown MYUSER.MYGROUP * -R" on all files I've got 0.8.1 "x86 tar.gz format" to run. ;-)
Reporter | ||
Comment 8•23 years ago
|
||
It seems it must be a special text box (see attachment). With that test page, the bug is 100% reproducable at my end. When I modify the first line of the HTML source, the bug can no longer be reproduced. Starting with an empty text area, I use the mouse to copy text from an editor. Lines get wrapped since they don't match the line width of the box (step2_1.png). Hence I move the cursor to the end of the first line and press backspace to delete the linefeed and append the second line (this is something I do often when I know that the submitted text is likely to be formatted, e.g. to block-text). Immediately, the two first lines disappear and sometimes also the cursor disappears (step2_2.png). When the cursor has disappeared, I need to click the text area to reactivate it. The "empty" area where once the first two lines of text have been is not clickable. I cannot get back the original text unless I press space which pops up the "hidden" text again. However, subsequent cut'n'paste operations manage to mess up the text area more and more (step2_4.png -- took a 2nd try, hence no step2_3.png).
Reporter | ||
Comment 9•23 years ago
|
||
Reporter | ||
Comment 10•23 years ago
|
||
Reporter | ||
Comment 11•23 years ago
|
||
Reporter | ||
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
this is not linux only, I can reproduce this on win98, to reproduce try this: 1. save the testcase locally, and edit the file to include the close bracket for the body start tag, save it. 2. Open 4.x or another 6.x browser window and scroll to this set of comments ------- Additional Comments From Michael Schwendt 2001-04-10 04:47 ------- 2. highlight the first para in that comment and past into the textarea, when I paste it in, it appears on five lines, like this: It seems it must be a special text box (see attachment). With that test page, the bug is 100% reproducable at my end. When I modify the first line of the HTML source, the bug can no longer be reproduced. 3. set your caret at the end of the second line, hit the spacebar and then hit delete -- you should see the text disappear as Michael mentions. If I go to the end of the pasted text and begin to paste more of the blocks of text, the other paste issues and rendering issues that he mentions are also evident. assigning to Kin, cc simon and mike
Assignee: beppe → kin
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1
Reporter | ||
Comment 14•23 years ago
|
||
I'm using the first two paragraphs from my message at 2001-04-10 03:53. The bug cannot be reproduced with every text.
Comment 15•23 years ago
|
||
Michael: no longer an issue for this specific bug, but I download daily builds nearly every day and run them on RH 7.0. I use the net installer builds (e.g. mozilla-i686-pc-linux-gnu-installer.tar.gz). Yesterday's net installer was broken (didn't actually download any files), so I used the .sea installer instead, which did work.
Comment 16•23 years ago
|
||
I just tried this again and I am still able to reproduce this on win98 using the 10 May build
Assignee | ||
Comment 17•23 years ago
|
||
Hmmmm I can see this bug in OPT builds on WinNt4 and Win98, but not in my debug build. Time to fire up Purify and see if I can spot something ...
Status: NEW → ASSIGNED
Assignee | ||
Comment 18•23 years ago
|
||
I was able to reproduce this problem on WinNt with a MOZ_PROFILE build, which basically builds with debug symbols and Optimizations turned on. While in the debugger, I was seeing strange things, like the "this" pointer of nsTextFrame methods turning NULL when calling other nsTextFrame methods. For example if I was in an nsTextFrame method called foo(), this would be valid, but when code in foo() called this->bar() ... the "this" pointer in bar() would be null leading to strange results and garbage on the screen.
Assignee | ||
Comment 19•23 years ago
|
||
Assignee | ||
Comment 20•23 years ago
|
||
Assignee | ||
Comment 21•23 years ago
|
||
After debugging this a bit, there seems to be a difference between the number of reflows that happens in a Win32 debug build versus an OPT build. It seems that nsBoxToBlockAdaptor::Reflow() thinks that a reflow, which is neccessary to create some continuing frames and to reset the data in an existing text frame who's textnode contents has changed, is not neccessary because it's mLastSize == (aWidth, aHeight) ... so we end up painting frames with bad values in them. I just wanted to give an update in case this rings any bells.
Comment 22•23 years ago
|
||
It doesn't for me, but maybe hyatt or evaughan could comment. It looks like nsBoxToBlockAdaptor is stifling reflows?
Assignee | ||
Comment 23•23 years ago
|
||
Ok, I think I have a handle on what's going on here, but I may have a little trouble explaining it. Note: My Debug and OPT builds were built with VC++ 6.0 ServicePack 3 on Windows NT 4 Service Pack 5 ... I mention this, because I can't seem to repro the problem on my Home machine running VC++ 6.0 Sp3 and Windows NT 4 Sp6. To reproduce the problem I used the 05/22/01 15:10 (Smaller test case). I copied the entire line below the text area ("is 100% reproducable at my end. When I"), then pasted it into the textarea, I then placed the caret before the first 'r' character in the word "reproducable" and pasted again. You should then see garbage. There seems to be 2 problems: 1. nsBoxFrame::Reflow() triggers a call to nsGfxTextControlFrame2::ReflowStandard(), which calls dx->GetScrollBarDimensions(sbWidth, sbHeight); which seems to return an sbWidth of 239.999985 in debug builds, and 240.000000 in OPT builds. This value is then multiplied by a scale variable (1.0000) and cast to a PRInt32, so we get a difference of one twip between debug (239) and OPT (240) builds. Knowing this fact, you can modify nsGfxTextControlFrame2::ReflowStandard() so that sbWidth is manually set to 240 to reproduce the garbage problem in a debug build. This difference of 1 twip is enough to change the outcome of nsTextFrame::MeasureText() during the first paste in my test case, and invoke the 2nd problem below. It's important to note that this scrollbar width is used in the calculation of the block (which is a div inside the textarea) frame width. This block frame width is also used in MeasureText() which is called when reflowing textframes. 2. It seems that in debug builds, the first paste I do causes MeasureText to return a width that is less than the preferred size of the textarea, so nsBoxToBlockAdaptor::Reflow() saves this width (the one returned from MeasureText) as it's mLastSize.width, so the next paste i do results in nsBoxToBlockAdaptor::Reflow() calling mFrame->Reflow() because aWidth (the current block width) is not equal to mLastSize.width. In opt builds, the first paste I do causes MeasureText to return a width that is the same as the containing block frame, so nsBoxToBlockAdaptor::Reflow() stores this as it's mLastSize.width, so the next time I paste, nsBoxToBlockAdaptor::Reflow() compares aWidth (which is basically the current block frame width) with it's mLastSize.width and since they are equal, it thinks it does not need to call mFrame->Reflow(). This results in continuing frames not being created and stale data in text frames that existed prior to the 2nd paste. So #2 is obviously the bigger bug, since it really shouldn't matter what size the scrollbars are. #1 just illustrates that there are some differences between OPT and Debug builds. So should this bug go to evaughan@netscape.com now?
Assignee | ||
Comment 24•23 years ago
|
||
Over to evaughan@netscape.com.
Assignee: kin → evaughan
Status: ASSIGNED → NEW
Comment 25•23 years ago
|
||
clearing target for re-triage by new owners
Target Milestone: mozilla0.9.1 → ---
Comment 26•23 years ago
|
||
how serious is this? should we try and get it for rtm?
Assignee | ||
Comment 27•23 years ago
|
||
I hear that people run into this bug all the time. It's very disconcerting when some of your textarea content renders as garbage, and some of it disappears, not to mention that you can actually crash sometimes when trying to select this garbage. I think it should be fixed before RTM. :-)
Reporter | ||
Comment 28•23 years ago
|
||
Build ID 2001062823 on Linux has another and new bug in the text area editor. When moving right (or left) with the cursor keys the cursor stops at strange word boundaries when it is expected to move to the end of the form. It looks like it is help up by hidden string delimiters inserted after a cut'n'paste job. The only work-around is to move the cursor "around" (i.e. up, right, down, or down, right, up) those places, whatever it may be that blocks proper movement. To reproduce this, I type a long text which extends over 2-3 lines at least. I then position the cursor at some arbitrary plac, press return to insert a line feed, and then go back and press delete to concatenate the two pieces again. Afterwards, the cursor is not able to move across the position where I did that "split'n'merge lines" thing.
Reporter | ||
Comment 29•23 years ago
|
||
Lame typos of mine: it is help up -> it is _held_ up at some arbitrary plac, -> at some arbitrary _place_,
Assignee | ||
Comment 30•23 years ago
|
||
In order to avoid morphing this bug into something else ... I filed bug 90141 to cover the *new* issue reported by mschwendt@yahoo.com (Michael Schwendt) above.
Comment 31•23 years ago
|
||
What is the status of this bug? I've tried to reproduce it, but failed both on windows 98 and Linux RedHat 6.2 builds... should this be resolved?
Reporter | ||
Comment 32•23 years ago
|
||
I haven't been able to reproduce it for some time. Using Linux Build ID 2001100808 right now. One issue (probably related to bug #90141, too) is left though: At the end of sentences, the editor loses at least one of multiple newline characters _sometimes_ causing "what you see is NOT what you get". Where I want an empty line and press return twice, I see an empty line, but I don't get any in the submitted data. This is _not always_ reproducible, but clearly a bug in Mozilla's code because it has worked before. Copying may be required, but I haven't found out yet.
Comment 33•23 years ago
|
||
This is definately not a crash any more, and the end of line problem is completely different from the original bug... Michael, Please file a separate bug for it. I'll resolve this as works for me.
Assignee | ||
Comment 34•23 years ago
|
||
This bug is still alive and well, and I just created a test case that makes it easy to reproduce on any platform, using any skin/font. I have 3 separate bugs regarding, Deletion, Pasting, and Setting the value of a textarea via JS, all of which are due to this bug. Rather than duping them all to this one bug, I'm going to resummarize this bug to state what the problem is, and then make those bugs dependent on this one. Old summary: textarea input form crashed during complex edit session New summary: nsBoxToBlockAdaptor::Reflow() prevents TextArea contents from being reflowed
Status: RESOLVED → REOPENED
OS: Linux → All
Hardware: PC → All
Resolution: WORKSFORME → ---
Summary: textarea input form crashed during complex edit session → nsBoxToBlockAdaptor::Reflow() prevents TextArea contents from being reflowed
Assignee | ||
Comment 35•23 years ago
|
||
Using the buttons in the test case, adjust the width of the textarea until the arrow ("-->") on the textarea's first line is as close to the textarea's vertical scrollbar as possible, without creating a horizontal scrollbar. Note: To see any of the bugs listed below, the textarea must have a vertical scrollbar and no horizontal scrollbar. Make sure you don't touch the first line in the textarea, the one that contains the arrow, while attempting any of the edits listed below. * Delete some lines of text. (bug 101122) * Copy some text within the textarea and paste it back into the textarea. Make sure that whatever you paste does not create a horizontal scrollbar. (bug 107973). * Type something in the textarea, then hit the "Reset Content" button. (bug 107973).
Reporter | ||
Comment 36•23 years ago
|
||
Using the "Reliable Test Case" I'm able to reproduce a couple of symptoms again. When cutting out lines (using SHIFT+CURSOR_DOWN and DELETE block operations) I get empty graphical lines which the cursor cannot reach or edit. It just skips them. Please also see comment #32. I still get such minor bugs in the text area editor occasionally, but I don't have the overview of where possible duplicates might have been reported long ago. Something must be wrong with how line (or string) delimiters are handled.
Comment 37•23 years ago
|
||
Comment 38•23 years ago
|
||
Patch moved to bug#110328
Assignee | ||
Comment 39•23 years ago
|
||
Here's the one line change, extracted from evaughan's box incremental reflow rewrite, that fixes the problem. I tweaked the comments a bit to make them consistent with each other.
Attachment #57839 -
Attachment is obsolete: true
Assignee | ||
Comment 40•23 years ago
|
||
After the patch has been reviewed, we'll probably want to check this into the trunk and to the 0.9.4 and 0.9.6 branches if we can since the 3 bugs that depend on this are the most reported problems I hear about in regards to textareas.
Whiteboard: FIX IN HAND, need r= and sr=
Target Milestone: --- → mozilla0.9.7
Comment 41•23 years ago
|
||
r=evaughan on your patch
Comment 42•23 years ago
|
||
Comment on attachment 57971 [details] [diff] [review] Patch Rev 1 (One line fix extracted from previous incremental reflow patch) sr=attinasi
Attachment #57971 -
Flags: superreview+
Attachment #57971 -
Flags: review+
Assignee | ||
Comment 44•23 years ago
|
||
Fixed checked into trunk: mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp revision 1.33 I'm leaving this open till I can land this on the 0.9.4 branch.
Status: NEW → ASSIGNED
Whiteboard: FIX IN HAND, need r= and sr= → CANDIDATE_094, fixed on trunk
Whiteboard: CANDIDATE_094, fixed on trunk → [EDITORBASE] CANDIDATE_094, fixed on trunk
Comment 45•23 years ago
|
||
*** Bug 110833 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 46•23 years ago
|
||
*** Bug 25538 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 47•23 years ago
|
||
Nominating for edt0.9.4 since this causes some of the most reported problems with textareas. (See the "Bug 74383 blocks" list above.)
Keywords: edt0.9.4
Comment 48•23 years ago
|
||
was this fix verified on the trunk (and there are no known regressions)? if yes, please check the fix (I assume that this is the one liner patch above) into 0.9.4 branch.
Assignee | ||
Comment 49•23 years ago
|
||
The fix has been on the trunk since 11/21/01, without anyone reporting any regressions. There was some confusion on my part as to whether or not I should resolve this bug as FIXED before I got permission to check it in on the 0.9.4 branch, but I guess what I'll do is mark this bug as FIXED so that vladimire@netscape.com can verify it on the TRUNK. After he does this, I'll check it in on the 0.9.4 branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Keywords: vtrunk
Resolution: --- → FIXED
Assignee | ||
Comment 50•23 years ago
|
||
*** Bug 107973 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 51•23 years ago
|
||
*** Bug 100727 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 52•23 years ago
|
||
*** Bug 101122 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 53•23 years ago
|
||
*** Bug 112475 has been marked as a duplicate of this bug. ***
Comment 54•23 years ago
|
||
verifying on 2001-12-03-03-trunk windows 98 and 2001-12-03-08-trunk linux
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 55•23 years ago
|
||
Fixed checked into MOZILLA_0_9_4_BRANCH: mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp revision 1.24.66.3
Keywords: fixed0.9.4
Whiteboard: [EDITORBASE] CANDIDATE_094, fixed on trunk → [EDITORBASE] CANDIDATE_094, fixed on trunk and 0.9.4 branch
Comment 56•23 years ago
|
||
*** Bug 106593 has been marked as a duplicate of this bug. ***
Comment 57•23 years ago
|
||
*** Bug 110186 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 58•23 years ago
|
||
*** Bug 112753 has been marked as a duplicate of this bug. ***
Updated•5 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•