Closed Bug 53676 Opened 24 years ago Closed 24 years ago

multiline textfield with lots/large of content (assigned through XPCOM) is really slow and uses 100% CPU

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 51938

People

(Reporter: arthur.barrett, Assigned: joki)

Details

(Keywords: perf, Whiteboard: [nsbeta3-])

Attachments

(5 files)

XUL part of test set
1.72 KB, text/xml
Details
JavaScript part of test set
1.07 KB, text/plain
Details
an example result set cut from the multiline textfield
73.66 KB, text/plain
Details
A better test set, press test, then when complete, try moving around with the mouse.... For a more excessive version change the internal javascript to count >500 lines....
1.59 KB, text/xml
Details
Simple HTML TextArea test case.
74.56 KB, text/html
Details
I cant create a simple test set, but I'm calling XPCOM (blackconnect to Java) to get rows from a database table using JDBC/Oracle. Javascript fills up a textfield with the results. When I then click on the multiline textfield and scroll etc, CPU usage goes 100% and it is really really slow. I'll attach a result set (cut and pasted, but I tried pasting it back in and performance problem did not occur), and the XUL and JS.
Attached file XUL part of test set —
Is this problem unique to XUL? Or is it a problem with multiline fields in HTML, as well? If the latter, component should be "HTML Form Controls".
cc beppe
Seems to be either textfield multiline=true or textarea, so remarking as HTML form control. A little futher info, seems to be related to having 2 multiline text fields on the screen (or in the attached case 1 multiline text field and one html:textarea. The newly attached XUL has a test button which loads 250 lines of data into each multiline textfield/textarea. When you move around with the mouse you can notice the excessive CPU usage compared to using cursor. To really see it slow down, up the number of lines produced to 500 or 1000 (but the javascript takes a LONG time to build it....). This is tested on Windows NT 4.0 SP4 with a mozilla build from the tree arounds the 15/16 sep 2000.
Component: XP Toolkit/Widgets → HTML Form Controls
reassigning to component owner
Assignee: trudelle → rods
QA Contact: jrgm → ckritzer
editor team has two open issues in regards to generated data in form elements through js, they have both been futured -- see bugs 38196 and 33014
So I took the contents of the 09/21/00 21:01 attatchment and put it in a simple testcase which looked something like: <html><body><form><textarea>[Attatchment Text]</textarea></body></html> And played around with selection autoscrolling. Selection seems a bit slow inside of the textarea, and even slower when selection autoscrolling starts (when the mouse leaves the window while your mouse button is still down). Breaking in the debugger when it was slow revealed that we are calling into the XIF code to write out the contents of the textarea because a BLUR event was received. This shouldn't be happening because the textarea should still have focus. Cc'ing saari@netscape.com and myself. Here's the stack trace generated when I broke into the debugger: getter_AddRefs(nsCOMPtr<nsIContent> & {...}) line 985 nsRange::IndexOf(nsIDOMNode * 0x036fb560) line 689 + 13 bytes GetNodeBracketPoints(nsIContent * 0x036fb568, nsCOMPtr<nsIDOMNode> * 0x0012de34, int * 0x0012de3c, int * 0x0012de40) line 268 + 14 bytes IsNodeIntersectsRange(nsIContent * 0x036fb568, nsIDOMRange * 0x049a6ab0) line 126 + 21 bytes nsDOMSelection::ContainsNode(nsDOMSelection * const 0x049a6a40, nsIDOMNode * 0x036fb560, int 1, int * 0x0012dee4) line 5614 + 23 bytes nsHTMLDocument::IsInSelection(nsISelection * 0x049a6a40, const nsIContent * 0x036fb568) line 4193 nsGenericDOMDataNode::ConvertContentToXIF(const nsIContent * 0x036fb568, nsIXIFConverter * 0x049a64f0) line 565 + 71 bytes nsTextNode::ConvertContentToXIF(const nsTextNode * const 0x036fb568, nsIXIFConverter * 0x049a64f0) line 59 + 48 bytes nsDocument::BeginConvertToXIF(nsIXIFConverter * 0x049a64f0, nsIDOMNode * 0x036fb560) line 3326 nsDocument::ToXIF(nsDocument * const 0x039ec820, nsIXIFConverter * 0x049a64f0, nsIDOMNode * 0x036fb560) line 3374 nsDocument::ConvertChildrenToXIF(nsIXIFConverter * 0x049a64f0, nsIDOMNode * 0x0366e080) line 3338 + 28 bytes nsDocument::ToXIF(nsDocument * const 0x039ec820, nsIXIFConverter * 0x049a64f0, nsIDOMNode * 0x0366e080) line 3375 nsDocument::CreateXIF(nsDocument * const 0x039ec820, basic_nsAWritableString<unsigned short> & {...}, nsISelection * 0x049a6a40) line 3517 + 33 bytes nsTextEncoder::EncodeToString(nsTextEncoder * const 0x049a6830, basic_nsAWritableString<unsigned short> & {...}) line 192 nsDOMSelection::ToStringWithFormat(nsDOMSelection * const 0x049a6a44, const char * 0x049a68b0, unsigned int 1049, int 40, unsigned short * * 0x0012eaa4) line 1610 + 42 bytes nsHTMLEditor::OutputToString(nsHTMLEditor * const 0x0366ccb0, basic_nsAWritableString<unsigned short> & {...}, const basic_nsAReadableString<unsigned short> & {...}, unsigned int 1048) line 5842 + 60 bytes nsGfxTextControlFrame2::GetTextControlFrameState(basic_nsAWritableString<unsigne d short> & {...}) line 2977 + 56 bytes nsGfxTextControlFrame2::GetProperty(nsGfxTextControlFrame2 * const 0x00fb5f58, nsIAtom * 0x01ab79c0, basic_nsAWritableString<unsigned short> & {...}) line 2359 nsHTMLTextAreaElement::GetValue(nsHTMLTextAreaElement * const 0x0364fb30, basic_nsAWritableString<unsigned short> & {...}) line 358 nsGfxTextControlFrame2::GetText(nsGfxTextControlFrame2 * const 0x00fb5ed8, nsString * 0x0012ec54, int 0) line 2787 + 19 bytes nsTextInputListener::Blur(nsIDOMEvent * 0x049a6b14) line 397 nsEventListenerManager::HandleEvent(nsIPresContext * 0x04b30cc0, nsEvent * 0x0012f474, nsIDOMEvent * * 0x0012f0a0, nsIDOMEventTarget * 0x03668c74, unsigned int 7, nsEventStatus * 0x0012f498) line 1180 + 23 bytes nsGenericElement::HandleDOMEvent(nsIPresContext * 0x04b30cc0, nsEvent * 0x0012f474, nsIDOMEvent * * 0x0012f0a0, unsigned int 1, nsEventStatus * 0x0012f498) line 1407 nsHTMLTextAreaElement::HandleDOMEvent(nsHTMLTextAreaElement * const 0x0364fb3c, nsIPresContext * 0x04b30cc0, nsEvent * 0x0012f474, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus * 0x0012f498) line 568 + 31 bytes nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x03645448, nsIPresContext * 0x04b30cc0, nsEvent * 0x0012f854, nsIFrame * 0x00fadc8c, nsEventStatus * 0x0012f7bc, nsIView * 0x03658960) line 561 PresShell::HandleEventInternal(nsEvent * 0x0012f854, nsIView * 0x03658960, unsigned int 1, nsEventStatus * 0x0012f7bc) line 4249 + 43 bytes PresShell::HandleEvent(PresShell * const 0x03624204, nsIView * 0x03658960, nsGUIEvent * 0x0012f854, nsEventStatus * 0x0012f7bc, int 0, int & 1) line 4190 + 25 bytes nsView::HandleEvent(nsView * const 0x03658960, nsGUIEvent * 0x0012f854, unsigned int 8, nsEventStatus * 0x0012f7bc, int 0, int & 1) line 379 nsView::HandleEvent(nsView * const 0x0365b470, nsGUIEvent * 0x0012f854, unsigned int 8, nsEventStatus * 0x0012f7bc, int 0, int & 1) line 352 nsView::HandleEvent(nsView * const 0x03627b90, nsGUIEvent * 0x0012f854, unsigned int 28, nsEventStatus * 0x0012f7bc, int 1, int & 1) line 352 nsViewManager2::DispatchEvent(nsViewManager2 * const 0x03627d70, nsGUIEvent * 0x0012f854, nsEventStatus * 0x0012f7bc) line 1429 HandleEvent(nsGUIEvent * 0x0012f854) line 68 nsWindow::DispatchEvent(nsWindow * const 0x0365fda4, nsGUIEvent * 0x0012f854, nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f854) line 702 nsWindow::DispatchFocus(unsigned int 108) line 4039 + 15 bytes nsWindow::ProcessMessage(unsigned int 8, unsigned int 0, long 0, long * 0x0012fb98) line 3099 + 19 bytes nsWindow::WindowProc(HWND__ * 0x00c608fa, unsigned int 8, unsigned int 0, long 0) line 950 + 27 bytes USER32! 77e71303() USER32! 77e71962() NTDLL! 77f763ef() USER32! 77e71a89() nsAppShell::Run(nsAppShell * const 0x00af9e70) line 96 + 24 bytes nsAppShellService::Run(nsAppShellService * const 0x00afb130) line 408 main1(int 1, char * * 0x00a23050, nsISupports * 0x00000000) line 1004 + 32 bytes main(int 1, char * * 0x00a23050) line 1185 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77f1b9ea()
bah ... forgot to Cc saari@netscape.com. Marking NEW since I see the slowness too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Wow, if I set the following pref to false in my prefs.js file, things get alot more zippy: user_pref("nglayout.events.showHierarchicalHover", false); Looks like this code was turned on by joki@netscape.com on Sept 14th. Reassigning to joki. Cc nisheeth.
Assignee: rods → joki
keywords
Keywords: nsbeta3, perf
No such luck. Seems to make no difference to me. I also tried putting printf("blah"); on all the occurences of ::Blur in mozilla/layout and dont see to get any messages during the troublesome moments. I have observed that even passing the mouse cursor over the multiline text field causes the CPU usage to jump to 100%. So I assume it must be SOME event.... Maybe you should create a new bug number for the other one?
Mousing over window contents using 100% of the CPU sounds a lot like bug 51938.
Updating QA contact.
QA Contact: ckritzer → bsharma
Running my test set, nsFrame::GetFrameForPoint() is certainly being called LOTS during the 100% CPU. Blur is not called at all. So I think that my original bug is a dup of 51938. Any other bugs should probably recieve their own number now. If noone votes to the contrary I will mark it as dup tomorrow.
Looks like the blur call was not a bug ... at the time, I was noticing that it was taking several seconds between caret placements and dragging, I tried to click in the VC++ menus to force a break to see what was going on, but I guess by the time VC++ came to the foreground and allowed me to select "Break", the caret had already been moved, so it had time to fire off a blur event. I still see a huge improvement in responsiveness when selecting and selection autoscrolling in the sample I posted earlier when I set the following pref: user_pref("nglayout.events.showHierarchicalHover", false); I'm using WinNt 4.0 Sp5 on a 450Mhz PC. I hear they are going to make "false" the current setting while they do some further investigation.
Marking nsbeta3- and nominating for rtm
Keywords: rtm
Whiteboard: [nsbeta3-]
The showHierarchicalHover pref has been turned off by default in the 9/27 build onwards.
I'm convinced, dup of 51938 as per my comments yesterday. *** This bug has been marked as a duplicate of 51938 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: