20207 - Extra newlines in textarea

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[ckritzer (gone)]

The onBlur/onFocus events do not appear to work

Steps to Reproduce:
1) Launch 1999112809 apprunner
2) Load test page (http://marvin/whitebox/tools/Event%20Tools/16-1.html)
3) Click on any field, button, popup list

Actual Results:
No text output (of the onBlur/onFocus events) is displayed in the Input
Events[3] field

Expected Results:
All onBlur/onFocus events will display text output in the Input Events[3] field

Build Date & Platform Bug Found:
Linux6 1999112808 apprunner, while regressing bug 17196

Additional Builds and Platforms Tested On:
Windows & Mac platforms not available to test.  Windows 1999112809 build crashes
on launch, and Macintosh 19992715 build hangs on install.  Will test on Win98 &
Mac86 when build become available.

Comment 1

[ckritzer (gone)]

This bug had a previous incarnation as Bugzilla bugs#4074 & 4079.

Comment 2

[ckritzer (gone)]

Same occurs for Netscape 1999112715 apprunner (fullcircle build).

Comment 3

[rods (gone)]

Chris, I had all this working before you checked in some of your focus work. Let
me know if you need any help figuring it out.

Comment 4

[saari (gone)]

Cool, another test case. I was looking at this problem over the weekend, and it
is partially my fault, partially editor's IMO. I'm trying to get a hold of buster
to talk about it, but I do have some changes that make this page work again.

Comment 5

[Peter Trudelle]

This seems to work in today's opt build, resolving as fixed by recent saari
changes.

Comment 6

[ckritzer (gone)]

Updating QAContact.

Comment 7

[ckritzer (gone)]

Sorry Chris, this is still busted in the 2000-01-26-xx M13 builds...
- MacOS86 2000-01-26-01
- Linux6 2000-01-25-20
- Win98 2000-01-25-20

Comment 8

[leger]

Clearing FIXED resolution due to reopen.

Comment 9

[saari (gone)]

Uh, this definitely worked before. Now I see *nothing* showing up in the Input 
Events dialog, no key events, nothing. Something larger than focus is broken 
here.

Comment 10

[Peter Trudelle]

Yup.  Clearing target milestone.  Who gets this?

Comment 11

[saari (gone)]

Don't know who should get this. Joki maybe? Hard to tell where the problem is 
without more investigation

Comment 12

[saari (gone)]

The broken bits seem to have fixed themselves, marking works for me

Comment 13

[ckritzer (gone)]

Sorry dudes, this is still not working correctly.

The Clear and Reset buttons seem to have no effect.  
The TextArea (Input Events[3]) shows extra extra linefeeds/carriage returns are
being put in (seemingly randomly).

Comment 14

[saari (gone)]

I only do eyes, er, focus

Tossing to buster on a hunch that it is the text area that is failing to clear when told to.

Comment 15

[buster]

it looks like we get an exponential number of newlines in the text area for 
every widget message that is appended there.
see nsGfxTextControlFrame::SetTextControlFrameState(), especially the line:

  nsresult result = mEditor->OutputToString(currentValue, format, 0);

It looks like every time through this code, a newline gets appended after every 
pre-existing newline by the output system.  

After a pretty small number of such messages, you get an apparent hang as the 
editor code processes thousands of newlines per message.

Comment 16

[Kathleen :Brade]

M14

Comment 17

[Akkana Peck]

Is there some way you can find out what the dom tree looks like that the editor
is trying to print?  E.g. get it to call DebugDumpContent()?  The output system
shouldn't be adding extra newlines if the output flags are zero, and it would be
useful to know whether there were any newlines in the content model.

Also cc'ing Charley because he just mentioned to me that there's a separate bug
on not being able to clear the contents of a text field; maybe that part of this
bug is a dup.  Charley, what's that bug #?

Comment 18

[Charles Manske]

The bug Akkana requests is 27835

Comment 19

[Akkana Peck]

I don't see these exponential numbers of newlines, but I do see two newlines
being added after every line that goes into the text area.  These double
newlines are going in because there are two breaks in the editor's content.  I
put a call to mEditor->DumpContentTree(); and a line that prints the result of
OutputToString into nsGfxTextControlFrame::SetTextControlFrameState, and this is
the sort of output I got:

nsGfxTextControlFrame::SetTextControlFrameState: dumping tree!
html@0x866f2cc refcount=22<
  head@0x866f30c refcount=39<
  >
  body@0x866f34c style=font-family: monospace; white-space: pre;  refcount=70<
    Text@0x84ce840 refcount=11<Focus: browser (nn)>
    br@0x85118fc _moz_dirty= refcount=5<>
    br@0x84d51e4 _moz_dirty= refcount=7<>
    Text@0x84d54a0 refcount=11<Click: browser (nn)>
    br@0x84d54f4 _moz_dirty= refcount=6<>
    br@0x859d744 _moz_dirty= refcount=7<>
    Text@0x859d900 refcount=11<Blur: browser (nn)>
    br@0x859dc84 _moz_dirty= refcount=6<>
    br@0x859d864 _moz_dirty= refcount=7<>
    Text@0x859d898 refcount=11<Focus: browser (nn)>
    br@0x84d4e94 _moz_dirty= refcount=6<>
    br@0x851193c _moz_dirty= type=_moz refcount=11<>
  >
>
OutputToString returned: 'Focus: browser (nn)

Click: browser (nn)

Blur: browser (nn)

Focus: browser (nn)

'
Looks right to me.  Maybe I'm not understanding the bug buster is seeing, or how
to reproduce it?  Sending it back; if there's some specific way to get these
exponential added newlines, let me know (or, ideally, add in the DumpContentTree
and see whether they're really in the tree vs. being added by the output system).

Comment 20

[buster]

akkana:  I'm about to attach the (hand-edited) output from some debug print code 
I added.  It shows lots of extra content with the pattern:
    br@031963AC _moz_dirty= refcount=5<>
    Text@03197BD0 refcount=10<\r>
being added after every round trip through the editor.
Bounce back to you...
It looks like maybe the InsertText code is adding BR's for text of value "\r", 
or is it the output system that is generating these?  I'd have to look at the 
javascript, but I'll bet what it's doing is getting the current value of the 
text area, and appending some more text to it, then setting the result as the 
value of the text area.

Comment 21

[buster]

Attachment: some hand-annotated debug output that akkana requested

Comment 22

[Akkana Peck]

Changing milestone since this isn't marked beta1.  Changing summary to reflect
the bug into which this has morphed, which has nothing to do with the original
topic.  

If this is an \r issue, then it's probably Windows-only, and I won't be able to
see it on Linux.  But where are those \r's coming from?  \r is not a legal DOM
character, and we should never be inserting it.  Why are we?

I'm not sure what the editor does with a \r character.  In the text edit rules,
I don't see any special code to filter out returns, so I suppose we'll just
insert it (which we probably shouldn't, since it's never supposed to make it
into the dom).  Cc'ing Joe in case he knows, and Simon since he did some work on
line break characters vs. form submission.

Steve, could you possibly let me know who's calling InsertText with a \r, and
why it's passing those in?

Comment 23

[buster]

(cc'ing vidur and joki, since this might be a DOM issue)

see the URL on marvin.  looking at the test case, the interesting javascript is 
this:

function report(element, event) 
{
    var t = element.form.textarea;
    var sEName = element.name;
    if ((element.type == "select-one") || (element.type == "select-multiple")){
        value = " ";
        for(var i = 0; i < element.options.length; i++)
            if (element.options[i].selected) 
                value += element.options[i].value + " ";
    }
    else if (element.type == "textarea") value = "...";
    else value = element.value;
    var msg = event + ": " + sEName + ' (' + value + ')\n';
    t.value = t.value + msg;
}

the last line, "t.value = t.value + msg" is the line that triggers the debug 
output I attached.  I don't see any explicit use of "\r"  Maybe some code 
somewhere is translating the newlines inappropriately, either in javascript 
land, the text control, or the editor?

The string that is passed to nsGfxTextControlFrame::SetTextControlFrameState() 
ends in 0x0A.  I don't know if that's a \n or a \r, I can never remember.  I 
think it's a \r.
Anyway, the memory dump for the first call to SetTextControlFrameState(aValue) 
is
aValue =
0314CA20  46 6F 63 75 73  Focus
0314CA25  3A 20 70 61 73  : pas
0314CA2A  73 77 6F 72 64  sword
0314CA2F  20 28 29 0A 00   ()..

with this stack:
nsGfxTextControlFrame::SetTextControlFrameState(const nsString & {"Focus: 
password ()
"}) line 1356
nsGfxTextControlFrame::SetProperty(nsGfxTextControlFrame * const 0x0132c854, 
nsIPresContext * 0x02e94f10, nsIAtom * 0x01c9a690 {"value"}, const nsString & 
{"Focus: password ()
"}) line 1453
nsHTMLTextAreaElement::SetValue(nsHTMLTextAreaElement * const 0x02ea0d50, const 
nsString & {"Focus: password ()
"}) line 392
SetHTMLTextAreaElementProperty(JSContext * 0x02dd1490, JSObject * 0x02509a38, 
long -21, long * 0x0012d828) line 475
js_SetProperty(JSContext * 0x02dd1490, JSObject * 0x02509a38, long 37390992, 
long * 0x0012d828) line 2058 + 139 bytes
js_Interpret(JSContext * 0x02dd1490, long * 0x0012d9bc) line 2259 + 1353 bytes
js_Invoke(JSContext * 0x02dd1490, unsigned int 2, unsigned int 0) line 681 + 13 
bytes
js_Interpret(JSContext * 0x02dd1490, long * 0x0012e264) line 2292 + 15 bytes
js_Invoke(JSContext * 0x02dd1490, unsigned int 1, unsigned int 2) line 681 + 13 
bytes
js_InternalInvoke(JSContext * 0x02dd1490, JSObject * 0x025099f0, long 38835944, 
unsigned int 0, unsigned int 1, long * 0x0012e3f0, long * 0x0012e39c) line 754 + 
19 bytes
JS_CallFunctionValue(JSContext * 0x02dd1490, JSObject * 0x025099f0, long 
38835944, unsigned int 1, long * 0x0012e3f0, long * 0x0012e39c) line 2790 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x02dd44b0, void * 0x025099f0, 
void * 0x025096e8, unsigned int 1, void * 0x0012e3f0, int * 0x0012e3ec) line 562 
+ 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x03187524) line 128 + 57 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x02eb9c70, 
nsIDOMEvent * 0x03187524, unsigned int 1, unsigned int 7) line 697 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02e94f10, nsEvent * 
0x0012e990, nsIDOMEvent * * 0x0012e7e8, unsigned int 7, nsEventStatus * 
0x0012e9b4) line 1105 + 29 bytes
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x02e94f10, nsEvent * 
0x0012e990, nsIDOMEvent * * 0x0012e7e8, unsigned int 1, nsEventStatus * 
0x0012e9b4) line 1010
nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x02e9f5a0, 
nsIPresContext * 0x02e94f10, nsEvent * 0x0012e990, nsIDOMEvent * * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012e9b4) line 833 + 31 bytes
nsEventStateManager::SendFocusBlur(nsEventStateManager * const 0x02ecde10, 
nsIPresContext * 0x02e94f10, nsIContent * 0x02e9f5a0) line 2374
nsEventStateManager::SetContentState(nsEventStateManager * const 0x02ecde10, 
nsIContent * 0x02e9f5a0, int 2) line 2158
nsHTMLInputElement::SetFocus(nsHTMLInputElement * const 0x02e9f5a8, 
nsIPresContext * 0x02e94f10) line 717
nsEventStateManager::ChangeFocus(nsIContent * 0x02e9f5a0, nsIFrame * 0x0132c60c, 
int 1) line 1739
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x02ecde10, 
nsIPresContext * 0x02e94f10, nsGUIEvent * 0x0012ed0c, nsIFrame * 0x0132c60c, 
nsEventStatus * 0x0012ed4c, nsIView * 0x030012f0) line 880
nsEnderEventListener::DispatchMouseEvent(nsIDOMMouseEvent * 0x03185384, int 302) 
line 3909 + 43 bytes
nsEnderEventListener::MouseDown(nsIDOMEvent * 0x03185384) line 3981 + 24 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02ef0680, nsEvent * 
0x0012f308, nsIDOMEvent * * 0x0012f018, unsigned int 2, nsEventStatus * 
0x0012f508) line 757 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x02ef0d10, nsIPresContext * 
0x02ef0680, nsEvent * 0x0012f308, nsIDOMEvent * * 0x0012f018, unsigned int 2, 
nsEventStatus * 0x0012f508) line 2474
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x02ef0680, nsEvent * 
0x0012f308, nsIDOMEvent * * 0x0012f018, unsigned int 2, nsEventStatus * 
0x0012f508) line 1027 + 39 bytes
nsHTMLHtmlElement::HandleDOMEvent(nsHTMLHtmlElement * const 0x02ef0a3c, 
nsIPresContext * 0x02ef0680, nsEvent * 0x0012f308, nsIDOMEvent * * 0x0012f018, 
unsigned int 2, nsEventStatus * 0x0012f508) line 191
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x02ef0680, nsEvent * 
0x0012f308, nsIDOMEvent * * 0x0012f018, unsigned int 2, nsEventStatus * 
0x0012f508) line 1020 + 39 bytes
nsHTMLBodyElement::HandleDOMEvent(nsHTMLBodyElement * const 0x02ef095c, 
nsIPresContext * 0x02ef0680, nsEvent * 0x0012f308, nsIDOMEvent * * 0x0012f018, 
unsigned int 2, nsEventStatus * 0x0012f508) line 715
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x02ef0680, nsEvent * 
0x0012f308, nsIDOMEvent * * 0x0012f018, unsigned int 1, nsEventStatus * 
0x0012f508) line 1020 + 39 bytes
nsHTMLBRElement::HandleDOMEvent(nsHTMLBRElement * const 0x0300351c, 
nsIPresContext * 0x02ef0680, nsEvent * 0x0012f308, nsIDOMEvent * * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012f508) line 218
PresShell::HandleEvent(PresShell * const 0x02ff2dc4, nsIView * 0x030023e0, 
nsGUIEvent * 0x0012f308, nsEventStatus * 0x0012f508) line 2945 + 39 bytes
nsView::HandleEvent(nsView * const 0x030023e0, nsGUIEvent * 0x0012f308, unsigned 
int 8, nsEventStatus * 0x0012f508, int & 0) line 799
nsView::HandleEvent(nsView * const 0x03001250, nsGUIEvent * 0x0012f308, unsigned 
int 8, nsEventStatus * 0x0012f508, int & 0) line 784
nsView::HandleEvent(nsView * const 0x030012f0, nsGUIEvent * 0x0012f308, unsigned 
int 8, nsEventStatus * 0x0012f508, int & 0) line 784
nsView::HandleEvent(nsView * const 0x02ff11f0, nsGUIEvent * 0x0012f308, unsigned 
int 28, nsEventStatus * 0x0012f508, int & 0) line 784
nsViewManager::DispatchEvent(nsViewManager * const 0x02ff1470, nsGUIEvent * 
0x0012f308, nsEventStatus * 0x0012f508) line 1704
nsGfxTextControlFrame::RedispatchMouseEventToSubDoc(nsGfxTextControlFrame * 
const 0x0132c60c, nsIPresContext * 0x02e94f10, nsGUIEvent * 0x0012f4c8, 
nsEventStatus * 0x0012f508, int 1) line 725 + 43 bytes
nsGfxTextControlFrame::HandleEvent(nsGfxTextControlFrame * const 0x0132c60c, 
nsIPresContext * 0x02e94f10, nsGUIEvent * 0x0012f4c8, nsEventStatus * 
0x0012f508) line 557 + 29 bytes
nsEnderEventListener::DispatchMouseEvent(nsIDOMMouseEvent * 0x03183504, int 302) 
line 3903 + 32 bytes
nsEnderEventListener::MouseDown(nsIDOMEvent * 0x03183504) line 3981 + 24 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x02ef0680, nsEvent * 
0x0012fac4, nsIDOMEvent * * 0x0012f784, unsigned int 2, nsEventStatus * 
0x0012f9d0) line 757 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x02ef0d10, nsIPresContext * 
0x02ef0680, nsEvent * 0x0012fac4, nsIDOMEvent * * 0x0012f784, unsigned int 2, 
nsEventStatus * 0x0012f9d0) line 2474
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x02ef0680, nsEvent * 
0x0012fac4, nsIDOMEvent * * 0x0012f784, unsigned int 2, nsEventStatus * 
0x0012f9d0) line 1027 + 39 bytes
nsHTMLHtmlElement::HandleDOMEvent(nsHTMLHtmlElement * const 0x02ef0a3c, 
nsIPresContext * 0x02ef0680, nsEvent * 0x0012fac4, nsIDOMEvent * * 0x0012f784, 
unsigned int 2, nsEventStatus * 0x0012f9d0) line 191
nsGenericElement::HandleDOMEvent(nsIPresContext * 0x02ef0680, nsEvent * 
0x0012fac4, nsIDOMEvent * * 0x0012f784, unsigned int 1, nsEventStatus * 
0x0012f9d0) line 1020 + 39 bytes
nsHTMLBodyElement::HandleDOMEvent(nsHTMLBodyElement * const 0x02ef095c, 
nsIPresContext * 0x02ef0680, nsEvent * 0x0012fac4, nsIDOMEvent * * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012f9d0) line 715
PresShell::HandleEvent(PresShell * const 0x02ff2dc4, nsIView * 0x030023e0, 
nsGUIEvent * 0x0012fac4, nsEventStatus * 0x0012f9d0) line 2945 + 39 bytes
nsView::HandleEvent(nsView * const 0x030023e0, nsGUIEvent * 0x0012fac4, unsigned 
int 8, nsEventStatus * 0x0012f9d0, int & 0) line 799
nsView::HandleEvent(nsView * const 0x03001250, nsGUIEvent * 0x0012fac4, unsigned 
int 8, nsEventStatus * 0x0012f9d0, int & 0) line 784
nsView::HandleEvent(nsView * const 0x030012f0, nsGUIEvent * 0x0012fac4, unsigned 
int 8, nsEventStatus * 0x0012f9d0, int & 0) line 784
nsView::HandleEvent(nsView * const 0x02ff11f0, nsGUIEvent * 0x0012fac4, unsigned 
int 28, nsEventStatus * 0x0012f9d0, int & 0) line 784
nsViewManager::DispatchEvent(nsViewManager * const 0x02ff1470, nsGUIEvent * 
0x0012fac4, nsEventStatus * 0x0012f9d0) line 1704
HandleEvent(nsGUIEvent * 0x0012fac4) line 69
nsWindow::DispatchEvent(nsWindow * const 0x03001134, nsGUIEvent * 0x0012fac4, 
nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fac4) line 514
nsWindow::DispatchMouseEvent(unsigned int 302, nsPoint * 0x00000000 {x=??? 
y=???}) line 2957 + 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 302, nsPoint * 0x00000000 {x=??? 
y=???}) line 3175
nsWindow::ProcessMessage(unsigned int 513, unsigned int 1, long 655391, long * 
0x0012fd60) line 2238 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x0252073c, unsigned int 513, unsigned int 1, long 
655391) line 671 + 27 bytes

the memory dump of aValue for the second call is:  
0x0012d47c
0012D490  94 D4 12 00 46  番..F
0012D495  00 6F 00 63 00  .o.c.
0012D49A  75 00 73 00 3A  u.s.:
0012D49F  00 20 00 70 00  . .p.
0012D4A4  61 00 73 00 73  a.s.s
0012D4A9  00 77 00 6F 00  .w.o.
0012D4AE  72 00 64 00 20  r.d. 
0012D4B3  00 28 00 29 00  .(.).
0012D4B8  0D 00 0A 00 0D  .....
0012D4BD  00 0A 00 53 00  ...S.
0012D4C2  65 00 6C 00 65  e.l.e
0012D4C7  00 63 00 74 00  .c.t.
0012D4CC  3A 00 20 00 70  :. .p
0012D4D1  00 61 00 73 00  .a.s.
0012D4D6  73 00 77 00 6F  s.w.o
0012D4DB  00 72 00 64 00  .r.d.
0012D4E0  20 00 28 00 29   .(.)
0

Comment 24

[Akkana Peck]

(Reducing severity, since this has morphed into something very different from
the original bug.)

I talked this over with Joe and Simon, and the consensus was that the editor
should assume that it will not be passed illegal input (\r is an illegal
character in the dom) because having to search for and remove all \r characters
is an extra performance hit in InsertText, a method which is already a
performance bottleneck for several operations.

So code somewhere else needs to be responsible for stripping out any illegal
characters before calling editor routines.  In this case,
nsGfxTextControlFrame::SetTextControlFrameState should strip out the \r
characters before calling htmlEditor->InsertText.

That's easy enough to do, either by extending the existing method RemoveNewlines
to take a flag indicating whether to remove LF as well as CR and NUL, or by
adding a new method.

Comment 25

[Akkana Peck]

Does this patch help?  (I'll try it tomorrow if I get a good windows build.)

Note, it also include warning fixes.

Comment 26

[Akkana Peck]

Attachment: Patch to strip returns before sending text to the editor

Comment 27

[Akkana Peck]

The fix is checked in.  My windows build failed; I hope someone with a windows
build can check this.

Comment 28

[Eric Pollmann]

See also bug 22983.  This was PDT+ and sounds just like this one.  (I was not
able to reproduce it) Maybe this fix should be pulled over onto the branch?

Comment 29

[Akkana Peck]

*** Bug 31699 has been marked as a duplicate of this bug. ***

Comment 30

[Eric Pollmann]

On further inspection, bug 22983 seems to be a separate issue involving hidden
inputs.  If it turns out they are related, I'll note that on this bug.

Comment 31

[Eric Pollmann]

*** Bug 28778 has been marked as a duplicate of this bug. ***

Comment 32

[Dwayne]

Build 2000-04-13-08
WinNT 4.0, SP6a

Please reopen.  Data is lost altogether on return.  Noticeable in the last
couple weeks of builds.

Comment 33

[Akkana Peck]

Please explain what problem you're seeing ... or, better yet, file a new bug.
This bug has become so overloaded that it's virtually useless for tracking
anything now.

Comment 34

[Loco]

Updating QA Contact.

Comment 35

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 36

[Madhur Bhatia]

QA contact updated

Comment 37

[luis rincon]

verified on build 2001-07-16-07-trunk