Open Bug 561578 Opened 14 years ago Updated 2 years ago

100 % CPU for several minutes when resizing textarea with large amount of text

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Platform:
x86
All
Type:
defect

Tracking

()

People

(Reporter: fehe, Unassigned)

References

(Depends on 1 open bug, Blocks 2 open bugs,
URL
)

Details

(Keywords: hang, perf)

Attachments

(3 files, 1 obsolete file)

test case
1.93 MB, text/html
Details
WinDBG log of hang (breaking 2.5 minutes into hang)
82.32 KB, text/plain
Details
What I have thus far
8.07 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100424 Minefield/3.7a5pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100424 Minefield/3.7a5pre

Bug 532998 fixed an issue related to the linked URL; however, a significant problem remains: specifically, resizing the textarea results in a high-CPU hang, for several minutes, before the resize operation is completed.

Click the gripper and resize the textarea to cover as much of the page content area as possible.  Firefox hangs for several minutes, consuming 100 % CPU.  The larger the resize, the longer then hang.  Even resizing to only about 4x4 inches results in several minutes of 100 % CPU utilization on my 933 MHz P3.

I tried disabling spell checking to eliminate that as a possible cause.  Hang is independent of whether spelll checker is enabled or disabled.

I'm thinking the cause is what ROC discribed in bug 532998 comment 12.  If so, is there some way to fix this by maybe not hunting for "\n"?


Reproducible: Always
Attached file test case — 

    
  
Keywords: hang, 
          
            perf
Version: unspecified → Trunk

    
    

    
  
Seeing this with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100424 Minefield/3.7a5pre ID:20100424040157
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All

    
    

    
  
I can't reproduce this on Mac trunk from today.  Resize takes < 1 second....

Is this bug Windows-only?

    
    

    
  
Can't repro this on Windows 7 x64.  Using latest hourly btw.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100427 Minefield/3.7a5pre - Build ID: 20100427120509

    
    

    
  
Hardlocks on 3.6.3 on my work machine using the test case in comment #1

Intel Core2 Quad CPU
Q9400 2.66ghz
3.23gb RAM
WinXP SP3

    
    

    
  
Didn't see the URL. The only thing I see is that the mouse pointer is way ahead of he resizing gripper.  Probably because there is some much data. But I see no hangs or high CPU usage.

OOPP, dw/d2d enabled.

    
    

    
  
(In reply to comment #5)
> Hardlocks on 3.6.3 on my work machine using the test case in comment #1

Must be tested with Trunk, because there's a patch that fixed an original hanging issue.

    
    

    
  
(In reply to comment #2)
> Seeing this with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre)
> Gecko/20100424 Minefield/3.7a5pre ID:20100424040157

What is your CPU and Windows architecture (32-bit or 64-bit)?

    
    

    
  
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100427 Minefield/3.7a5pre ID:20100427030742

on an ancient pc with slow HD and low memory, running ubuntu lucid beta.
tooks a few secs to resize to near full screen

    
    

    
  
(In reply to comment #9)
> on an ancient pc with slow HD and low memory, running ubuntu lucid beta.
> tooks a few secs to resize to near full screen

Define ancient.  Do you know what processor it has? i686 is very broad and includes current architectures.

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100427 Minefield/3.7a5pre

Seeing this on Windows 7 x64, running a Core 2 Duo @ 2GHz.

Resizing the textarea to a large size causes the browser to lock up for 10-15 seconds, with firefox.exe at 50% CPU usage (using a single core out of two). Also, closing the tab and then doing an undo-close-tab causes the browser to lock up for 5-10 seconds.

D2D/DW enabled.

    
    

    
  
Does anyone know how to run the debug builds on Windows?  

The last time I ran into an issue like this, where the Firefox slowness issue wasn't experienced by everyone, it was because of assertions.

I have downloaded the latest debug build, corresponding symbols, and the language pack; however, I can't find documentation on what to do with it all.  I end up with the error message, "This application has failed to start because the application configuration is incorrect."

    
    

    
  
(In reply to comment #10)
> (In reply to comment #9)
> > on an ancient pc with slow HD and low memory, running ubuntu lucid beta.
> > tooks a few secs to resize to near full screen
> 
> Define ancient.  Do you know what processor it has? i686 is very broad and
> includes current architectures.

Pentium 4, 1.8GHz, 512MB RAM; circa 2001

    
    

    
  
(In reply to comment #13)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > on an ancient pc with slow HD and low memory, running ubuntu lucid beta.
> > > tooks a few secs to resize to near full screen
> > 
> > Define ancient.  Do you know what processor it has? i686 is very broad and
> > includes current architectures.
> 
> Pentium 4, 1.8GHz, 512MB RAM; circa 2001

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100427 Minefield/3.7a5pre ID:20100427040158

On same system with XP SP3 booted, and took over 2 minutes rather than a few seconds.

    
    

    
  
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #10)
> > Pentium 4, 1.8GHz, 512MB RAM; circa 2001
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100427
> Minefield/3.7a5pre ID:20100427040158
> 
> On same system with XP SP3 booted, and took over 2 minutes rather than a few
> seconds.

Thanks.  That at least confirms what I'm experiencing with XP.

@Tyler Downer: Are you running 32-bit or 64-bit Windows 7 and how long is the delay you experience?

Unless those experiencing this issue on Windows 7 can confirm that they experience delay approaching at least 1 minute, I will change "Platform" to x86 Windows XP, since it is reproducible there and will help the devs focus on a platform where they can see the issue.

    
    

    
  
I'm running x64, and I'm actually getting a very long hang, like, long enough that windows steps in and asks to close firefox. I have not tried in a new profile yet, I will do that soon.

    
    

    
  
"very long hang" is still too arbitrary.  Is there anyway you could time it?  I'm not familiar with what Windows 7 does, but Windows XP will report a program as not responding even within a few seconds, if one tries to interact with it.

    
    

    
  
OK.  This business of people with the same software and similar hardware seeing totally different things is ... confusing.  ;)

For people who are seeing the problem: what happens if you set the "accessibility.win32.force_disabled" preference to false?

    
    

    
  
(In reply to comment #18)
> OK.  This business of people with the same software and similar hardware seeing
> totally different things is ... confusing.  ;)

That's why I want to set platform to Windows XP.  It's so far consistent on that platform.

> For people who are seeing the problem: what happens if you set the
> "accessibility.win32.force_disabled" preference to false?

It's already false.  Toggling to true makes no difference.

    
    

    
  
> It's so far consistent on that platform.

Yes, but it sounds like on Win7 some people are seeing it and some not.  Or did I misunderstand?

> It's already false.  Toggling to true makes no difference.

Er, I meant "set to true".  I assume you restarted the browser after doing that?

    
    

    
  
(In reply to comment #20)
> Yes, but it sounds like on Win7 some people are seeing it and some not.  Or did
> I misunderstand?

I figure, go with the sure bet and hopefully it fixes it for Win 7 users too.

> Er, I meant "set to true".  I assume you restarted the browser after doing
> that?

Not when I first tested, but I've tried again with restart and it still takes several minutes.

    
    

    
  
(In reply to comment #20)
> Yes, but it sounds like on Win7 some people are seeing it and some not.  Or did
> I misunderstand?

I am seeing this on Windows 7 using the build from 20100427. It tends to hang the browser sometimes when resizing the testcase

    
    

    
  
> I figure, go with the sure bet and hopefully it fixes it for Win 7 users too.

At the moment the bigger problem is pinning it down...  I don't suppose someone who can reproduce this is willing to do a profile using CodeAnalyst and the symbol server or something?
Keywords: qawanted

    
    

    
  
Unfortunately, I'm still in diapers and my machine is a geriatric, so I won't be of any help there.

    
    

    
  
Boris, seeing as I'm home sick all day, I might as well. However, IIRC, CodeAnalyst doesn't run on x64 very well correct?
 Some more info, with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100428 Minefield/3.7a5pre ID:20100428041827, I opened the testcase in  a fresh profile. I dragged the gripper, and got a hang and a whole core was used. Hang last roughly 25 secs, then windows stepped in and offered to close Firefox, which I did.

    
    

    
  
> However, IIRC, CodeAnalyst doesn't run on x64 very well correct?

I don't know.  I've never used it myself...

Another option here, if you grab symbols off the code server, is to just do poor-man's profiling in a debugger by stopping the program while it's acting hung and seeing what the stacks look like.  That might well be enough to at least point in the right direction.

    
    

    
  


  
Boris: will this do?

    
    

    
  
I'm not an expert on windbg output, but that seems to be missing symbols...  See, e.g.:

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for D:\firefox\xul.dll -

    
    

    
  
I went through the step to download symbols, and it downloaded them, so not sure.

    
    

    
  


  
Try this one.  I used the Apr 26 Trunk to obtain this.

        Attachment #442128 -
        Attachment is obsolete: true

    
    

    
  
That's much more like it.

Thread 0 in that last log is under nsTextControlFrame::Reflow, in particular in the nsTextFrame::GetNextInFlow call that nsLineLayout calls.

Given that, I tried running this on the testcase in this bug:

  javascript:var s = new Date, t = document.forma.area; t.style.width = t.style.height = "500px"; document.body.offsetWidth; alert((new Date)-s);

and that measures at 35s on my machine in an April 27 build, which is way slower than I remember the resize being when I made comment 3.

In any case, if it's taking 35s here, I can certainly see it taking 4x as long on a slower machine.  Profiling now.

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100428 Minefield/3.7a5pre ID:20100428041827
on XP SP3 (on same h/w) with "accessibility.win32.force_disabled" preference set to true...resize to near fullscreen was almost immediate.

    
    

    
  
Strange.  Didn't work for me.

    
    

    
  
OK, my profile of the comment 31 testcase shows me spending 95% (!) of the time in nsTextFrame::SetLength, called from nsTextFrame::Reflow.

If I believe the per-instruction info, it seems like this loop is where the time is spent, for the most part:

6046   // Our frame is growing. Take text from our in-flow(s).
6047   // We can take text from frames in lines beyond just the next line.
6048   // We don't dirty those lines. That's OK, because when we reflow
6049   // our empty next-in-flow, it will take text from its next-in-flow and
6050   // dirty that line.
6051   while (f && f->mContentOffset < end) {
6052     f->mContentOffset = end;
6053     if (f->GetTextRun() != mTextRun) {
6054       ClearTextRun();
6055       f->ClearTextRun();
6056     }
6057     f = static_cast<nsTextFrame*>(f->GetNextInFlow());
6058   }

I'm not sure I trust that, though; certainly the instruction to line# mapping seems to be pretty confused.

    
    

    
  
I'd really like to see comment 32 and comment 33 reconciled, by the way.

IU, when you stop in the debugger, what's the value of nsWindow::sIsAccessibilityOn ?

As for comment 34, over here I see lots of frames in a row all with the same mContentOffset slightly < end.  In fact, if the new width is C times the old width, then we would expect 1/C as may textframes as we had before, and the k-th frame will have to reset the mContentOffset on C*k or so frames.  So the number of iterations of this loop will be about sum_{k = 0 to N/C} (C*k) = C*(N/C)*(N/C+1)/2 or so.  Ignoring the +1 bit as not significant, this simplifies out to (N^2)/(2C).  In our case, our original N is on the order of number of lines, so about number of chars over 20 so 9*10^4 or so.  C is probably no bigger than 20, so we get about 2*10^8 iterations.  That would take 1s if each iteration takes about 10 processor cycles.  Over here I see lots of L2 misses in this loop, so it takes a lot more than 10 cycles per iteration...

This does make me wonder why the drag testcase wasn't showing the issue for me or for some others, though.

    
    

    
  
(In reply to comment #35)
> I'd really like to see comment 32 and comment 33 reconciled, by the way.
> 
> IU, when you stop in the debugger, what's the value of
> nsWindow::sIsAccessibilityOn ?

Not sure how to get what you're after.

    
    

    
  
It actually is silly to advance multiple frames to all have the same offset. Maybe we could fix it with a heuristic so that one frame gets its offset advanced to 'end', the next frame gets its offset advanced to 'end + step", then 'end + 2*step' etc (limited to the length of the text, obviously). We'd have to dirty frames as we did this. We could choose 'step' to be the number of characters in the current frame.

This is all just work-around for the brokenness of the frame continuation model, though.

    
    

    
  
Could we just destroy the nif if we took all its text?

    
    

    
  
> Not sure how to get what you're after.

In your debugger, I don't know either...  What I'm after is the value of the static sIsAccessibilityOn member of the nsWindow class.

    
    

    
  
Maybe we could. That would be scary though since in general we try not to destroy frames in the middle of a continuation chain (unless we're going to destroy all frames after it too).

    
    

    
  
(In reply to comment #39)
> What I'm after is the value of the
> static sIsAccessibilityOn member of the nsWindow class.

Tried Firebug, but still can't figure out how to get that, as I didn't see nsWindow anywhere in the function list.  Unfortunately, I'm not much use there.

    
    

    
  
> Tried Firebug,

You need to do this in the C++ debugger (WinDBG in your case, looks like).  nsWindow is a C++ class that represents native widgets on Windows.

    
    

    
  
I'm not sure I did this right, but here goes:

I issued the command "dt nswindow", which gave me:

xul!nsWindow
   +0x000 __VFN_table : Ptr32 
   +0x004 mFirstChild      : nsCOMPtr<nsIWidget>
   +0x008 mLastChild       : Ptr32 nsIWidget
   +0x00c mNextSibling     : nsCOMPtr<nsIWidget>
   +0x010 mPrevSibling     : Ptr32 nsIWidget
   +0x014 mRefCnt          : nsAutoRefCnt
   +0x018 mClientData      : Ptr32 Void
   +0x01c mEventCallback   : Ptr32     nsEventStatus 
   +0x020 mContext         : Ptr32 nsIDeviceContext
   +0x024 mToolkit         : Ptr32 nsIToolkit
   +0x028 mLayerManager    : nsRefPtr<mozilla::layers::LayerManager>
   +0x02c mBackground      : Uint4B
   +0x030 mForeground      : Uint4B
   +0x034 mCursor          : nsCursor
   +0x038 mWindowType      : nsWindowType
   +0x03c mBorderStyle     : nsBorderStyle
   +0x040 mOnDestroyCalled : UChar
   +0x041 mUseAcceleratedRendering : UChar
   +0x044 mBounds          : nsIntRect
   +0x054 mOriginalBounds  : Ptr32 nsIntRect
   +0x058 mClipRects       : nsAutoArrayPtr<nsIntRect>
   +0x05c mClipRectCount   : Uint4B
   +0x060 mZIndex          : Int4B
   +0x064 mSizeMode        : nsSizeMode
   =10b2d7dc nsBaseWidget::mLastRollup : Ptr32 nsIContent
   +0x068 mLastSize        : nsIntSize
   +0x070 mLastPoint       : nsIntPoint
   +0x078 mWnd             : Ptr32 HWND__
   +0x07c mPrevWndProc     : Ptr32     long 
   +0x080 mBrush           : Ptr32 HBRUSH__
   +0x084 mIsTopWidgetWindow : UChar
   +0x085 mHas3DBorder     : UChar
   +0x086 mInDtor          : UChar
   +0x087 mIsVisible       : UChar
   +0x088 mIsInMouseCapture : UChar
   +0x089 mUnicodeWidget   : UChar
   +0x08a mPainting        : UChar
   +0x08b mLeadByte        : Char
   +0x08c mBlurSuppressLevel : Uint4B
   +0x090 mContentType     : nsContentType
   +0x094 mMenuCmdId       : Int4B
   +0x098 mOldStyle        : Uint4B
   +0x09c mOldExStyle      : Uint4B
   +0x0a0 mOldIMC          : Ptr32 HIMC__
   +0x0a4 mIMEEnabled      : Uint4B
   +0x0a8 mNativeDragTarget : Ptr32 nsNativeDragTarget
   +0x0ac mLastKeyboardLayout : Ptr32 HKL__
   +0x0b0 mPopupType       : nsPopupType
   +0x0b4 mDisplayPanFeedback : UChar
   +0x0b8 mWindowHook      : mozilla::widget::WindowHook
   =10b2d75c nsWindow::sInstanceCount : Uint4B
   =10af3480 nsWindow::sCanQuit : TriStateBool
   =10b2d778 nsWindow::sCurrentWindow : Ptr32 nsWindow
   =10b2d764 nsWindow::sIsRegistered : Int4B
   =10b2d768 nsWindow::sIsPopupClassRegistered : Int4B
   =10b2d76c nsWindow::sIsOleInitialized : Int4B
   =10b2d770 nsWindow::sHCursor : Ptr32 HICON__
   =10b2d774 nsWindow::sCursorImgContainer : Ptr32 imgIContainer
   =10b2d760 nsWindow::sSwitchKeyboardLayout : Int4B
   =10b2d77c nsWindow::sJustGotDeactivate : Int4B
   =10b2d780 nsWindow::sJustGotActivate : Int4B
   =10af3484 nsWindow::sTrimOnMinimize : Int4B
   =10b2d7c4 nsWindow::sTrackPointHack : Int4B
   =10b2fda8 nsWindow::sOOPPPluginFocusEvent : Uint4B
   +0x0bc mIdleService     : nsCOMPtr<nsIdleService>
   =10b2d784 nsWindow::sMsgFilterHook : Ptr32 HHOOK__
   =10b2d788 nsWindow::sCallProcHook : Ptr32 HHOOK__
   =10b2d78c nsWindow::sCallMouseHook : Ptr32 HHOOK__
   =10b2c59a nsWindow::sProcessHook : UChar
   =10b2d790 nsWindow::sRollupMsgId : Uint4B
   =10b2d794 nsWindow::sRollupMsgWnd : Ptr32 HWND__
   =10b2d798 nsWindow::sHookTimerId : Uint4B
   =10b2d7a4 nsWindow::sRollupWidget : Ptr32 nsIWidget
   =10b2d7a8 nsWindow::sRollupConsumeEvent : Int4B
   =10b2d79c nsWindow::sRollupListener : Ptr32 nsIRollupListener
   =10b2d7a0 nsWindow::sMenuRollup : Ptr32 nsIMenuRollup
   =10b2d7ac nsWindow::sLastMousePoint : tagPOINT
   =10b2d7b4 nsWindow::sLastMouseMovePoint : tagPOINT
   =10b2d7bc nsWindow::sLastMouseDownTime : Int4B
   =10b2d7c0 nsWindow::sLastClickCount : Int4B
   =10b2c59b nsWindow::sLastMouseButton : UChar
   +0x0c0 mPaintDC         : Ptr32 HDC__
   +0x0c4 mD2DWindowSurface : nsRefPtr<gfxD2DSurface>
   +0x0c8 mTransparentSurface : nsRefPtr<gfxWindowsSurface>
   +0x0cc mMemoryDC        : Ptr32 HDC__
   +0x0d0 mTransparencyMode : nsTransparencyMode
   +0x0d4 mPossiblyTransparentRegion : nsIntRegion
   +0x104 mGlassMargins    : _MARGINS
   +0x118 mGesture         : nsWinGesture
   +0x150 mTaskbarPreview  : nsCOMPtr<nsIWeakReference>
   +0x154 mHasTaskbarIconBeenCreated : Int4B
   =10b2d7c8 nsWindow::sIsAccessibilityOn : Int4B
   =10b2d7cc nsWindow::sAccLib : Ptr32 HINSTANCE__
   =10b2d7d0 nsWindow::sLresultFromObject : Ptr32     long 

There then a command, "Dd <address>" to "Display dword values at specified address," but I'm not sure which is the address.  Is it the "10b2d7c8"?  If you can confirm this, I have a value I can post.  But will wait till you confirm so I don't end up posting data that should otherwise be private.

    
    

    
  
I don't know enough about the debugger you're using to answer your question with certainty. But yes, 10b2d7c8 seems like the right address.

    
    

    
  
(In reply to comment #44)
> I don't know enough about the debugger you're using to answer your question
> with certainty. But yes, 10b2d7c8 seems like the right address.

Hmm.  The output I got from the Db 10b2d7c8 command contained additional addresses, but I guess the only relevant one is the following, which turns out to be all zero:

10b2d7c8  00000000 00000000 00000000 00000000

    
    

    
  
OK.  In that case, I have no idea why some people are seeing an accessibility dependence...

    
    

    
  
Just noticed something.  It seems this issue causing high CPU on resizing is actually affecting painting and GUI responsiveness and not resizing itself.

If, when I resize, I do not let go of the mouse button and slightly wiggle the mouse pointer, for about five seconds, in the region I dragged to, the contents are updated to my drag dimension; however, high CPU load continues and the browser eventually become unresponsive, due to the bug -- until the bug has finished running its course.

    
    

    
  
So now I wonder if some people aren't experiencing this issue because their CPU has enough cores/threads that the problem code is able to run without blocking the GUI/painting -- unlike with my slow single core?

    
    

    
  
initial load is also piggish, not just resize. 10+secs on Core duo 2.4Ghz Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100429 Minefield/3.7a5pre (.NET CLR 3.5.30729)

    
    

    
  
Could this be related to bug 466955 comment 4?

    
    

    
  
Any chance this will get fixed?

Just tested with nightly on Windows 7 64-bit and a core i3 processor, and it completely hung the browser.

    
    

    
  
> Any chance this will get fixed?

Unclear.

For what it's worth, we now do what comment 38 suggested.  That change was made in bug 597627.  So the profile looks totally different now.

In fact what happens now is that all the time is spent under TrimTrailingWhitespace creating textruns.  The reason for that is that all the text here is a single huge textrun (no newlines anywhere), and nsContinuingTextFrame::DestroyFrom does this:

  if ((GetStateBits() & TEXT_IN_TEXTRUN_USER_DATA) ||
      !mPrevContinuation ||
      mPrevContinuation->GetStyleContext() != GetStyleContext()) {
    ClearTextRun(nsnull);

Note the nsnull passed to ClearTextRun.  This calls UnhookTextRunFromFrames with a null aStartContinuation.  We seem to not have a simple flow here for some reason, but the mapped flow count on the userdata is 1.  Since aStartContinuation is null, that means we set destroyFromIndex to 0, |found| eds up false, and we nuke the textrun's userdata.  Then ClearTextRun deletes the textrun.

In this case we're not in the textrun's userdata, but mPrevContinuation is null because we remove from flow before destroying so that the _following_ in-flows won't get killed in SetLength (again, see bug 597627).

    
    

    
  
And if I fix that issue, then I see all the time taken up by linebreaking inside nsTextFrame::EnsureTextRun.  It sounds like we're finding the textrun in the cache correctly but having to rebreak it.

And _that_ happens because when we enter nsTextFrame::EnsureTextRun from ReflowText aLine is non-null and has GetInvalidateTextRuns() == 1.  So we keep rebreaking the same text (from the very beginning) over and over again, making the whole thing O(N^2) in the text length.

roc, can we do better there somehow?

    
    

    
  
Actually, we can.  And if I do that, then all the time is spent in nsLineBox::IndexOf looking for the line to remove the frame from....  The usual problem.  :(

    
    

    
  
I tried dealing with that by removing in chunks, but that only helps a little (maybe a factor of 3x).  The O(N^2) behavior is still there.

I'll attach what I have so far, I guess.

    
    

    
  
bz, thanks for attaching what you have so far!

Here's another way I've run into this bug, and your patch seems solve my problem:

1)  In Thunderbird (on Mac OS X), compose a new message
2)  Do "Insert | HTML" and paste in a large block of text with no newlines.  In my case, I'm inserting a <img src="data:image/png;base64,......">

In my case, the ...... was 372,532 characters (a large, base64 encoded image)

Note this is a xul textbox.

3)  Attempt to resize the Insert HTML dialog

That's where I would beach ball.  And I no longer beach ball with your patch!

Another possibly related test case:

1)  In Firefox, go to http://htmledit.squarefree.com/
2)  Paste in <img src="data:image/png;base64,......"> (again, for me  ...... was 372,532 characters) into the top text area
3)  resize the top text area

But I bet that is similar to the test case in this bug already.

For that tbird bug, your patch makes a huge difference.  Do you think it could land as is?
Depends on: 682051

    
    

    
  
Seth, thanks for testing that!

I spun off bug 682051 to get that patch landed.
Blocks: 680461
Blocks: 667412
Depends on: 190147
Depends on: 682052
Component: Editor → Layout: Block and Inline
QA Contact: editor → layout.block-and-inline
Keywords: qawanted

    
    

    
  
With bug 682051 fixed, is this still an issue?

    
    

    
  
Yes, last I checked.  See comment 55....

    
    

    
  
Are you going to be able to spend some time on this, by any chance?  The DevTools folks are telling me that this makes the performance of Scratchpad really bad.  Plus, we also allow resizing of textareas on regular web pages by default now...

    
    

    
  
The next thing this needs, I guess, is a fix for bug 682052.

I'll see what I can do, but I have other stuff on my plate too that no one else is really likely to take on, whereas bug 682052 is something others could pick up as well...  If no one else does, I'll try to do it, of course.

    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: